31

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.

user1
  • 441
  • 4
  • 10
  • 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 Feb 27 '17 at 07: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 Feb 27 '17 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 Feb 27 '17 at 19:13
  • 1
    "The first criterion is security and only then usability" Haven't familiarized yourself with [AviD's Rule of Usability](http://security.stackexchange.com/a/6116/46979), have you? – jpmc26 Feb 28 '17 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 Mar 01 '17 at 09:51
  • @user1 I have no objection to balancing security and usability. I'm just saying that they are equally important concerns, and neither should be elevated as fundamentally more important than the other, primarily because if you make doing the right thing hard, users will do the wrong thing. – jpmc26 Mar 01 '17 at 16:42

2 Answers2

58

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.

PwdRsch
  • 8,341
  • 1
  • 28
  • 35
  • 14
    +1 for mentioning pre-hashing, because the assumption that bcrypt locks you into 72 characters isn't completely true. – Xiong Chiamiov Feb 27 '17 at 07: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 Feb 27 '17 at 09: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 Feb 27 '17 at 18:21
  • It's just a lot better user experience, but on the otherhand 72 characters is going to be rare. But I always hated, utterly hated sites that have a 18 character limits and don't do this. What if I can memorize that 19-25 character password a lot better and I just type it for myself cause thats how I remember it ? You want to force me to think of a password that is exactly 18 characters ? I'm just gonna shit on security on your site and not care, because I can either remember that 8 character password or a 19-22 character one. Stupid inconvenience is a high security risk for normal customers. – HopefullyHelpful Feb 27 '17 at 19:11
  • 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 Feb 27 '17 at 19:40
  • Like I said for 72 it's not going to matter, you will only fill that with copy paste. For less high upper bounds it can actually be useful. – HopefullyHelpful Feb 27 '17 at 19:53
  • @XiongChiamiov Well, technically speaking bcrypt **does** locks you into 72 characters. Using sha-256 to turn a longer password to a shorten one does not create a new "password slot for bcrypt" out of think air. If you are generating the passwords completely randomly (without limiting the character set) it does not make sense to use more than 72 characters and pre-hashing. However it helps if the password is not random or the character set is limited (e.g. a very long passphrase, even if not completely random can achieve the equivalent entropy of 72 purely-random characters by pre-hashing). – Bakuriu Feb 27 '17 at 20:52
  • 2
    Here is another example from stackoverflow: http://stackoverflow.com/a/1688236/3771352 – Christian Feb 28 '17 at 15:26
  • For `The first criterion is **security**`, **do not pre-hash** the password because it is dangerous. It is suffered by "Password Shucking", which uses insecure password hash from existing breaches to crack pre-hashed bcrypt hash. https://scottbrady91.com/Authentication/Beware-of-Password-Shucking It is also mentioned in OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pre-hashing-passwords – ypresto Sep 04 '21 at 18:18
  • My understanding is that pre-hashing without salt only adds a small risk in the case of common or reused passwords that have appeared in other leaks with the same hash. Instead of an attacker running their wordlist and hybrid guesses against each Bcrypt hash, they run their list of simple hashes and then target any matches for cracking. So it provides a time savings for the 'lower hanging fruit' passwords but doesn't undermine the security of all of them. However, I'm happy to edit my answer to specifically recommend using a salt with your pre-hash. – PwdRsch Sep 29 '21 at 23:57
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.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 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 Feb 26 '17 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 Feb 26 '17 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. Feb 27 '17 at 00:00
  • @J.A.K. That's indeed what I based that statement on. It holds for other things as well right? Like, to my knowledge it has nothing to do with AES or symmetric encryption specifically. – Luc Feb 27 '17 at 00:08
  • 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. Feb 27 '17 at 00:17
  • I don't think your dictionary is a good choice for passphrase generation – many words in there will be too similar to each other to memorize. A 1000–2000 word dictionary would be more plausible. – Paŭlo Ebermann Feb 27 '17 at 15:27
  • @PaŭloEbermann You mean words like abdicate, abdication, abdicated, abdicating, etc.? As in, one would construct a dictionary that contains only the base version of a word to make it easier? Because I'm not 100% convinced it's much easier to remember, but even if it were, I get to 35660 words, and that excludes things like any words ending in an s (to remove plural words) which probably removed a lot of false-positives (non-plural words that happen to end in an s, like stress). – Luc Feb 27 '17 at 17:15
  • 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 Feb 27 '17 at 20:23
  • @Charles An 15424-bit RSA key is said to be roughly equivalent to 256-bit symmetric keys. If I understand you correctly, you're saying that anything relying on factorization hardness will be broken? Even if one would be using 15kb keys? (Not talking about the practicality of such a thing, just the possibility.) – Luc Feb 28 '17 at 08:00
  • @Luc Pretty much. Beauregard's version of Shor's algorithm would require only 30k qubits to factor such a key, and the time required is reasonable (cubic). I think there's an improved version which halves the qubit requirement at the expense of giving the output one bit at a time. Once there are quantum computers I would immediately move away from all factorization-based crypto (if I wasn't off already) because you don't know how quickly quantum computing will develop. – Charles Feb 28 '17 at 08:09
  • Found it! The n+1 qubit algorithm is here: https://arxiv.org/abs/1507.08852 – Charles Feb 28 '17 at 08:17
  • Thanks for the actual cryptographer(ish) answer with mentioning entropy and such. Another +1 for the subtle reference to XKCD :) – W00d5t0ck Feb 28 '17 at 08:30
  • @Luc Wrong thread by failure to read. My apologies. Deleted. – jpmc26 Feb 28 '17 at 19:12