markpasc.org weblog

So I'm reading this Open Web Application Security Project PDF article "Top Ten Web Application Vulnerabilities"--thanks for making the text uncopyable and URLs unclickable, btw--and have to take issue with this part, as I always do when someone overlooks this pet technology of mine that I defend irrationally:

All passwords must be stored in either hashed or encrypted form to protect them from exposure, regardless of where they are stored. Hashed form is preferred since it is not reversible. ... Decryption keys must be strongly protected....

Also, instead of storing encrypted passwords, use a one-way function, such as SHA-1, to hash the passwords.

(I was going to make sure they didn't cover this in the "OWASP discussion on Authentication and Site Management," linked from the article, but the URL is a 404, and it's entirely nonobvious where on the site it is, if anywhere.)

A lot of systems, such as LiveJournal, allow you to hash your password by itself and log in with that. The theory is that if someone steals the hash, they still don't know your password. The problem is they can still use that hash to log in as you for that service--as well anywhere you happened to use the same password that happens to use the same flavor hash. Sure, you're some protected, but it's rather accidental, so you shouldn't rely on it.

A long time ago when I messed with Jabber, it used a method of providing from the server to the client a token, or seed, that the hashed with the password to produce a one-time password. Apparently this is like S/KEY, which seems to add re-hashing to extend the life of each seed, and is apparently used in IMAP, and with which Jabber seems to have replaced the previous method. Neil Haller's original paper is listed in Citeseer and I don't see any subsequence "S/KEY Busted Wide Open" papers, and FreeBSD provides it and a functionally equivalent system called Onetime Passwords In Everything (OPIE), so I imagine it's still in use.

Except it isn't. Some folks at MIT went so far as to mention it in the "General authentication protocols" section of "Dos and Don'ts of Client Authentication on the Web" at the 10th USENIX Security Conference, but dismissed it because "it requires the client to perform computation such as modular exponentiation." It was already 2001, but is that such a problem? Actually, it was for them, because they stipulated browser extensions were disallowed; that is, a no progress zone. That's pragmatic, but with Atom doing some authentication magic and the case for save HTTP authentication, it seems to me the time has come to remove that restriction.

The problem with that is it requires the have the password, which is where the OWASP stipulation comes in. It seems to me nobody thinks of using anything like S/KEY not only because browsers are in the way but because people are security conscious enough to design their databases not to store the whole password. People in my experience do follow OWASP's suggested principle to hash instead of encrypt passwords. After all, UNIX has done it for thirty years. Then, after your model is working, you build the view and--oops, you don't have the whole password on the server, so the best you can do is have the client prehash the password to obscure it, which sounds good but is totally busted open to replay attacks.

Anyway, in general, while OWASP provides a good checklist of all the common faults you've heard of but may not recall off the top of your head, I'll give this as much credence as the article from which I got it, which shames LiveJournal for not protecting logins with SSL then quotes "abuse manager" Mark Ferrell stating "most of these attacks couldn't be prevented by technical means: 'People have had a boyfriend or somebody who knew their password and that person takes over their account.'" We haven't forgotten all the buzz about knowing your threat model already, have we?

In closing, all actual cryptography- and security-related content above is provided for amusement only, discovered in the last few hours when I should've been sleeping, should you know better enough to point where I'm wrong and laugh. But please do so.

January 1, 2004 5:06 AM 2 comments