Tuesday, May 05, 2009

Can you trust Paul Graham with your password?

The other day I asked Can you trust 37signals with your password? and the good folks at Hacker News responded on their forum and here on my blog. Driving back home the other day I suddenly wondered how good a job Hacker News was doing of keeping my password safe.

The answer is... only marginally better than 37signals. Since the source code of the web site is available it's possible to dig in and find out how Paul Graham handles password authentication.

The good news is that he doesn't store passwords in plain text. And even better he uses a one-way hash function (SHA-1) to verify passwords. When you enter your password it is hashed using SHA-1 (he uses OpenSSL's implementation of SHA-1 to do the hashing) and then stored in a file called arc/hpw. When it comes time to verify a password the hash from the password file is read and compared with a hash of the password you typed in.

(def good-login (user pw ip)
(let record (list (seconds) ip user)
(if (and user pw (aand (shash pw) (is it (hpasswords* user))))
(do (unless (user->cookie* user) (cook-user user))
(enq-limit record good-logins*)
(do (enq-limit record bad-logins*)

(def shash (str)
(let fname (+ "/tmp/shash" (rand-string 10))
(w/outfile f fname (disp str f))
(let res (tostring (system (+ "openssl dgst -sha1 <" fname)))
(do1 (cut res 0 (- (len res) 1))
(rmfile fname)))))

The good news is that this means that if arc/hpw were stolen a hacker wouldn't be able to read the password from the file directly. The bad news is that the file is readily attackable using a rainbow table. If you got access to his password file, the passwords within it (unless they were really, really good passwords) would be broken in seconds or minutes.

That's a pity since he could easily have implemented a salted hash and he would have had a first line of defense against a rainbow table. The current implementation is little better than a plain text password file.

Even better he could have swapped SHA-1 for a slow algorithm like bcrypt. With salted bcrypt rainbow tables are out of the window, as are password crackers that rely on running a dictionary plus salt through the hash algorithm.


Manfred said...

When your server is compromised in such a way that people can read the password file it doesn't really seem too much effort to also steal all databases, which would give you access to all data anyway.

SCdF said...


It's not so much the data on the site that people would be worried about, it's more that many people use the same password for more than one web site.

So if my password is '[email protected]+' and I use it for a bunch of obviously associateable sites (facebook, my blog, any login that uses my main email address) you could then use the password gleaned from the password file on a myriad of other sites I use.

kibitzer said...

SCdF, impersonating someone on FB seems rather silly, it could never validate the time spent hacking/decyphering password file, only if for some script kids epeen enlargement. You don't use [email protected]+ for your online banking, do you?

As to the original post, no crypto algorythm is uncrackable, so the only metric you have to consider is time spent vs. benefit gained. Websites encrypt passwords for the sole purpose of preventing accidental plaintext display. So here I would agree with Manfred, compromised system means that attacker already gained all the possible benefits, so there really is no reason to spend CPU on harder-to-crack encryption, as the value of public site password seems miniscule.

Anonymous said...


Scammers use compromised Facebook accounts to claim they've been robbed and stranded abroad, and could their friends wire them some money so they can get home.

Anonymous said...

Hacker News also allows you to use OpenID, which bypasses the issue of individual sites storing passwords altogether. I'd say that's much better than storing passwords in plain text.

Andrew said...
This comment has been removed by the author.
Anonymous said...

Hacker News also allows users to use OpenID as their authentication which bypasses this issue completely for users who take advantage of OpenID.