33

When I generated password for GitHub with KeePass I got a message on GitHub site that said the limit for password length is 72 characters. It seemed weird it not being a power of 2 so I googled a bit and it appeared that 72 is the max bytes for brypt algorithm. So it seems logical to restrict the number to 72 as longer passwords would be truncated to 72 anyway.

Then I generated password for Discord and it appeared that the max length is 128 characters. But I thought that I'll check if the first 72 characters from my password would suffice. And yes, my 128 character password is also truncated to 72 first ones, so I guess Discord is also using bcrypt.

So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords (how long? 128, 256 bytes?) even though they will be truncated?

The first criterion is security and only then usability, storage or difficulty of implementation.

Improve this question
6
  • 26
    If you truncate their passwords at 72 characters and they believe they still have to type all 100 and someday they type the last few wrong and still get in what would they think of the system?
    – Hanky Panky
    Commented Feb 27, 2017 at 7:03
  • 5
    To rephrase the general sentiment of the answers, if you need more security than 72 characters can provide your access policy should involve armed guards and vaults rather than passwords over the wire. Also, security at the expense of usability is not secure: it merely encourages users to circumvent policy.
    – Jared Smith
    Commented Feb 27, 2017 at 15:31
  • @JaredSmith I agree with your first point. As for the second one, we're talking about maximal password length. We're not making anybody use such long passwords.
    – user1
    Commented Feb 27, 2017 at 19:13
  • 1
    "The first criterion is security and only then usability" Haven't familiarized yourself with AviD's Rule of Usability, have you?
    – jpmc26
    Commented Feb 28, 2017 at 19:13
  • @jpmc26 I actually have. :-) But imo security should get along with usability and so you have to make compromises. If you only cared about usability you could allow 1-character passwords. It's that you should not only care about security, but also usability. And that's exactly what I'm doing. But +1 for the link. :-)
    – user1
    Commented Mar 1, 2017 at 9:51

2 Answers 2

Reset to default
61

I don't favor silent truncation because it misleads the users into thinking that their entire password was accepted when it wasn't. I'd prefer a system just set a maximum length, if necessary, and restrict the user to that during password input. One bad scenario I've heard of is a code change that begins processing characters beyond the previous max length and suddenly the longer password users can't log in. The system only has a record of the first 72 characters and their longer string doesn't match that without the old system truncation. That leads to frustrated users.

As an alternative to truncation at 72 characters you should consider pre-hashing the password with something like salted SHA-256. The allows the user's entire password string beyond 72 characters to be considered while still providing the computational protection of bcrypt. Please read the linked question and comments below to understand some of the security tradeoffs of this approach.

Improve this answer
10
  • 14
    +1 for mentioning pre-hashing, because the assumption that bcrypt locks you into 72 characters isn't completely true.
    – Xiong Chiamiov
    Commented Feb 27, 2017 at 7:29
  • If you limit the password then limit the input length of the field (with presses beyond 72 being ignored/dismissed), otherwise the user has to randomly guess how long his password is and how much he needs to delete.
    – HopefullyHelpful
    Commented Feb 27, 2017 at 9:42
  • 3
    @HopefullyHelpful how is that different from silent truncation when 1) a user pastes their 200 character password from a password manager into the form or 2) the form is shorter than the maximum character length (likely on small screen devices) and fills with unicode circles giving no visual feedback when it begins truncation
    – Steve Cox
    Commented Feb 27, 2017 at 18:21
  • 2
    @HopefullyHelpful I strongly disagree that that’s a better user experience. If I paste a 100-character password into an input box with a maximum length of 72, I won’t have any idea that truncation has taken place. The page itself will also not be able to warn me, since it can’t tell whether I entered a password of exactly 72 characters or I entered a longer password that was truncated by the browser.
    – bdesham
    Commented Feb 27, 2017 at 19:40
  • 2
    Here is another example from stackoverflow: stackoverflow.com/a/1688236/3771352
    – Christian
    Commented Feb 28, 2017 at 15:26
17

I am usually the person who argues against silly limits but I have to wonder: who seriously uses passwords of over 72 characters? Such a long password would be very impractical to type so it's almost certainly a robot (or ctrl+v from a password manager). Robots* and password managers don't care if they have to remember random alphanumeric strings rather than passphrases.

Assuming they don't use special characters, that is 26+26+10=62 possibilities per character and let's say up to 72 characters. This allows for 62^72 = 1.13*10^129 possibilities. Converting to bits of entropy, a much more manageable number, we get log(62^72)/log(2) = 428.7 bits of entropy.

Last I checked, 256-bit keys are considered reasonable even post-quantum, so this should be plenty.

In the rare event that it is a passphrase, let's take a very standard dictionary: the default one on my Debian system. After some standard pruning (case-insensitivity; removing possessive variants like "horse's" instead of "horse") it contains about 50k words. This math I'm less sure about, but I think this means each word, when randomly picked (as you should with passphrases), gives about log(50000)/log(2)=15.6 bits of entropy. Average word length in general is considered 5 characters, plus a space, so 72 is about 12 words.

This comes down to 15.6*12 = 187.3 bits of entropy in a 72-character passphrase. As a lower bound, because my dict does not contain all words. I'd say you're good.

The real silly limit is bcrypt's 72 characters, but if that's what you've got to work with, I think it's a reasonable limit to set for the users.

* OK, fine, maybe robots would care. Ask me again when the Robot Rights Amendment is there.

Edit: I was answering the title. To address further questions in your post:

So the question is, is it better to just set the password length limit to 72 characters or let users choose longer passwords [...] even though they will be truncated?

Don't silently truncate. There is no advantage in this. Either you will get support requests "boo-hoo I can't use a 105-character password" or eventually someone figures out "OMG I only have to enter the first 56% of my password for it to work what is this crap?!?!?". I think the latter actually has a reasonable point and the former will be extremely rare (if ever).

The first criterion is security and only then usability

I think you might be interested to learn about client side TLS certificates.

Improve this answer
13
  • Wounderful answer, but I will have to nit pick. Different algorithms works differenty on quantum computing. That AES is considered safe does not mean that some other algorithm with similar level of entropy is. But that is a tiny detail not really relevant to the question. As I said, overall great answer.
    – Anders
    Commented Feb 26, 2017 at 21:42
  • @Anders I used AES as an example because basically no entropy is lost when using a key for symmetric encryption (contrary to, say, RSA, where 1024-bit moduli are only 80-ish bits of entropy, due to not every number being an option). I think the meaning of the post doesn't change at all if I just remove the word AES, so let me just go ahead and do that. Thanks for the feedback!
    – Luc
    Commented Feb 26, 2017 at 23:45
  • 1
    For AES the Grover algorithm allows a speed up of O(√n). which, given a key size of n bits, thus a search size of 2^n an effective search of √2^n = 2^(n/2). The effective size of the key (if you were to compare to a pre-quantum size) is divided by 2, so AES-256 would become as strong as pre-quantum AES-128
    – J.A.K.
    Commented Feb 27, 2017 at 0:00
  • 3
    That said, i have absolutely no idea what effect quantum cryptanalysis will have on BCrypt. Let me go figure it out.
    – J.A.K.
    Commented Feb 27, 2017 at 0:17
  • 2
    @J.A.K. Grover's algorithm means that symmetric keylengths need to double, and hash functions that need to resist collisions need to be increased 50% because the birthday attack works at 1/3 length instead of 1/2. And of course all algorithms based on factorization or other abelian hidden subgroup problems become worthless.
    – Charles
    Commented Feb 27, 2017 at 20:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .