Comments on: Simple suggestions for implementing passwords correctly

By: Stefano

Stefano — Sun, 18 Mar 2012 15:26:43 +0000

I would add “Don’t force me to put numbers and symbols to my password – if I want to use a 40 chars password, made up of 4 words and spaces, I want to be free to do that (and no one will ever hack my account)!”.

By: Antonin

Antonin — Mon, 19 Apr 2010 08:43:32 +0000

Some time ago I wrote a python library to work with the 1password “agilekeychain” format.
It is a good exemple of a decent secure manner of storing passwords using password deviation algorithm and strong encryption cyphers.

I you want to have a look : http://github.com/gwik/agilekeychain

By: Philip Tellis

Philip Tellis — Tue, 13 Apr 2010 09:03:45 +0000

@andy: email is not secure

By: andy

andy — Mon, 12 Apr 2010 07:04:40 +0000

When visitors sign up on one of my site, I email them their login information (username+password) before storing the hashed salt of their passwords in my database. Does that considered bad too? If yes, would you mind explaining why?

By: Philip Tellis

Philip Tellis — Mon, 12 Apr 2010 06:20:17 +0000

SSL isn’t absolutely necessary. Let me explain:

Users still don’t understand what SSL is, so if an attacker were to gain control over the user’s ISP’s DNS server, they could redirect DNS to their own server and steal the user’s login credentials. This means that if you can avoid it, you really don’t want to send the password as it was typed over the wire.

The solution is to implement challenge-response authentication. This requires changes on the client side though, and this is how you’d do it.

On the server, you store an encrypted password. You encrypt rather than hash because you want to be able to decrypt it later. This is your pseudo clear text password (since it can be decrypted by someone who has the key).

Now when a user comes to your login page (or sends an auth request through a non-browser based client), you send along a challenge string. For the non-browser based client, this could be based on the username, or not. When the user enters his login credentials into the form, you hash it client-side either using javascript for a browser or whatever language you want for a non-browser client. You then send the username and the hash to the server. This can be sent in clear text, since simply having the hash is insufficient for a replay attack. The hash has to match the challenge that was sent, and that changes on every request.

Once the request gets to the server, you run the same hashing algorithm on the decrypted password using the same challenge string, and if they match, you allow the user through.

This has the added advantage of being harder to brute-force because an attacker has to do the hashing on the client-side for each request, and has to use a different challenge for each hash (so he can’t just pre-compute hashes).

On the server, you still have to manage your assymmetric keys on different boxes (reg uses one way, login uses the other way), but that’s not terribly hard, and it means that if someone were to get login access, they’d need to be able to log in to two boxes. It goes without saying that boxes that store auth info (or any private info) go into a vault secured with a physical lock to prevent someone (eg: a bad employee) from just making a disk copy.

Oh, and this is not far fetched NSA stuff. Most internet companies that store user personal data should be doing this.

By: Antonio Cangiano

Antonio Cangiano — Thu, 01 Apr 2010 14:18:26 +0000

Matt, I would consider the open source Keepass.

By: Matt

Matt — Thu, 01 Apr 2010 13:08:44 +0000

Is there any Windows-based programs you would recommend? This is a brilliant article by the way, thank you.

By: Antonio Cangiano

Antonio Cangiano — Thu, 01 Apr 2010 12:52:57 +0000

Matt, this is why I only use a program that has a company I really trust behind it. Otherwise you could extend the same logic to your browser’s company or even your OS’ company. It’s also not hard to check for programs phoning home.

By: Matt

Matt — Thu, 01 Apr 2010 08:18:23 +0000

The hard part is trusting these programs as well. As a Windows user, how can I trust a downloadable password manager? How do I know it doesn’t have a keylogger or send off my details somewhere?

Trusting one program can be as dangerous as only using a single password.

By: Piervincenzo

Piervincenzo — Thu, 25 Mar 2010 08:50:32 +0000

This is a very useful post!
As you say a lot of site use a bad policy to manage not only the password but, more in general, the user-site interaction. In often happens that the real control of field is done after having post it and the user must re-write some field (e.g. password). But returning to the topic, of course the use of an application like iPassword make the security issue less stressful… but as you noticed it could be difficult work in a different machine without the passwords of iPassword so… why not use a portable solution?