Two questions: phpBB security holes and (unrelated) md5
-
Well, I guess this might be related because phpBB uses md5 to store passwords...
1) I have read a few posts in TDWTF that phpBB is insecure. Actually the implications are that people find new holes all the time. Can anyone tell me specifically how it's insecure, or point to a resource? I intend to use it, but I want to see what kind of security issues I would have, and possible remedies. (I know how popular PHP is you software engineer types, so hold your flames, please. [:S])
2) Any value put through the md5 algorithm produces a 32 character string. What are the chances of two dissimilar values producing the same string? I presume it's at least possible, if highly improbable. What if the original values are < 32 characters, or > 32 characters? I thought someone might have that bit of trivia in their brain.
-
On #2
md5 is a 128 bit signature. So its 16 bytes, not 32. The
chance of generating the same string with 2 files is 1/2^16, or approx
1/65000. So the chance of 2 random files having the same md5 is
unlikely. Md5 does have some attacks though, so use of it for
cryptographic purposes is not recomended. Using it to id file
versions or the like is just fine.
If your original text is too short for the algorithm, you generally
fill the extra bits with a known pattern (all 0s) and take the md5 sum
of that.
-
Unrelated, but I'm not convinced on the usefullness of hashing/salting of passwords for things like bulletin boards. Who is this supposed to benefit? Does anyone actually use their "secure" password for bulletin boards?
-
@R.Flowers said:
Can anyone tell me specifically how it's
insecure
Well, here's the deal, it's not PHP that's insecure per se. It's
what you're going to do with it. Specifically, what you are going
to do with it (most likely) is take input from a user and then run some
code ON YOUR SERVER that acts on that input. That type of setup
is always prone to potential vulnerabilities - even if computers aren't
involved.
Think about it this way, if I gave you a recipe for French bread, I
wouldn't really care what you did with it. That's like giving
someone code to run on their own servers. If on the other hand, I
gave you my sweet old mother's mailing address, and told you that you
could write her a letter and ask her to bake some French bread and UPS
it back to you, then we have a situation like PHP, a situation that is
potentially vulnerable. If you can understand why that situation
represents a potential vulnerability, then you can understand why PHP
is often said to be insecure.
See, my mother represents the server and your letter represents the
input. I'm assuming that you're going to write my mother
something like the following, "Dear Mrs. Tofu, please bake two loaves
of French bread and send it to p.o. box 123" But somebody out
there is a mean, evil, bastard, and that person is going to write,
"Dear Mrs. Tofu, please bake two loaves of French bread and send a
check for $10,000 to p.o.box 123" and my sweet old mother, who doesn't
know any better, is going to dutifully follow those instructions.
On a PHP-enabled website, you are going to have some way for the user
to communicate with you. On this page of the Daily WTF that I'm
typing this response on, the address bar ends with "PostID=6054"
That's me communicating with the server, it's me asking the server to
look up post number 6054. This server isn't PHP but the issues
are the same. Somewhere on the server, some code like the
following was executed:
Select * from posts where posted = $PostID
If I was a mean, evil bastard, (and if the guy who programmed this
website was very careless), then I could change what's up there on my
address bar to "PostID=6054;delete from posts" And now when the
server executes:
Select * from posts where posted = $PostID
What it will actually be executing is:
Select * from posts where posted = 6054;
Delete from posts
I'm sure that the guy who programmed this website wasn't actually an
idiot though. I'm sure that he thought of this and wrote code to:
a) make sure that the variable PostID is an integer, and b) to remove
all possible SQL control characters just in case.
The question is, are you that smart? PHP isn't insecure. It's
just a tool. If you don't know what you're doing, then you will
write some code with that tool and that code will be insecure.
-
@tofu said:
@R.Flowers said:
Can anyone tell me specifically how it's insecure
Well, here's the deal, it's not PHP that's insecure per se.Actually, I was asking about phpBB, not PHP in general.
@tofu said:
The question is, are *you* that smart? .I hope I am! [:O]
-
@Alex Papadimoulis said:
Unrelated, but I'm not convinced on the usefullness of hashing/salting of passwords for things like bulletin boards. Who is this supposed to benefit? Does anyone actually use their "secure" password for bulletin boards?
I don't disagree, but that's the way phpBB handles passwords. And I can assure you that some of the users I have worked with (they tend to be independent businessmen) have memorized maybe 3 passwords, and apply them to their bank account, forum, online poker games, whatever. I've even had some of them boast(!) that they only use one password, thus eliminating the hassle of trying to remember different ones.
There is also the matter that I am using the bulletin board user accounts as a basis for other website functions, extending the table with my own fields. The data is not super-double-secret, but I want to be as safe as I can.
-
@R.Flowers said:
Actually, I was asking about phpBB, not PHP in general.
well, you can't really expect me to read your post before responding!
-
One big benefit. If your hashed password includes some random
data in the hash, you can then send the hash back in clear text without
using SSL, and yet be safe from replay hacks. This reduces server
load.
-
@Javariel said:
On #2
md5 is a 128 bit signature. So its 16 bytes, not 32. The
chance of generating the same string with 2 files is 1/2^16, or approx
1/65000. So the chance of 2 random files having the same md5 is
unlikely. Md5 does have some attacks though, so use of it for
cryptographic purposes is not recomended. Using it to id file
versions or the like is just fine.
Usually people take those 16 bytes and break it into 32 nibbles to produce a hexadecimal 32-character string, which looks all neat and tidy. I'd still defend MD5, or at least one-way hashing algorithms, as a method of storing passwords. This is ideal because you should never need to 'decrypt' a password - only to check that it's hash matches the one you've got.
I remember one afternoon at work a (more senior and much higher paid) colleague of mine asked me if there was anyway to 'reverse' an MD5 hash. I said no. He asked why. I tried to explain the difference between a one-way hash or checksum and a two-way encryption. He didn't believe me and insisted that there must be a way to reverse an MD5 hash.
After a ten minute argument, I gave up and told him that if he could reverse an MD5 hash he'd make millions of pounds selling his solution to the CIA or MI5. His eyes lit up with glee at the prospect and he spent the rest of the afternoon skiving off work furiously trying to hack MD5...
-
@murphyman said:
I remember one afternoon at work a (more senior and much higher paid) colleague of mine asked me if there was anyway to 'reverse' an MD5 hash. I said no. He asked why. I tried to explain the difference between a one-way hash or checksum and a two-way encryption. He didn't believe me and insisted that there must be a way to reverse an MD5 hash.
After a ten minute argument, I gave up and told him that if he could reverse an MD5 hash he'd make millions of pounds selling his solution to the CIA or MI5. His eyes lit up with glee at the prospect and he spent the rest of the afternoon skiving off work furiously trying to hack MD5...
hee hee hee.
If I was a mean, evil bastard, (and if the guy who programmed this
website was very careless), then I could change what's up there on my
address bar to "PostID=6054;delete from posts" And now when the
server executes:
Though SQL injection like that is just about the utmost basic of attacks, and easily patched by checking for is_numeric($yourparametervalue).
Even I know that. :)
Any other ways an evildoer can hack the gibson? I think that such information should be easily available for people with simple webhosting, because their DB usually has one user: the full admin. At least mine does.
I'm not sure how useful it is to hash passwords. If someone gets to the point where he can read the checksums from the DB, he definitely doesn't need to use it anymore. Like locking a key inside the box it's supposed to unlock: if you obtain the key, the box is already open.
-
@dhromed said:
Though SQL injection like that is just about the utmost basic of attacks, and easily patched by checking for is_numeric($yourparametervalue).
yes. That was the solution that I suggested.
@dhromed said:
I'm not sure how useful it is to hash passwords. If someone gets to the point where he can read the checksums from the DB, he definitely doesn't need to use it anymore.
It's because a lot of people use the same password for everything, and most of the time a user account table has an email address in it. So, if you got the account table for a website like thedailywtf, I bet you'd be able to access 25 to 30% of the users' email accounts.
Speaking of MD5s and HTTP, I once made an offhanded suggestion to a fellow programmer that it would be a good idea to hash the password on the client (with javascript or something). He said that was the dumbest thing he'd ever heard of, because, he said, if someone is sniffing the network, they will see the MD5 sum and they'll be able to replay it.
Anybody else see the fallacy of that argument?
-
@tofu said:
if you got the account table for a website like thedailywtf, I bet you'd be able to access 25 to 30% of the users' email accounts.
That's one thing I thought -- that hashing was meant to hide it from the BBS owner. But, I still don't see that protecting the user -- who's to say he hasn't changed the coding to plain text it? As a user, I think it's wise to have at least two passwords. I have three that I use; for a site like this, I would use my totally insecure password that I use (and have used) for 15 years. Except, since I have full admin rights, I use my 2nd level pwd.
@tofu said:Speaking of MD5s and HTTP, I once made an offhanded suggestion to a fellow programmer that it would be a good idea to hash the password on the client (with javascript or something). He said that was the dumbest thing he'd ever heard of, because, he said, if someone is sniffing the network, they will see the MD5 sum and they'll be able to replay it.
You know that's a good point. Everyone knows that network sniffers can only read binary and hex. A MD5 sum is hex-looking, and probably hex-like. But passwords are plain text, so if you send the password over the network in plain text, the sniffer is worthless.
-
@tofu said:
Speaking of MD5s and HTTP, I once made an offhanded suggestion to a fellow programmer that it would be a good idea to hash the password on the client (with javascript or something). He said that was the dumbest thing he'd ever heard of, because, he said, if someone is sniffing the network, they will see the MD5 sum and they'll be able to replay it.
Anybody else see the fallacy of that argument?I'd also have called dumb, but for the reason that any user using a javascriptless browser, or having javascript more or less disabled, would lose the ability to access the website altogether.
Which may be quite upsetting, and borderline illegal if your country/state has disabilities acts (e.g. class-action lawsuit against Target by a blind student of UC Berkeley), as are websites that try to throw you out when you don't accept cookies.
-
@masklinn said:
I'd also have called dumb, but for the reason that any user using a javascriptless browser, or having javascript more or less disabled, would lose the ability to access the website altogether.
And then I would call you dumb for making such an assumption. Quite obviously, I would have to make sure it worked when javascript was turned off. It is, in fact, trivial to make something like this degrade gracefully. I do it all the time. If you'd like example code just let me know.
Do you not see the point of my question re: the fallacy of the argument? If someone can sniff the line and get the hashed password, then they can sniff the line and see the plaintext password - and (here is the point) the plaintext password is more useful because, for some users, it is the password they use for everything.
-
@tofu said:
Do you not see the point of my question re: the fallacy of the argument? If someone can sniff the line and get the hashed password, then they can sniff the line and see the plaintext password - and (here is the point) the plaintext password is more useful because, for some users, it is the password they use for everything.
Of course I see it, but it was so obvious that, at least once in my whole life, I didn't feel like being captain obvious and chose to argue on a slightly less uninterresting point of the post.
-
Oh, and I beg your pardon for not considering that you could make this feature gracefully degrade, but in my experience the people who bring up that kind of ideas usually see "graceful degradation" as a set of 20 random ASCII characters, and by experience considering that everyone work that way until proven otherwise (see it as an opt-in form) works much better than considering that everyone is aware of the best practices of web design and programming.
(is it me or do I sound like a pompous jackass to you too?)
-
@masklinn said:
people who bring up that kind of ideas usually see "graceful degradation" as a set of 20 random ASCII characters
Yes, that's true. Most people don't care. Where I work, we have to comply with section 508, and for a long time I've hated the idea of IE-only websites, so over the years I've built up a bag of tricks to be able to do cool things and still have them work everywhere for everyone. But whenever we get a new programmer, they have to be trained to think that way, because when they get here they don't care - or so it seems.
-
@masklinn said:
Oh, and I beg your pardon for not considering
that you could make this feature gracefully degrade, but in my
experience the people who bring up that kind of ideas usually see
"graceful degradation" as a set of 20 random ASCII characters, and by
experience considering that everyone work that way until proven
otherwise (see it as an opt-in form) works much better than considering
that everyone is aware of the best practices of web design and
programming.(is it me or do I sound like a pompous jackass to you too?)
I agree with you, but it's not just you.
As for MD5ing passwords prior to sending them, that's basically a hack to work around the fact that it's impossible to use some but not all features of SSL. You could just use an HTTPS login page, but in the current implementation that means setting up a self-signed cert or paying money to someone just to set up your dinky web forum.
It'd be nice if you could get the encryption benefits of SSL without requiring the authentication features too. It shouldn't show the lock icon in browsers, because that's really supposed to be about authentication, but being able to encrypt semi-sensitive info would be useful even for unauthenticated recipients.
-
@tofu said:
@masklinn said:
I'd also have called dumb,
but for the reason that any user using a javascriptless browser, or
having javascript more or less disabled, would lose the ability to
access the website altogether.
And then I would call you
dumb for making such an assumption. Quite obviously, I would have
to make sure it worked when javascript was turned off. It is, in
fact, trivial to make something like this degrade gracefully. I
do it all the time. If you'd like example code just let me know.
Do
you not see the point of my question re: the fallacy of the
argument? If someone can sniff the line and get the hashed
password, then they can sniff the line and see the plaintext password -
and (here is the point) the plaintext password is more useful because,
for some users, it is the password they use for everything.
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
If another person tries a replay technique with the same hash, it
doesn't work, because the expected random value is not the same.
In a webpage, the initial request is basicly going to the login page
(its sent down in a hidden field). Such techniques are usually
not used with webpages though, since ssl is easy to use with a webpage.
For that matter, I don't think the server even needs to send down the
random string- the client can create it, and just tell the server
what was used. Saves a round trip.
-
@Javariel said:
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
If another person tries a replay technique with the same hash, it
doesn't work, because the expected random value is not the same.
In a webpage, the initial request is basicly going to the login page
(its sent down in a hidden field). Such techniques are usually
not used with webpages though, since ssl is easy to use with a webpage.
For that matter, I don't think the server even needs to send down the
random string- the client can create it, and just tell the server
what was used. Saves a round trip.Actually, it's very important that the server (not the client) generates the random string - otherwise, someone could pull the hash and random string off the wire and replay them at a later date (this risk would be removed, or at least somewhat reduced, if the server kept a record of every random string used ever, but that's totally impractical).
-
@Javariel said:
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
Nice try, but we already said that the server doesn't know the password. The server only knows the password hash. Your system wont work as you stated it unless the server knows the plaintext password.
Oops! I guess it's not such a bogus argument after all!
-
It seems everyone forgot about the PHPBB-related question. Here's what
I could determine from a brief look inside: it relies on
register_globals (ouch!) and is "secured" through an ever growing list
of sanity checks. Now, the team has a good history of plugging security
holes in a timely manner, but I can tell that nothing short of a
complete rewrite will stop new ones from appearing. So I guess PHPBB is
ok, if you're willing to patch your installation every few weeks...
-
@tofu said:
@Javariel said:
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
Nice try, but we already said that the server doesn't know the password. The server only knows the password hash. Your system wont work as you stated it unless the server knows the plaintext password.
Oops! I guess it's not such a bogus argument after all!No problem, just have the client send the hash of the hashed password and the random challenge.
-
@jsmith said:
@tofu said:
@Javariel said:
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
Nice try, but we already said that the server doesn't know the password. The server only knows the password hash. Your system wont work as you stated it unless the server knows the plaintext password.
Oops! I guess it's not such a bogus argument after all!No problem, just have the client send the hash of the hashed password and the random challenge.
That does work and is used in some places, though it means that someone who wants to hack into the system just needs to know the hash of the password (not the actual password). As long as you're using a suitable salt in the password hash, I think it does protect people who use the same password on multiple sites from having accounts elsewhere hacked if someone gets access to the site's database, though.
-
@felix said:
It seems everyone forgot about the PHPBB-related question. Here's what
I could determine from a brief look inside: it relies on
register_globals (ouch!) and is "secured" through an ever growing list
of sanity checks. Now, the team has a good history of plugging security
holes in a timely manner, but I can tell that nothing short of a
complete rewrite will stop new ones from appearing. So I guess PHPBB is
ok, if you're willing to patch your installation every few weeks...
I don't know the exact version where the chage was made (or what the
current version is come to that) but phpBB2 has been ok with
register_globals disabled for a while.
-
@makomk said:
@Javariel said:
Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
If another person tries a replay technique with the same hash, it
doesn't work, because the expected random value is not the same.
In a webpage, the initial request is basicly going to the login page
(its sent down in a hidden field). Such techniques are usually
not used with webpages though, since ssl is easy to use with a webpage.
For that matter, I don't think the server even needs to send down the
random string- the client can create it, and just tell the server
what was used. Saves a round trip.Actually, it's very important that the server (not the client) generates the random string - otherwise, someone could pull the hash and random string off the wire and replay them at a later date (this risk would be removed, or at least somewhat reduced, if the server kept a record of every random string used ever, but that's totally impractical).
Good point. I knew there was a reason we coded it the first way, I just couldn't remember it off the top of my head yesterday.
-
@NonComposMentis said:
I don't know the exact version where the chage was made (or what the
current version is come to that) but phpBB2 has been ok with
register_globals disabled for a while.
My mistake. Those sanity checks must be leftovers, then?
-
@felix said:
@NonComposMentis said:
I don't know the exact version where the chage was made (or what the
current version is come to that) but phpBB2 has been ok with
register_globals disabled for a while.
My mistake. Those sanity checks must be leftovers, then?
It's been a while since I looked inside (or used) phpBB so I'm not sure
but IIRC you can use it with register_gobals on or off so the sanity
checks are still required for the latter. I think that turning
register_globals off isn't required as a lot of managed hosting
will still have it enabled due to the amount of scripts requiring it.
Since php now has register_globals disabled by default, the next version of phpBB may well require it.
-
@Javariel said:
On #2
md5 is a 128 bit signature. So its 16 bytes, not 32. The
chance of generating the same string with 2 files is 1/2^16, or approx
1/65000. So the chance of 2 random files having the same md5 is
unlikely. Md5 does have some attacks though, so use of it for
cryptographic purposes is not recomended. Using it to id file
versions or the like is just fine.
If your original text is too short for the algorithm, you generally
fill the extra bits with a known pattern (all 0s) and take the md5 sum
of that.
Should that not be 1/2^128, or 1/256^16, or approximately 3x10^38? Although...there are recently-discovered attacks which can that chance a fair bit.
-
Going back to Tofu's qustion on PHP's insecurities, yes PHP is insecure in a few areas:
for instance the mail() function is insecure against injection attacks...
take this code for example:
<?php
$to="webmaster@website.com";
if (!isset($_POST["send"])){
// no post data -> display form
?>
<form method="POST" action="<?=$_SERVER['PHP_SELF'];?>">
To: webmaster@website.com
From: <input type="text" name="sender">
Subject : <input type="text" name="subject">
Message :
<textarea name="message" rows="10" cols="60" lines="20"></textarea>
<input type="submit" name="send" value="Send">
</form>
<?
}else{
// found post data .. deal with it
$from=$_POST['sender'];
// send mail :
if (mail($to,$_POST['subject'],$_POST['message'],"From: $from\n")){
// display confirmation message if mail sent successfully
echo "Your mail was indeed sent to $to.
";
}else{
// sending failed, display error message
echo "Doh! Your mail could not be sent.
";
}
}
?>this will produce a raw output of:
To: $recipient
Subject: $subject
$headers
$messageHowever taking note that the hex for line feed is 0A or %0A, you can specify numerous extra fields in the mail headers for example using the following values:
in the sender field:
"sender@anonymous.www%0ATo:recipient@someothersite.com,someoneelse@yetanothersite.com"
in the subject field:
"Congratulations"
and in the message field:
"Congrats you've won a free trip to hell, just goto mystupidpornsite.com to redeem your prize"
The email's raw data will look like this :
To: webmaster@website.com
Subject: Congratulations
From: sender@anonymous.www
<FONT color=#0000ff>To: recipient@someothersite.com,someoneelse@yetanothersite.com</FONT>
Congrats you've won a free trip to hell, just goto mystupidpornsite.com to redeem your prizeDespite having 2 "To:" fields in the raw data this will still work as having 3 recipients in the first "To:" field, thus enabling the site to become an anonymous SMTP proxy for the purpose of spamming to ANY recepient of your choice
-
Yep. PHP is one big source of spam. And again, it's not PHP's fault, it's just that it's very easy to shoot yourself in the foot with it. Sending mail, interacting with a database, and (god help us) working with the file system, are all areas where PHP will get you into trouble if you don't know what you're doing - and let's face, most of us don't. I'm certainly no expert. I would have written code vulnerable to the spam attack above. I'm sure I would have.
Maybe the PHP folks need to do a better job of encapsulating things like sending mail.
-
@tofu said:
it's not PHP's fault
Yes it is... Or the creators of this heap of poo's fault if you prefer...
The root issue is that PHP has never been designed, it started as a bunch of Perl macros and grew without control, restraint, lead, design, or anything... from there, kind of like mold on your several-years-old cheese. Or worms in meat you forgot in the sun a hot day of august. Even now, I doubt there's a good language designer anywhere near the PHP dev team of Zend.
-
@masklinn said:
@tofu said:
it's not PHP's fault
Yes it is...
The root issue is that PHP has never been designed
Sure sure, I agree with you that PHP is, shall we say, "raw." I even said that PHP should be better designed.
However, the distinction that I make is that PHP's problems aren't the result of bugs in the language. In other words, PHP does what it says it does. It's the inexperienced programmer's fault that he wrote insecure code.
Take the mail() issue detailed above. If PHP said, "use it this way and you'll never ever have any problems" but then that turned out to not be true, then I would agree with you, it was PHP's fault. But that's not what PHP says. PHP says, "what you put here will be output following the To: field in the header" and guess what, that's *exactly* what happens. PHP is doing what it said it would do. It is your responsibility to understand the implications of that.
Your criticism, that PHP isn't working hard enough to constrain the programmmer and protect him from his own carelessness, is the same criticism that we used to hear about C. Don't you remember? "omg! C let's you just assign a number to a point! What kind of crap language is this? Everyone should use Pascal!!" Remember that?
Think of it as being like a gun. If I buy a gun and shoot myself in the foot, who's fault is that? Most people will agree that it's my fault. Same situation here. If I dive into PHP and never think about safety, that's my fault.
-
@tofu said:
@masklinn said:
@tofu said:
it's not PHP's fault
Yes it is...
The root issue is that PHP has never been designed
Sure sure, I agree with you that PHP is, shall we say, "raw." I even said that PHP should be better designed.
However, the distinction that I make is that PHP's problems aren't the result of bugs in the language. In other words, PHP does what it says it does. It's the inexperienced programmer's fault that he wrote insecure code.
Take the mail() issue detailed above. If PHP said, "use it this way and you'll never ever have any problems" but then that turned out to not be true, then I would agree with you, it was PHP's fault. But that's not what PHP says. PHP says, "what you put here will be output following the To: field in the header" and guess what, that's *exactly* what happens. PHP is doing what it said it would do. It is your responsibility to understand the implications of that.
Your criticism, that PHP isn't working hard enough to constrain the programmmer and protect him from his own carelessness, is the same criticism that we used to hear about C. Don't you remember? "omg! C let's you just assign a number to a point! What kind of crap language is this? Everyone should use Pascal!!" Remember that?
Think of it as being like a gun. If I buy a gun and shoot myself in the foot, who's fault is that? Most people will agree that it's my fault. Same situation here. If I dive into PHP and never think about safety, that's my fault.
If car manufacturers stop putting good brakes in their cars and make a public announcement that their breaks, from now on, will be crap and you will be able to die unless you drive carefully, then does making that announcement absolve the car manufaturers from any responsibility concerning the safety of their drivers.
Do you buy into Kazaa's argument that "they just made the software" and it's not their users just "happen" to use it for copyright violation purposes?
PHP is not designed to be unsafe in the sense that the designers said "hey, let's make an unsafe language!". The gun you mention is *specifically* designed to be unsafe: you're supposed to use it to shoot people.
Idiocy!
It's the user's fault for not thinking about safety.
It's most certainly PHP's fault for making the unsafe so terribly easy.
-
@dhromed said:
If car manufacturers stop putting good brakes in their cars and make a public announcement that their breaks, from now on, will be crap and you will be able to die unless you drive carefully, then does making that announcement absolve the car manufaturers from any responsibility concerning the safety of their drivers.
That actually makes the car undriveable, so I don't think it's a valid analogy. A better analog would be, what if car manufacturers started making motorcycles. In that case, people who want to ride motorcycles, perhaps because they are cheap, accept responsibility for what they do on the motorcycle.
People who want to use PHP, perhaps because it's free, have to accept some responsibility.
Can PHP be better. Yes. This is the third time I've said it. Should it be better. Absolutely. But the reality is, it's not better, not yet. So you use it, it's your fault.
-
@tofu said:
That actually makes the car undriveable
No it doesn't, slightly harder to much harder to drive sure, but I've already driven a car without foot brakes (now without hand/parking brakes is another matter, not much of an issue for the driving itself, but makes full stop kind of an engine breaker).
It was a manual, not automatic though, I have no idea how you could do it on automatic.
-
Now there's a WTF - automatic cars. (they dont exist in Ireland, we prefer to have FULL control of the car)...
-
-
@Hitsuji said:
Now there's a WTF - automatic cars. (they dont exist in Ireland, we prefer to have FULL control of the car)...
Your avatar makes me unhappy. Are you 15?
sincerely,
Richard Nixon
-
@Hitsuji said:
they dont exist in Ireland, we prefer to have FULL control of the car
I don't believe it in the least. You may say that they're not frequent, not widespread, that you never saw one, I'd say the same about france (well not the latter since I already saw one or two) especially after visiting the US where automatics are extremely widespread, but saying that "they don't exist" is at best an overstatement and at worst a lack of knowledge.
-
@masklinn said:
@Hitsuji said:
they dont exist in Ireland, we prefer to have FULL control of the car
I don't believe it in the least. You may say that they're not frequent, not widespread, that you never saw one, I'd say the same about france (well not the latter since I already saw one or two) especially after visiting the US where automatics are extremely widespread, but saying that "they don't exist" is at best an overstatement and at worst a lack of knowledge.
I think, p'raps, that you may have read "automatic transmission" where "automatic car" was written. I think it was a play on how we on this side of the pond tend to say "the car's an automatic" rather than "she's got an automatic gearbox" or some such....
-
@Stan Rogers said:
@masklinn said:
@Hitsuji said:
they dont exist in Ireland, we prefer to have FULL control of the car
I don't believe it in the least. You may say that they're not frequent, not widespread, that you never saw one, I'd say the same about france (well not the latter since I already saw one or two) especially after visiting the US where automatics are extremely widespread, but saying that "they don't exist" is at best an overstatement and at worst a lack of knowledge.
I think, p'raps, that you may have read "automatic transmission" where "automatic car" was written.Indeed
@Stan Rogers said:I think it was a play on how we on this side of the pond tend to say "the car's an automatic" rather than "she's got an automatic gearbox" or some such....
My automatic translator just burst into flames. I hate jokes&irony in english, I still miss 75% of them bastards :/
-
@Richard Nixon said:
Your avatar makes me unhappy. Are you 15?
sincerely,
Richard NixonWhy does my avatar displease you so? Do you know of another way I can run unsigned code? Nah I'm not 15 , but I am still pretty young, 22.
-
@Hitsuji said:
@Richard Nixon said:
Your avatar makes me unhappy. Are you 15?
sincerely,
Richard NixonWhy does my avatar displease you so? Do you know of another way I can run unsigned code? Nah I'm not 15 , but I am still pretty young, 22.
Because it's the type of avatar that someone on one of those modding forums would have. I am not criticizing either the discussion or the act but rather the use of the avatar as some sort of badge of honor, as though it made you special.
sincerely,
Richard Nixon
-
@Richard Nixon said:
@Hitsuji said:
@Richard Nixon said:
Your avatar makes me unhappy. Are you 15?
sincerely,
Richard NixonWhy does my avatar displease you so? Do you know of another way I can run unsigned code? Nah I'm not 15 , but I am still pretty young, 22.
Because it's the type of avatar that someone on one of those modding forums would have. I am not criticizing either the discussion or the act but rather the use of the avatar as some sort of badge of honor, as though it made you special.
sincerely,
Richard NixonYour quite correct, it is. And no its nothing that makes me special, it just shows one of my interests, and that is programming for the xbox. Theres quite a few nice apps for the xbox out there like xbmc, but theres always something missing that i like to write myself. it's a nice learning curve while im in college. And gives me a chance to learn about a few things that i wouldn't necessarily learn elsewhere. And I think thats enough talk about me coz this convo's starting to get well off topic
-
@Hitsuji said:
@Richard Nixon said:
@Hitsuji said:
@Richard Nixon said:
Your avatar makes me unhappy. Are you 15?
sincerely,
Richard NixonWhy does my avatar displease you so? Do you know of another way I can run unsigned code? Nah I'm not 15 , but I am still pretty young, 22.
Because it's the type of avatar that someone on one of those modding forums would have. I am not criticizing either the discussion or the act but rather the use of the avatar as some sort of badge of honor, as though it made you special.
sincerely,
Richard NixonYour quite correct, it is. And no its nothing that makes me special, it just shows one of my interests, and that is programming for the xbox. Theres quite a few nice apps for the xbox out there like xbmc, but theres always something missing that i like to write myself. it's a nice learning curve while im in college. And gives me a chance to learn about a few things that i wouldn't necessarily learn elsewhere. And I think thats enough talk about me coz this convo's starting to get well off topic
As long as you're in college, take an English class. I'm amazed that you got out of high school.
And if you think that since you're going to be a programmer, grammar and spelling skills don't matter - think again. I will block a promotion for anyone who can't understand and make use of "your" and "you're" without hesitation.
sincerely,
Richard Nixon
-
hehe, sorry, was rushin' while typing that. In the middle of work at the time
-
@Hitsuji said:
hehe, sorry, was rushin' while typing that. In the middle of work at the time
Sure, that's it. You're too busy for proper English. If you are well-educated, you don't have to think about using "your" or "you're"; it just comes out correctly. Again, I suggest you take some English classes and get some fry cook skills to fall back on.
sincerely,
Richard Nixon
-
Hey man no need for the agro
-
While I've not had much experience with phpBB myself, I have heard that while it used to have a fair number of security issue's that this is no longer true. That said however, having looked over the code base for it, I personally would avoid it if possible, simply due to the mess that it is.