I'd certainly be willing to try. Perhaps on signup/account registration including a "keyserver/whatever".

The problem is that it might be overly technical for most users, so having it as an option for login could be nicer. (and having it in an option somewhere to enable, so as not to scare off illiterate users).

Another thing that could be done is bringing authentication to the client side would be to run a javascript hash on the clientside. (creating an authentication token using hashes of both username, password and a nonce sent through a hidden form value.).

This would be simple enough. Clear the password in javascript, set a new hidden field with the digest value and then on the server side use the digest to authenticate. You then know who they authenticate as using the provided username.

Talk about implementation of a poc?

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

Maybe setup an openid provider that uses your gpg key to authenticate you?

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.

@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.