20 responses

  1. Nicola Larosa
    March 24, 2010

    Thanks, Antonio, very nice recap of what should *not* be done, as much important as what should be.

  2. thomas
    March 24, 2010

    i don’t get point 10. why is that bad?

  3. Antonio Cangiano
    March 24, 2010

    Thomas, while it is only a minor issue, it’s an annoyance to the user. If I just entered my password, and I’m about to confirm it, I should not be prompted with an error message. Error messages should be reserved for situations when something out of the ordinary happens (that prevents the sign up process from going through).

  4. nlo
    March 24, 2010

    @thomas – He’s saying don’t show the password mismatch error as soon as you tab out of the initial password entry box. Ideally, I think, this error should only be shown as early as tabbing out of the password confirmation box.


    Instead of

  5. nlo
    March 24, 2010

    Speaking of annoyances, WordPress filters out HTML-like tags in comments instead of escaping them!

    Take two – e.g.:
    (password entry) (tab) (password confirm) (tab) (first time password mismatch error may appear)

    Instead of (password entry) (tab) (first time password mismatch error may appear) (…)

  6. Zach
    March 24, 2010

    The worst is when I use my password manager to create an awesomely long password, the website accepts it, and THEN I CAN’T EFFING LOG IN WITH THE PASSWORD IT JUST ACCEPTED BECAUSE THE IDIOT DEVELOPER ISN’T ESCAPING CHARACTERS CORRECTLY. This happens more than it needs to, really.

  7. Antonio Cangiano
    March 24, 2010

    Good one, Zach. I HATE when that happens.

  8. Giovanni Bajo
    March 24, 2010

    Why are you saying that GMail got it wrong for a long time? GMail used to be non-SSL by default for the content, but the login has always been SSL, as far as I can tell.

  9. Antonio Cangiano
    March 24, 2010

    Giovanni, I think you’re right. I removed my remark about Gmail.

  10. Cindy Compton
    March 25, 2010

    Hi Antonio,

    Great post! Thanks for showing folks some best (and worst!) practices 😉

    Thanks for your support of 1Password!

    Cindy Compton
    AWS Customer Care

  11. Piervincenzo
    March 25, 2010

    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?

  12. Matt
    April 1, 2010

    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.

  13. Antonio Cangiano
    April 1, 2010

    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.

  14. Matt
    April 1, 2010

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

  15. Antonio Cangiano
    April 1, 2010

    Matt, I would consider the open source Keepass.

  16. Philip Tellis
    April 12, 2010

    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.

  17. andy
    April 12, 2010

    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?

  18. Philip Tellis
    April 13, 2010

    @andy: email is not secure

  19. Antonin
    April 19, 2010

    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

  20. Stefano
    March 18, 2012

    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)!”.

Leave a Reply




Back to top
mobile desktop