7 ms·
Why would you have a maxlength on password in the first place?!
by nikanj 6y ago
Why would you have a maxlength on password in the first place?!
- arkadiyt 6y agoIt's common in practice even if it shouldn't be. Also many bcrypt implementations truncate input longer than 72 characters.
- masklinn 6y ago> It's common in practice even if it shouldn't be. It should be though, the backend should reject overlong passwords, and the frontend should have such limits as well. Though by "overlong" I mean kbyte range, not 32 character. The point of the limitation is to avoid randos feeding megabytes of data into your KDF and DOSing your server. > Also many bcrypt implementations truncate input longer than 72 characters. The alternative would be to error as bcrypt works on 18 words (of 32 bits). You need special handling (pre-hashing with a non-broken cryptographic hash function) to fix this issue. Also it's 72 bytes not characters. And your pre-hash needs to generate some sort of textual representation (hex, base64, base85, …), as bcrypt will also truncate at the first NUL byte. The original paper actually specifies 56 bytes.
- Dylan16807 6y agoA kilobyte limit is fine but > The point of the limitation is to avoid randos feeding megabytes of data into your KDF and DOSing your server. You shouldn't be using a KDF that takes significantly longer when the password gets bigger. If you make that mistake, even a kilobyte is going to be annoyingly slow. If you don't make that mistake, then even MAX_POST_SIZE passwords won't DOS you.
- masklinn 6y ago> You shouldn't be using a KDF that takes significantly longer when the password gets bigger. Your KDF necessarily takes longer when the password gets longer as it's a hash function and thus O(n). For typical password sizes (typically under 64 bytes), you're below the hash's blocksize so the effect is nil and you can treat it as a constant but it will start coming into play as the size of the key and thus the number of blocks to feed into the hash increases.
- Dylan16807 6y agoA KDF is not a hash function, and I said "significantly" for a reason. If adding a megabyte of input causes the original megabyte to get hashed or otherwise processed once, then you pass the test. If adding a megabyte of input causes the original megabyte to get fed into your algorithm 100000 times, then you fail the test.
- monadic2 6y agoYou can also trivially truncate to 72 bytes server side.
- Dylan16807 6y agoThat's a horrible thing to do. If you're really paranoid about cryptography then reject it. If you're slightly less paranoid then pass it through SHA512 before bcrypting it. Never silently truncate a password.
- fwip 6y agoWhy not?
- int_19h 6y agoBecause you're misleading the user. Loudly complaining about invalid input is okay, but accepting and silently changing it in a way that affects it properties is not.
- monadic2 6y agoHow would the user tell the 73rd byte is truncated? Might as well call bcrypt itself misleading. In any case this doesn’t preclude client-side validation.
- skosch 6y agoA year after you leave the job, your team is told to build a new auth backend against the database, using a different bcrypt implementation. They just know to use bcrypt, but not about your truncation hack. The deployment is a success. Two weeks later, an angry user (the only one with a 100-digit password) complains that they can't log in anymore. The guy is the company's best-paying customer; the boss is furious. The whole team goes on a wild goose chase for two days and nights just to find out what happened, as clearly there's nothing wrong with their code. A few years later, a former colleague shares the episode on HN. As you read the comments, it dawns on you that the idiot antagonist of the story is you. In this moment, you are enlightened.
- grifball 6y agoIf your password is too long to fit in a hash scheme, then it's probably secure to just truncate and match. Unless the user has little entropy in the first part of their password, which i can't see happening.
- deleted 6y ago[deleted]
- Wowfunhappy 6y ago...I think it's reasonable for there to be some limit, right? Lest a user submit a 50,000 character password?
- cxr 6y agoYou haven't answered the question. > Lest a user submit a 50,000 character password? What's wrong with that?
- 542458 6y agoWe’ll, at a certain point CPU consumption from hashing a sufficiently massive pass would be a concern, no? Like, bcrypt is a pretty slow function, although I don’t know how it scales with input length. Edit: Hunh, apparently bcrypt only handles 72 chars anyways.
- remus 6y agoYou should be doing some fairly expensive hashing if you're storing the password correctly. Maybe not an issue for a 50k char password, but how about a 50 billion char password?
- danaliv 6y agoThis is a backend concern, not a frontend one. The backend shouldn’t naively accept input without making sure the input is within the backend’s limitations.
- oefrha 6y agoClient side validation does not replace server side validation, and vice versa. Just because you validate server side doesn’t mean you can’t also do it client side and avoid a round trip.
- Dylan16807 6y agoI guess? But if someone puts in a ten megabyte password they are either suffering a bug or blatantly screwing with you. It's okay to throw a 400 error at them.
- r00fus 6y agoTruncating at 8 or 12 chars is crazy. Truncating at 30+ is fine but still causes edge cases.
- at_a_remove 6y agoBecause someone would inevitably try to submit a four megabyte password, or an eight gigabyte password, or whatever.
- danaliv 6y agoLimit request size and/or time at the HTTP server, and validate input on the backend.
- beervirus 6y agoSo you don't have to hash a terabyte of data that some DOS'ing asshole sends you.
- deleted 6y ago[deleted]
- tempestn 6y agoMany sites have had unreasonable max length limits on passwords, such as 4, 6, 8, or 12 characters. These unreasonably short limits are bad. However, some seem to take this logic to an extreme, suggesting that even much larger limits are detrimental. Once you get up to say 14-16 random characters or 4-5 random words, with proper hashing, there's just no realistic risk of your password being brute forced. Beyond that you're just wasting effort. And someday it's conceivable you'll need to type that password in on a device where you can't install your password manager; what then? So, giving it plenty of margin; say someone wants to type in 10 10-character words, and round up to 127, or even 255 if you like. I'm going to go on record saying there's no reasonable reason to allow password inputs longer than that in 2020. (And there's no real reason to make passwords nearly that long, but also not much gained by restricting them further.) I welcome responses explaining why passwords of hundreds of characters would ever be necessary or useful.
- sjwright 6y agoMost password managers don't even let you generate passwords longer than 50-100 characters anyway. So long as you're using a password manager that generates unique passwords for every site you visit, there's no real reason to have those generated passwords be particularly long. Ten random characters (with enforced complexity rules) is more than ample for any normal, plausible scenario. If you're a high value individual, you might want to eliminate any doubt and use 12–15 characters. Exceeding that is security masturbation—but also lacks any downside so long as you never have to transcribe it. Or if you fear worldwide retribution, 20 characters is enough to withstand all compute power on earth suddenly dedicated to the task of cracking your Spotify password. The only scenario I can imagine where the length of random+unique passwords matters AT ALL is if (1) the website uses a very weak/naive password hash implementation (2) a hacker manages to acquire a copy of your hashed password and (3) the account is of sufficiently high value to justify a large investment in computing resources to brute force the hash. Hitting that trifecta is very unlikely indeed.