Comments

6 responses to “seven basic rules for developers setting up password systems”

1. 2011/10/22

   Clive

   Sweeping seems an understatement. Personally, I use a range of passwords varying between “insecure” and three-of-five keyshares of a 4096-bit RSA key kept passphrased in geographically separate locked buildings.

   I would have thought rules like “if you allow unlimited retries without activating elevated security checks, it’s a bug”, “if you forget to make at least one user exempt from that, for DoS avoidance purposes, it’s a bug”, “if your passwords ever touch wire in the clear, it’s a bug”, “if you leak passwords (including non-existant usernames which might have been passwords put in the wrong box) to logfiles, it’s a bug”, “if you insist on the password being a fact that’s trivially discoverable, it’s a bug”, “if you hash passwords but don’t also protect them from prying eyes, it’s a bug” were more important, given the howlers I’ve seen people make.

   Reply
2. 2011/10/22

   alecm

   > Sweeping seems an understatement

   You’re not my target audience. To borrow a phrase, you’re the 1%.

   > if you allow unlimited retries without activating elevated security checks, it’s a bug

   Leads to developers implementing http://www.crypticide.com/article/42

   > if you forget to make at least one user exempt from that, for DoS avoidance purposes, it’s a bug

   1) special cases are bad 2) if you exempt the superuser, it’s a route for me to guess passwords willy-nilly thereby defeating the object of the exercise 3) it’s still a DoS of everyone else.

   > if your passwords ever touch wire in the clear, it’s a bug

   Good point, but I considered networking, like Unicode, to be out of scope.

   > if you leak passwords (including non-existant usernames which might have been passwords put in the wrong box) to logfiles, it’s a bug

   Ditto.

   > if you hash passwords but don’t also protect them from prying eyes, it’s a bug

   I wasn’t going to get into that. Hashes and good passwords should be able to stand up on their own, albeit I agree with you. The goal is that an attacker should not be able to get anywhere even if they get a copy of the password directory.

   Reply
3. 2012/06/13

   When I wrote Crack I could make three password guesses per second; @BrianKrebs readers plz note #security #hashcat – dropsafe

   […] Hateful, isn’t it? But this is what needs to be done on the user end; and as Tom clearly says the baseline for what needs be done on the server end can be expressed as use bcrypt() or better – although I prefer to push that a little bit further in terms of user interface requirements. […]

   Reply
4. 2012/08/02

   KJS3

   4) Bcrypt may be a good answer, it *might* even be the best (though Bruce has been hemming and hawing about it being time to consider retiring Blowfish), but it’s not the only good answer (see: scrypt). The point I try and drive home to my developers is never, ever roll your own, and always, always use a mature, well vetted, open solution.

   5) Would you rather users picked a good 9 character password or a bad 12 character password? I haven’t figured the right number yet, but my subjective experience has been that there’s a point of diminishing returns in forcing password length with users where if it’s too long, they spend more time figuring out how to feed the system a bad password that’s easy for them to remember. I’ve got no objective data to back that up, however. We try very hard to educate users on why log passwords are important and how to pick good ones.

   Otherwise…spot on.

   Reply
   1. 2012/08/02

      alecm

      4) Yep. Just build scrypt’s brand. I have a long rant somewhere about crypto as a branding exercise, I should dig it out.

      5) re:

      “Would you rather users picked a good 9 character password or a bad 12 character password?”

      – that’s not a useful question, as users (to a fair approximation) cannot be trained to structure a “good” password, and frankly such structuring will reduce keyspace, so overall I am going for 16-or-longer, and am speaking my own users exclusively in terms of 20+ character PASSPHRASES to protect password-management DATABASES, each password WITHIN which is a 16 character nonce.

      Then all they have to do is remember one good, long passphrase; and change it annually because I am a bastard to them.

      Reply
5. 2012/11/14

   The solution to password guessability is this… – dropsafe

   […] And finally: seven basic rules for developers setting up password systems […]

   Reply