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

    $message

     

     

    However 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 prize

     

    Despite 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:

    automatic cars. (they dont exist in Ireland


    how do you hold on to your beer??



  • @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 Nixon

    Why 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 Nixon

    Why 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 Nixon

    Why 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

    Your 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 Nixon

    Why 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

    Your 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.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.