Sho Fukamachi Online

My application’s so bad …

… It runs faster with debugging turned on.

… It maxes out the CPU even when it’s not running.

… the error messages crashed console.

… the errors email was too large for my inbox.

… it outputs messages to console begging for me to kill it.

… subversion rejected my commit, and called me an “asshole”

… other applications around it shut down out of pure disgust

… it crashed my modem

… it crashes other computers who are just in the same room

… it starts up my computer, just to crash it

etc.

God, who would have thought it would be so easy. And yet it took me several days of playing around to finally figure it out.

I wanted to make a hash of interface strings to use in localisation. So I’ve got my user, and he has a language_id which links him to a languages table. Then I have interfaces, which have interface_strings attached to them, with a language_id field .. so by association joined back to the user. I want to make a hash of interface strings, determined by the user’s language_id, for easy localisation throughout the app.

So I’ve got my user:

 = User.find_by_id(session[:user_id])

From that I can query interface strings in the language of that user

 = .language.interface_strings.find(:all)

now let’s make an empty hash:

 = {}

And fill it with the strings:

for i in 
   [i.interface_id] = i.text
end

and now I can just call it by id number, ie interface_id .. or by modifying that loop, I can stick whatever identifying key I like into the hash. I’ll just go with ID numbers because I don’t want to worry about escaping anything:

[1]

.. will return the first interface string (“welcome!”) in whatever language the user has specified (and I have translated).

God, that was easy. Too easy! That’s why it took me so long, I couldn’t join dots that were so close together …

I mean seriously .. what is the actual reason to store them as hashes?

So if your database is compromised, people can’t see the passwords? Is that the reason? Seems to me that if your DB is compromised, you’re kinda fucked anyway.

Is it so you can save the hash in a cookie, and log people on automatically? So why not just store the hash in cookies only? And if you can see the hash, you can fake the cookie anyway, and gain a login that way! And let’s not forget that a dedicated attacker in possession of the hashes can just brute force them anyway, so you’re just slowing them down a bit. Even if you use a different salt for every hash, how long do you seriously think it takes to brute force a 6-digit password on a modern computer? 10 minutes max?

So why? Is there some killer reason I’m missing? Because there’s certainly a cost – you can’t email users their passwords anymore, something that users find extremely convenient, which is why YouTube and MySpace both store in plaintext. And don’t tell me emailing a password is a risk any more than emailing a “click here to change your password” link – which inevitably contains some sort of authentication token encoded in the URL. If an attacker owns the email, he owns an account which relies on that email, period. And as for “protecting your password from the webmaster” – don’t make me laugh, if he wants your password he can get it the next time you type it no matter what’s in the database. And if an attacker has compromised your main server, he could easily add some code to store login information somewhere, or even email it to himself!

So let me get it straight: Storing credit card information – no problemo! Storing names, dates of births, and other personal information useful for identity theft – hokey dokey! Storing hits, IP addresses, full text of all private messages, and the complete history of everything a user ever does on a site – yes sirree! Sending passwords in plain text over the wire, over insecure private and public networks, through countless routers owned by who knows who .. alrighty then! But storing passwords in a secure database- oh no, can’t do that, not in a million years.

Oh and yes I’m well aware of what happened to Reddit. But their database was stolen! I mean .. isn’t the real problem not that the passwords were in plaintext, but that their database was stolen??? As far as I can see, the only valid argument for hashing passwords in an otherwise well-designed system is to protect them from rogue non-authorised personnel with physical access to the machine, as you might find in a datacentre. But gee, if you’ve got that type of person hanging around in your datacentre you’ve got other problems .. and they could just as easily sniff you at the switch. Hell, the lesson I take away from the Reddit case is simply this: encrypt, or otherwise protect, your backups.

My take: it’s OK to store passwords in plaintext as long as you’re real careful about it. Treat them the same as you would CC information – preferably in a seperate machine from the web server, on a private network, with a different authentication regime. Extra points for implementing some kind of token system so only one password can get out at a time over a defined interface. But geez, we can put man on the moon, you’d think we could store a fricking password safely.

My feeling is that the obsession with password hashing derives from the old days of massive, shared computers, where anyone could read /etc/passwd, and an insecure database was assumed. For anyone with their own dedicated servers, it’s just not such an issue anymore. With the proper precautions in place, I don’t see why passwords shouldn’t be stores in their native state.