Slashdot Mirror

SSH and GPG use one password and key everywhere--and remote hosts can't compromise my key or password because they never receive them or store them.

Maybe it's time for a change with respect to the retarded password systems we have out there: GPGAuth.

How about one password that can be used anywhere, securely? GPGAuth.
It was built into FireGPG for the last few years, but when the shitty FireGPG dev (Maximilien Cuony) closed up shop and refused to let other developers continue on using the FireGPG name, it was split out and is currently being rebuilt for Firefox, Chrome, Safari, Webkit, etc...

http://www.gpgauth.com/ is a good technology. It's open and it's based around GPG. The main thing holding us back is the lack of hardware standards and lack of hardware in general. We should have the hardware in place otherwise a lot of the software will be useless.

We need better smartcards, better e-tokens. The idea of putting identity on our cellphones is stupid. Put it on a card so it can be put in your wallet or hidden if necessary. By putting it in your cellphone it's a huge target for hackers.

Addendum: Never mind, sorry - unlike the summary implies by "all users" the attack was targeted at capturing passwords from users who logged in while the site was compromised.

Naturally, simple hashing is no protection against that.

GPGAuth would have prevented that. Never send your password over the internet again. Receive random garbled encrypted data, decrypt it, re-encrypt it, and send it back.

If 'they' compromise the site, they still don't get your password.

your recommended http://gpgauth.com/ seems to be a complete failure.

it appears vulnerable to MITM attacks (if I just follow what's on the http://gpgauth.com/#what_how page) and philosophically it seems to duplicate what is available with HTTP certificates and OpenID.

Maybe it's not clear on that page, but it's not a replacement for SSL. SSL makes sure your data is encrypted during transport. GPGAuth takes care of authenticating both the user/browser and the server. Your username is (I believe) send in clear text, along with a GPG-encrypted blob of random data which is used to validate you. The validation takes place both ways. The server is verified by the user/browser and the user is verified by the server.

If you correctly access mybank.com (for example) and setup your account using GPGAuth, the system will verify next time that mybank.com is not being MITM'd.

The only weakness would be the initial access. GPGAuth only makes sure the site you are authenticating to is the same one you were accessing before. But technically, that's what SSL certs\0 are for.

your recommended http://gpgauth.com/ seems to be a complete failure.

it appears vulnerable to MITM attacks (if I just follow what's on the http://gpgauth.com/#what_how page) and philosophically it seems to duplicate what is available with HTTP certificates and OpenID.

Maybe it's not clear on that page, but it's not a replacement for SSL. SSL makes sure your data is encrypted during transport. GPGAuth takes care of authenticating both the user/browser and the server. Your username is (I believe) send in clear text, along with a GPG-encrypted blob of random data which is used to validate you. The validation takes place both ways. The server is verified by the user/browser and the user is verified by the server.

If you correctly access mybank.com (for example) and setup your account using GPGAuth, the system will verify next time that mybank.com is not being MITM'd.

The only weakness would be the initial access. GPGAuth only makes sure the site you are authenticating to is the same one you were accessing before. But technically, that's what SSL certs\0 are for.

your recommended http://gpgauth.com/ seems to be a complete failure.

it appears vulnerable to MITM attacks (if I just follow what's on the http://gpgauth.com/#what_how page) and philosophically it seems to duplicate what is available with HTTP certificates and OpenID.

your recommended http://gpgauth.com/ seems to be a complete failure.

it appears vulnerable to MITM attacks (if I just follow what's on the http://gpgauth.com/#what_how page) and philosophically it seems to duplicate what is available with HTTP certificates and OpenID.

The biggest problem is that most users who are not technically savvy use the same username and password for all their online activities, including job sites and banking.

If Monster had encrypted their passwords, this would be a significanly smaller problem.

Or if they used something like gpgauth, it wouldn't matter that they stole your login details. A username and a public key are useless...

I would have beat you if I could have remembered my login details...

OpenID and passwords have problems.

With OpenID, your provider could go down, or go out of business. Then you're locked out of all your sites. Screw that.

With passwords, every site has a different length, case, or punctuation requirement. You might use the same password for eBay and your bank (bad!). Your password app could break, corrupt your passwords, etc...

How about a solution where you control the one and only key?

GPGAuth

You verify the site either by a normal SSL cert--or by the fact that you've been there before and already have it's gpg key. Next it verifies you by the gpg key provided when you first signed up.

Which does absolutely nothing to stop scaring visitors of your website
The problem is that most people seem to only need encryption, while others need some sort of trust that the person you are connecting to is legit.

For those that need the trust, you'll have to pony up to verisign. They spend time and money to verify who you are and make sure you can be tracked down if there are problems. (for the most part).

For people who just need some sort of encryption, it shouldn't require the whole trust model as well--just the ability to verify you are sending your username/password to the same server you were using the last time you went to my.whatever.com.

So someone spur on the bastards at gpgauth.com. It seems like a good idea.

Single sign-on is possible, you just have to stop with the bad idea that logging in gives the server enough information to impersonate you. Some sort of public key auth like SSH uses makes much more sense. It has the minor privacy downside that if you use the same key everywhere, then your identities could be linked together for data mining, but that can be trivially worked around by having multiple keys, just like people use multiple usernames to avoid that now.

Man-in-the-middle attacks are a serious concern. Of course, HTTPS handles them, so we are only talking about unencrypted HTTP. As far as I can tell, any HTTP-only auth mechanism existing can be trivially attacked with a man-in-the-middle attack. SSH handles them by showing the user the server fingerprint and leaving it up to the user to confirm it. Realistically for web auth, server keys would have to either be validated the way they are now, by CAs + auth over HTTPS, or via web of trust which could be used for a more flexible auth mechanism.

Two separate projects exist for making OpenPGP based HTTP auth systems: enigform (and mod_auth_openpgp) and gpgAuth.

OpenID is also a good idea because it moves the authentication process away from the server being logged into. Eliminating the entire problem, although likely adding others.