Why do so many companies and people say that your password has to be so long and complicated, just to have restrictions?
I am in the process of changing some passwords (I have peen pwnd and it’s the password I use for use-less-er sites) and suddenly they say “password may contain a maximum of 15 characters“… I mean, 15 is long but it’s nothing for a password manager.
And then there’s the problem with special characters like äàáâæãåā ñ ī o ė ß ÿ ç just to name a few, or some even won’t let you type a [space] in them. Why is that? Is it bad programming? Or just a symptom of copy-pasta?
Is it bad programming?
With very few exceptions, yes. There should be no restrictions on characters used/length of password (within reason) if you’re storing passwords correctly.
A very high max of something like 500 characters just to make sure you don’t get DOSed by folks hitting your endpoint with huge packets of data is about the most I would expect in terms of length restrictions. I’m not a security expert or anything though.
That’s a misunderstanding of DDoS. 0 byte packets are actually worse than large packets.
Which is why most DDoS (at least was) is extremely slow 0 byte requests until the server throttles/crashes under the number of requests.
E: Consider this. Are you more likely to throttle a bandwidth of terabytes/petabytes with couple million 1gb requests; or break it entirely by sending >4294967295 0 byte requests that effectively never stop being requested from the server?
It depends on what the DoS is targeting. If hashing is being done with an expensive hash function you can absolutely cause a lot of resource usage (CPU or memory depending on the hash) by sending long passwords. That being said this likely isn’t a huge concern because only the first round needs to process the whole submitted data, the later rounds only work on the previous round’s output.
Simple empty requests or connection opening attempts are likely to be stopped by the edge services such as a CDN and fleet of caches which are often over-provisioned. A targeted DoS attack may find more success by crafting requests that make it through this layer and hit something that isn’t so overprovisioned.
So yes, many DoS attacks are request or bandwidth floods but this is because they are generic attacks that work on many targets. But that doesn’t mean that all DoS attacks work this way. The best attacks target specific weaknesses in the the target rather than pure brute-force floods.
Well to be fair, if they’re hashing serverside, they were doomed to begin with.
But yeah, there’s a lot of ways to DDoS, and so many tools that just make it a 1 button click.
Who isn’t hashing server-side? That just turns the hash into the password which negates a lot of the benefits. (You can do split hashing but that doesn’t prevent the need to hash server-side.)
Hashing on client side is both more private, and secure. All the user ever submits is a combined hash (auth/pubkey) of their username + password.
If the server has that hash? Check the DB if it requires 2FA, and if the user sent a challenge response. If not, fail the login.
Registering is pretty much the same. User submits hash, server checks DB against it, fail if exists.
Edit: If data is also encrypted properly in the DB, it doesn’t even matter if the entire DB is completely public, leaked, or secured on their own servers.
Underappreciated fact: Bcrypt has a maximum of 72 bytes. It’ll truncate passwords longer than that. Remember that UTF8 encoding of special characters can easily take more than one byte.
That said, this is rarely a problem in practice, except for some very long passphrases.
Bcrypt has a maximum of 72 bytes. It’ll truncate passwords longer than that. Remember that UTF8 encoding of special characters can easily take more than one byte.
Interesting: https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length
In the worst case a password is limited to 18 characters, when every character requires 4 bytes of UTF-8 encoding. For example: 𐑜𐑝𐑟𐑥𐑷𐑻𐑽𐑾𐑿𐑿𐑰𐑩𐑛𐑙𐑘𐑙𐑒𐑔 (18 characters, 72 bytes)Makes me question if bcrypt deserves to be widely used. Is there really no superior alternative?
Not only that, bcrypt could be run by GPUs and FPGA, that makes it more prone to bruteforcing attacks.
There are 2 modern alternatives: scrypt and argon2. They both require a substantial amount of memory, so gpu and hardware computation is no longer feasible.
And then there are times you set a password and everything just seems to work fine, but later the new password never works. You reset the password, try again and really focus because you think you made some mistake with the password manager. Again the password you set does not work.
You begin to google the problem and see that there is a max password lenght of 12. But you always set passwords of the lenght 20-30 and the interface never complained. But because you are desperate, you try just the first 12 characters of the last password you set. And it works!
I hate HP printers.
TL;DR: PayPal had reencrypted their database with a new encryption scheme, but it would accidentally cutout passwords larger than 8 characters. However one person in set their passphrase to “a$$word”, saving the day.
I always thought banks (of all places) had the most ridiculous requirements. What, a 5 character pin to get read access to most of my financial data? Are you kidding me? That’s like securing your bike with a numbers lock
Non-ASCII characters can cause troubles because of different encodings and because you may need to type them on a machine where corresponding keyboard layout is missing.
The password length limit is nothing short of stupid.
I hope you’re using a password manager, I recommend bit warden if not.
Password requirements are all attempts at getting people to introduce entropy into their passwords. The length the characters the not allowed characters the allowed characters. All about adding entropy
Restrictions on allowed characters tend to be based on legacy systems and the input state allow. So if you have an input system that only has Latin characters, it would be foolish to allow non-Latin characters into a password, because then people could get stuck unable to login. So typically they reduce to the safest set of characters that all of their systems use. And for some of the older systems that parse passwords, some of the Meta characters could be problematic.
Password length is also down to legacy systems. If you have an old school Solaris system somewhere in your back end, that truncates password fields at 15 characters. Then 15 characters is the max.
deleted by creator
While most of the time, I remember my password, I know I could just snap and forget it right there at any point. Happened to me not once. And I’m in my 20s. Sometimes when I forget a password, I just start typing and muscle memory kicks in, sometimes it doesn’t. I guess our brains are not optimized to store long random strings of characters. You could use a long sentence as your master password or do as I do:
Come up with a way to make up a long seemingly random password from a couple words. Then if/when you forget a password, just remember those words and reconstruct password from them.
- Don’t use common dictionary words or anything from popular media, as it could be guessed by attackers.
- You can write down algorithm on a piece of paper and keep it somewhere safe.
- Words should be related but not directly:
- two asteroid names - bad
- asteroid name and it’s greek translation - bad
- real city name and city name from a book - good
- two words that both start with S and end with T - good
- If you forget both words, you should be able to remember/look up at least one of them if you still remember how you came up with the word.
deleted by creator
