Thus idea would work well with OpenID; it's not an alternative to it.

As I understand it, this already exists in SSL - your browser should have a mechanism for handling user certificates, which sites can use to authenticate you.

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.

One of the bigger problem with this I can foresee is userA putting userB's public key in their own account - this would lead to duplicate keys. Although this would effectively lock userA from his own account, allowing userB to possibly log in as him.

You solve that problem by requiring userA to sign userB's public key with userB's private key.

The article says that "SSL for a site like NEVERFEAR isn't practical." Why is that?

I've always wondered why so few sites use SSL/TLS for the login-part.

As a couple of people pointed out above, SSL has all of the tools you need to secured authentication and it's already integrated into modern browsers and webservers.

Apache can be set up so that access to directories or entire servers is dependent on having a client-side certificate signed by the proper CA, there are plenty of tools that will make it easier for end-users to install the certificate in their browser, etc.

If you're absolutely determined to use gpg then you might want to take a look at John Walkers Javascrypt which is a javascript implementation that can be run from the users browser.

@Mo:

Your critical reading skills could maybe use a little work.

You enter a username and password, the web-server hashes the password...

First, the password hash isn't made client side.

Duh. That's what he said.

Sounds a lot like what LID did, before OpenID came along.

Some heavy thread-necro action here, but I had to comment given that I'm considering implementing something like this (for a private system, so OpenID doesn't exactly fit).

Steps

• Site displays random string/paragraph.

• The user copies this string, using: gpg --sign -armour

• The user copies the output into a textarea on the site, and submits it.

• The site runs gpg --verify on the returned textarea

• If it validates, who ever's key it is ("gpg: Good signature from "Bob Smith (Bob) bob@someFakeSite.com") is logged into the site.

You'd be able to cut steps 1 thru 4 by just having the client send a unique value each time. Sign the current time and send it out. On the server side, check that you don't already have the value you were just sent (wipe old ones occasionally if you're too cheap to get more disk, or require the signed values to be successive integers rather than the time), verify the signature and log them in (and store the new value) if it passes. It may get a bit storage intensive if your clients log in very frequently, but it knocks two network hops out of the process, and simplifies it a bit.

Mozilla Persona?