Comment on Secure website-authentication using GPG keys

Mo
Sun, 30 Dec 2007 14:09:34 +0000

I'm sorry, but I didn't read past your first paragraph. Which is a shame given that I managed to find your article from out of nowhere in the internet.

Currently, most websites log you in the same way: You enter a username and password, the web-server hashes the password (generally via MD5(), or SHA1()). This hash is then compared to the one stored in a database - if it matches, the user knows the original password, so it logs them in. This method has numerous problems, such as the password being sent unencrypted to the web-server, and the fact many users reuse passwords, if an intruder works out a users password (though any means), there is a good chance they can log into the same users email account, online banking etc etc..

It's all wrong what you just said there. First, the password hash isn't made client side. Meaning that the server doesn't receive a hash, it receives a clear text password which it then hashes. This means that a hash guessed offline is of no use to an attacker since the hash would be hashed again by the server and would obviously not match.

Second, the password should never be sent in clear text. This is the reason PKI-SSL exists. So that you can send your password over https. I'm not even going to defend https because that would be crossing into tin-foil land.

Last, even if you did someone manage to get access to hashes, there's an embarrassingly simple solution to the problem you described above and it's called Salt. The concept is simple, a server has a set random text it prepends to all passwords. So if you guess that a user's password is always "foo", you still haven't gained access because in ServerA that password would be hashed as "@#foo" while in ServerB it might be hashed as "FF_foo".

In essence: no. Sorry, bu I will not even read a cryptography article if it starts with such a fallacious first paragraph.