PHP Koderz Suck Moldy Dead Crotch

By now you’re probably aware that I think PHP koderz (who often way too generously refer to themselves as “developers”) are among my least favorite of the lower primates. Here’s an example of why that is:

One of my clients uses a shopping cart that’s pretty darn popular, but that shall remain unnamed here. They hate the thing, and since another of my clients is designing a new web site for them I’m writing them a new, custom shopping cart that will suck less. Along the way, they want to import all of their existing customer profiles into the new cart from the old one, which means I have to know the encryption algorithm used to store passwords in the old cart. It’s the first time I’ve had reason to concern myself with the passwords in the old, pretty darn popular shopping cart. When I looked into the database table that contains the user names and passwords, my first reaction was


But yes, they did. They used a cryptographic hashing algorithm that has been considered totally inadequate since the mid-1990’s. I was a member of the winning team in the competition to crack the thing way back when, in 1996 or so. I snagged three password hashes out of the shopping cart’s database, and plugged them into which gave me the plain text of two of them.

Grrr. Nothing makes me angry in quite the same way as a dolt who plays fast and loose with other people’s sensitive information only because said dolt doesn’t know any better. My client has already had trouble with that shopping cartย โ€” there’s a contract spammer in The Philippines who targets that cart specifically because it will gladly gateway his spam via the “email this page to a friend” feature which no site anywhere on the web should still have in the 21st century. Spammers abuse the hell out of them. The shopping cart vendor’s fix is so half-assed that as soon as that contract spammer reads their support forum he’ll know precisely how to work around it. At least anyone whose cart is abused in that way can find my bulletproof fix there and not be at the mercy of an incompetent vendor and a contract spammer who takes advantage of the vendor’s incompetence.

Now I get to crack all of the passwords I can in the existing database so I can convert them to new hashes using a hell-for-strong algorithm that’s more adequate for 2014. I probably won’t get all of them so will have to finish the job by writing code that will authenticate against the old weak shit and then update the stored passwords to the new, and later go through to just blow away the weak shit if those users don’t come back around. My client will probably hate that I’m going to blow away customer accounts. They’re already downgrading my password security requirements, which torques my nads, but I’m implementing brute force attack evasion so it’d be one wicked lucky cracker who could break in that way. And the algorithm I’m using is tough enough that even if someone like the NSA got hold of the database it’d take them a long, long time to get anything out of it.

Paranoia is the most important part of my job description. ๐Ÿ˜€


6 thoughts on “PHP Koderz Suck Moldy Dead Crotch

    1. happierheathen Post author

      Most of the time it’s perl. Sometimes it’s C, C++, python, ruby, or javascript. Sometimes it’s even PHP, in which I’m fluent but I find it distasteful. It’s more a collection of features than a programming language, as far as I can tell. But that makes sense because the original author wasn’t out to create a programming language — he intended it primarily as a template parser.

      I’m a-fixin’ to salt me some hashes, too. Gonna just about bury ’em in salt, even. And mix in some PBKDF2 for filling and binding. ๐Ÿ˜€

    1. happierheathen Post author

      PBKDF2 atop Blowfish,scrypt with very long salts out of a CSPRNG, and sensible password restrictions. (I’ve been looking for an excuse to use scrypt in production and I’m making this my excuse.)

      PS: In case you’re interested, I got 51.55% of the passwords in about half an hour using a relatively small password database of 1.2E9 entries. If I had (legal!) financial incentive to do so I’d get 100% by brute force, though it might take a few weeks running on a spare machine and it’d be noisy in the office with that machine’s CPU fan running full tilt the whole time.

  1. solberg73

    Hmm, I’m lucky. Spent an entire night last week researching random number generators but just for the intellectual pleasure of it. (My own need for knowing this is somewhat past: The C-64 used the ‘jiffy-clock seed plus some multiply/modular math).
    Also (maybe) now understand the newly discovered process for factorizing very large numbers, as in the RSA scrypt (spell-cheque still don’t like dat word.yet) Again, just to say that I can.
    I enjoy reading your descriptions of real-world applications.

    1. happierheathen Post author

      I just converted my application to use scrypt, but have to tune it some as my dev version is cranked way up so password validation is a 10 +/- 0.1 second process that would annoy users. I figure making it a two second process will not annoy so much but will still make parellelization a damnably expensive proposition.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s