Single Malt Passwords vs. More Bad Ideas

Howdy y’all-

Can I take a moment here to point out that the above punctuation is in fact correct? “Y’all” is a contraction of “you all” and thus I find the proliferation of “ya’ll” to be Just Plain Weird. Also, “y’all” is plural. Not singular. Please make a note.

And on a similarly important subject, if I ever again read a novel in which a character orders a single malt whiskey (or whisky…it’s island-specific) without specifying anything further, I may discorporate and haunt the author. The whole point, guys, is that single malts exist to help us celebrate, you know, unique and interesting flavors. Or, more often, flavours. So, I mean, what the heck? Glenfiddich and Glenlivet, by the way, might as well be blended. Try the Laphroaig 15-year, or the Lagavulin 16. Take a small enough sip that, by the time it reaches the back of your tongue, it has evaporated or elsewise gone away. Ignore all advice to add water, or Splenda, or manure. Though actually the manure might be interesting. After you recover–this may be painful at first–do it again. One of Lawrence Block‘s characters, in a book I very much liked, once either said or thought that, upon considering the first sip of Laphroaig, one wonders why anyone would drink it. But by the tenth sip, one wonders why anyone would drink anything else. Larry’s smarter than I am, and so are his characters, so pay attention.

Okay. I had a conversation a couple of weeks ago with a couple of recent college graduates. They seemed proud of themselves, and as they seemed to be productive young adults, they had every right. But the thing is, and you guys know I’m all about the thing, they espoused a most horrible idea concerning the storage of passwords.

Once upon a time passwords were commonly stored as plain-text in a database. Obviously this caused issues when the database was compromised. Next idea: passwords were stored in “hash” or “digest” form. For the uninitiated, a hash (or digest) is the result of an algorithm that takes input, such as a password, and returns an otherwise-incomprehensible string. It’s a one-way deal, so a document will always produce the same hash, when using the same algorithm, but you cannot generate a document from its hash. Also, a small change in a document produces a large change in its hash. So storing hashed passwords is neat: you see what the user gives you to log in, hash it, and compare. And you don’t store the password at all.

Problem: it’s not too hard to create a table of hashes of common passwords using the most common algorithms. And it’s absolutely possible, in every case, to find or create a password that will match any given hash, once the algorithm is known. Though, yes, in some cases it might be difficult. So progress has been made, but we aren’t done yet.

Next came the “salt”…which is not necessarily passed at the dinner table. A salt could be something like “hi this is david’s most recent rant” which is appended to a password before its hash is generated. No, I don’t know why hashes are almost always appended rather than prepended or interpolated or whatever. Deal with it for now & we’ll return to this in a bit.

A salt does something neat: an attacker now has to generate tables of hashes of common passwords with the salt appended. Yeah, I know. So what? Enter the “random” salt. The idea is that a different salt is generated on a per-password basis. So sure, you can generate a “rainbow table” that includes hashes of various common passwords plus salt, but you have to do this for each salt value. Neat! The whole thing becomes more secure!

Lots of applications use this method for password storage. There are standard “plugins” that take all the work out of it, too, which is nice for busy programmers. But…uh…guess what? Given sufficient computing resources & data storage (what year is this again?), lots of user passwords can still be identified. Why is this?

Because the “salt” is almost always stored in the database, right next to the hashed password-plus-salt.

Ow.

So here’s another idea: generate the salt via some application-specific algorithm. Include a timestamp, some weird manipulation of a username or email address, or really any data that is expected to remain constant over the span of time you anticipate interacting with a given user. Don’t store the salt in a database. If you don’t trust your algorithm, heck, use a hash of the weird string it gives you. Don’t store that either. In fact, if your application runs on multiple servers, let part of the data used to generate the salt live on a server entirely separate from the one hosting your database. Require login credentials that are not stored in either your database or your application’s code. Further, cause the server hosting that data to restrict access to a small range of internal IP addresses, making it very difficult for an outside attacker to access it at all.

Downside? It’s harder to build a generic plugin. As it, you know, should be.

I have this notion that people who store other people’s data should take some responsibility for it. And, you know, do the work. The guys I was talking to literally would not hear what I was trying to tell them, though. It kind of hurt my brain.

So what’s Scarecrow do about all this? I’m not telling you. Nor did I enlighten the guys I spoke to earlier. I might have dropped some hints, though, if they hadn’t wandered off in a huff.

Remember: single malt is about doing something different and not easily repeated. It is not the same as a blended whiskey. It’s not trying to be.

Okay, I’m done. As always, please feel free to tell me how I’m wrong.