seven basic rules for developers setting up password systems

  1. If any part of your user interface or code truncates password plaintext input at a length of less than 255 characters, it’s a bug.
  2. If you can’t cope with password plaintexts that contain SPACE and TAB characters (update: or if you impose any charset restrictions) it’s a bug.
  3. If your passwords are not hashed, it’s a bug.
  4. If you’re hashing your passwords with anything other than Bcrypt, it’s a bug; bcrypt() maxes out at 72 character passwords, but that’s not your fault…
  5. If you allow people to use a password of less than 12 characters, it’s a bug.
  6. If you do not encourage people to select a unique password for your service, it’s a bug.
  7. If you do not encourage people to use passphrases, it’s a bug.

Yes, the rules are opinionated. They are even biased and make sweeping assumptions. They don’t even address issues like UNICODE. But if you address these seven points in every application in the world, you’ll make password cracking a phenomenally tougher job.

original context

6 thoughts on “seven basic rules for developers setting up password systems

  1. 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. alecm Post author

    > 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. Pingback: When I wrote Crack I could make three password guesses per second; @BrianKrebs readers plz note #security #hashcat – dropsafe

  4. 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. alecm Post author

      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. Pingback: The solution to password guessability is this… – dropsafe

Leave a Reply