There’s a special place in hell for those who set an upper limit in password lengths.
I sort of get it. You don't want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
16 characters is too low. I'd say a good upper limit would be 100, maybe 255 if you're feeling generous.
The problem is that you (hopefully) hash the passwords, so they all end up with the same length.
At minimum you need to limit the request size to avoid DOS attacks and such. But obviously that would be a much larger limit than anyone would use for a password.
Also rate of the requests. A normal user isn't sending a 1 MiB password every second
What's a sensible limit. 128 bytes? Maybe 64?
I'd say 128 is understandable, but something like 256 or higher should be the limit.
64, however, is already bellow my default in bitwarden
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it's no longer your problem but the browser's. 🦹
Why are you hasing in the browser?
Also, what hashing algorithm would break with large input?
Damm, I legit didn't knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt
Scrypt has the same limit, FWIW.
It doesn't matter too much. It's well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won't get that long. If you're really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn't really matter.
Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.
Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can't trust the client that much.
You can hash the password on both sides to make it work; though I'm not sure why you'd want to. I'm not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?
Because then that means you don't salt your hashes, or that you distribute your salt to the browser for the hash. That's bad.
You could salt it. Distributing a unique salt doesn't help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.
It's one of those things in security where there's no particular reason to give your attacker information, but if you've otherwise done your job, it won't be a big deal if they do.
You don't hash in the browser because it doesn't help anything.
It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn't bad if you're using good password hygiene with random passwords, but that sadly is not the norm.
It doesn't. It just means the attacker can send the hash instead of the password.
For that particular website yes, but a salted client side hash is worthless on a different website.
Edit: plus even unsalted it would only work if the algorithm is the same and less iterations are done
If the end user is reusing passwords. Which, granted, a lot of people do.
On the flip side, we're also forcing the use of JavaScript on the client just to handle passwords. Meanwhile, the attack we're protecting against only works for reused passwords, and the attacker is inside the server and can see the password after transport layer encryption is removed. This is a pretty marginal reason to force the complexity of JavaScript.
With comments like this all over public security forums, it's no wonder we have so many password database cracks.
Per your edit, you're misunderstanding what Bitwarden does and why it's different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you've stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It'd be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn't like that. They have to actually match your transmitted password against what's in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
If you hash in the browser it means you don't salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
There's nothing stopping a browser from salting a hash. Salts don't need to be kept secret, but it should be a new random salt per user.
If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
That's not true. If they send hashed password you could salt/hash again on server if you're trying to keep the salt "secret". Their hash should always be the same if they've submitted the same password. You'd just be hashing a hash in that case... but it's the same premise.
The eBay password limit is 256 characters.
They made the mistake of mentioning this when I went to change my password.
Guess how many characters my eBay password has?
-1?
Damn signed bytes!
Just paste it in here and I count the characters for you.
69
oh yeah
I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
You don't store the original text. You store the hash of it. If you SHA512 it, anything that's ever given in the password field will always be 64Bytes.
The only "legit" reason to restrict input to 16 character is if you're using an encryption mechanism that just doesn't support more characters as an input. However, if that's the case, that's a site I wouldn't want to use to begin with if at all possible.
The resulting hash will always be the same size, but you don't want to have an unlimited upper bound otherwise I'm using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
If I choose to make you hash it in browser first... Then I simply don't care do I? I can hash/salt again when I get your hash.
Edit: There are other answers to the "DDOS problem" that don't require upper bounds.
You can make a client hash it, but if you don't reject large inputs to your API a client can send enough data to DOS you anyway.
And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What's your point.
The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn't make that any less true.
Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?
You were saying the input size doesn't matter because you only store the hash which is always the same size. What I'm saying is that the input size really does matter.
You absolutely should set upper limits on all input fields because it will be abused if you don't. Systems should validate their inputs, passwords included
And I showed you a way that we can make it so it doesn't matter.
Force local hash -> Hash/salt what you get. Password can be a million characters long. You'll only ever get like 128 characters.
Nothing I talked about said to not validate inputs. Just that we don't have to limit a persons password selection.
I'll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.
Depending on where you're doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don't remember what that number is but it certainly isn't in the thousands.
That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point.
That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we're using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428...) characters. After that you're losing data in the hashing process and by that effect it would be negligible... (There's some wiggle room here in that we can't type hidden ASCII characters so some passwords over 73 characters would fill those spaces... but detecting collisions is silly and non-trivial... better to just not worry about those at all.)
Extended ASCII would be same premise, just 64 characters instead of 73.
The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords... 64 characters is a good number to max out most of them. Databases don't need to store much at all regardless of the length of your actual password. If you're developing an app you can set the database to limit based on the algorithms you're using. If you have no idea what the web-dev will actually use... then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords... that's irrelevant and trivial for storage as hashes.
There's a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That's impossible to break due to thermodynamic limits on computing.
The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn't seem like that would be significant unless your backend was poorly made.
Yeah but what if I have one user with 9.9 million accounts? That bastard
Oh and also, "change this every four weeks please."
Okay then. NEW PASSWORD: pa$$word_Aug24
Invalid password, maximum 13 characters.
pa$$word0824
Only a maximum of 3 digits allowed
Yep. Having to have requirements that doesn't flow with people very well and requiring constant updates, people WILL find shortcuts. In the office, I've seen sheets of paper with the password written down, I've seen sticky notes, I've seen people put them in notepad/word so they could just copy paste.
This is made worse, because you have to go out of your way for a password manager, which means you need to know what that is. And you need a good one because there has been (and I'm going to generalize here) problems with some password managers in the past. And for work, they have to allow a password manager for that to even be an option. Which you then end up with this security theater.
And you need a good one because there has been problems with some password managers in the past.
coughLastPasscough
“Problems”. What an delightfully understated term to use.
the password cannot contains the same sequences of characters as the old password.
and i have seen this requirement in a service that requires changing it every month for some reasons.
and this is to manage a government digital identity that allows to log it in all governments websites.
the password cannot contains the same sequences of characters as the old password.
That's a weird way to say "we store your password in plaintext"
Not necessarily. Presumably the change password form requires entering the old and new password at the same time. Then they can compare the two as plain text and hash the old password to make sure it matches, then if so, hash the new password and overwrite it. Passwords stored hashed, comparison only during the change process. A theme on this is checking password complexity rules during the login process and advising to update to something more secure. It's possible because you're sending the password as plain text (hopefully over a secure connection), so it can be analysed before computing the hash. This even works if the hash is salt and peppered.
Reasonable upper limits are OK. But FFS, the limit should be enough to have a passphrase with 4 or 5 words in it.
Usually 256 bit hash is used. 256 bits is 32 bytes or 32 characters. Of course you are losing some entropy because character set is limited, but 32 characters is beyond reasonable anyway.
The eff passphrase generator has about 2.5 bits of entropy per character (without word separators). Eff recommends 6 word passphrases, and with an avg word length of 7, that's (only) 79.45 bits of entropy that won't even fit in the 32 characters. If there wasn't a password length limit it would be possible to saturate the hash entropy with a 20+ word & 102+ char passphrase.
Of course, but that's because you are using a passphrases. Passwords have a much hogher entropy.
I'd be totally fine woth 32 characters! But I've come across too many websites with unreasonably short (20 characters or less) limits.
Just opened a PayPal account and their limit is 20. Plus the only 2fa option is sms 🙃.
I just double checked and I have TOTP enabled for my PayPal account so it should be an option.
I just found this support article of theirs and it says it can only be enabled through their website and not through the app (why?!) so you might be running into that?
Probably people would struggle to scan the QR Code with their smartphone. I think most apps can scan it from a image but obviously this would be unsafe, especially when people sync their screenshot to the cloud.
I can 100% confirm totp exist for PayPal, because I'm using it.
That last part definitely isn't true.
I personally have a Yubikey and OTP for mine. Maybe they don't for your country?
That said, fuck PayPal.
Basically guaranteed to be a clear text offender
"Your password needs to be less than 65k characters long" >:(
Darn, can't use the entire Bee Movie on Blu-Ray as my password then.
I mean you could compress it
Especially since it takes more effort to limit it than leave it wide open for whatever length of password a user wants to use.
nvarchar(max) is perfect to store the hashed copy.
English letters? Really? So basically no a-z, only Æ, Þ, Ƿ, Ð?
Ye olde passwarde
What have the Romans ever done for us?
Roads?
Well, yeah. Obviously the roads. I mean, the roads go without saying, don’t they? But apart from the sanitation, the aqueducts, and the roads…
Irrigation!
I need to rewatch this, it's been too long.
All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?
You remind me of my bank about 17 years ago. Everyone had to have a 10-character password, exactly, and it had to include exactly 2 numbers and 1 symbol. I wasn't very knowledgeable about computers at the time and it already felt dumb.
A few years ago my ISP pushed an update to my router that changed the password requirements, invalidating my passwords. Because I couldn't enter the old password I also couldn't change the password. I had to do a factory reset.
Feels odd to check the password requirements on the enter password screen in addition to the new password screen.
Might be checking the old password on the new password screen. Easy programming mistake to make I guess? Apply the same validation to all 3 password fields...
Ahhh, good catch! You are probably a master of code reviews and QA!
Wow that's a big oops
ISP worker here. Our chosen routers default to an 8 digit password, the first 4 are the last 4 of the mac in hex, which anyone can easily see being broadcast by the wifi network. The last 4 are a part of a unique serial number, but its just 0-9. Ultimately, if you try to brute force this default password, you need 10000 tries. It takes a regular GPU 2 minutes with hashcat. It baffles my mind that companies think this is OK.
17 years ago, jeez. My credit Union's website is like that. Only its between 8-12 characters. No more, no less.
It's terrifying.
At that time my bank allowed up to 6 digits as a password. I kid you not, like a card PIN but for online banking login. I believe the whole banking security relies on their backoffices still running on paper.
That's what my current bank uses for the web portal now to think of it. Client number, and 6-number PIN. I guess they're only doing this because they really trust their "unusual activity" protocols, but I've got a feeling they really shouldn't only rely on those.
underlines
german programmers trying to translate Unterstrich
My unterstrich is chafed.
/^\w{6,16}$/
Those cases where an english word gets absorbed even though no one from the origin talks like that. It's also informally called underline here in Brazil lol.
I had one of those “fancy” Vodafone routers included with my broadband which had a stupid rule set on choosing the WiFi password. It’s my network, not yours, stupid router. It can be as insecure as I want.
Anyway the rules were enforced by the JavaScript so it was easy to bypass until I got my own router to replace it with.
It's important to note, that these things are designed for the average user. If you want to change the wifi password, you are by far not an average user. Most users just plugs in and never even think about that, and the number of that kind of users are several order of magnitude higher than the conscious ones. For them it's much more secure to set a random pw. If you let them select a password they will choose 12345 or password.
If you know what you are doing usually it's better to buy your own router where you can change everything the way you like.
If we could magically get the data I'd be willing to bet at least half of everyone thinks they can't change their router password.
Create a randomly generated password and store it in a password manager
Assuming we can use both lower- and uppercase letters (52 in total), with the ten digits and the underscore that gives us 63 characters to work with. A random 16-character combination of these gives us 95 bits of entropy (rounding down), which is secure enough by modern standards, at least for a home router.
Regardless, I understand the frustration of arbitrary limitations preventing you from choosing a secure password in a way that you're comfortable with.
Not allowing 20 character passwords is criminal, my bank does this.
Lol. Imagine thinking TP Link takes security seriously.
16 characters was the minimum length a password should be due to how easy it was to crack… something like a decade ago.
Now it’s something like 20 to 24 characters.
Seriously, if your company is defining maximum password length and demanding specific content, it is failing at the security game. Have the storage location accept a hashed UTF-8 string of at least 4096 bytes - or nvarchar(max) if it’s a database field - and do a bitwise complexity calculation on the raw password as your only “minimum value” requirement.
Look at how KeePass calculates password complexity, and replicate that for whatever interface you are using. Ensure that it is reasonable, such as 150-200bit complexity, and let users choose whatever they want to achieve that complexity.
It's TPLink. Budget networking equipment comes with budget security principles.
TP-Link.... TP-Link...
I don't trust your bottom barrel software, TP-Link...
True trash-tier software and hardware. Last year I was having trouble with frequently dropped packets from my office computer. I thought it was a Spectrum issue until I tore everything out and started testing all my ports (modem, router, wall ports, etc). I FINALLY narrowed it down to the relatively new TP-Link dumb router I bought. I threw that piece of trash in the garbage.
Never again.
admin wouldn't even work. It's too short.
Username admin
Password password
As is tradition
Like my router that defaulted to
Root
Root
One of mine defaulted to root with no password set.
"adimin"
I hate that kind of stuff, when I see this I wonder if they hash the password at all
It's because of shit like this, I've had a document containing all passwords and accounts stashed away.
I'm going to copy and paste, fuck anyone thinking I'm going to manually enter their shit.
Why not just use password manager?
not as portable
I ran into the same issue, I didn't want to use a cloud password manager because entrusting literally every password I have to a third party and on the internet sounds absurd to me. KeePass seemed like a good idea for me, but at the time I fell back to syncing the vault by sending it to myself in Telegram any time I made a change. Certainly not ideal
I now just have an RPi self hosting Vaultwarden with Tailscale, and for me that's been the best solution that keeps me happy; it's more secure as someone needs to compromise my Tailnet first, it's not public facing, I'm not trusting a third party to not lose my vault (a la LastPass), but its still convenient.
Keepass and syncthing are great combined. Functions fully locally even when I have no access to my home network, and changes get synced between my desktop, laptop, and phone whenever I have WAN access.
Yeah, I probably would have gone with that solution if I knew about it at the time, but now that I have Vaultwarden I'm pretty happy with it.
How do you handle (and test) backups?
I'm gonna be honest, for Vaultwarden I don't. However, a local cached copy of the vault exists on all my devices that are signed in via the official Bitwarden client, and I have recovered using this method before, so that's my backup strategy.
Seems fair. I was just wondering since I was considering vault warden or keypass + sync thing.
I use a keepass vault thrown in a syncthing directory but like literally any file sync will do. If you get conflicts, KeePassXC can merge them
Yeah, I'm with you on that. Everyone on Lemmy loves password managers, but I don't really like the idea of entrusting all of my passwords for everything with one singular program. I actually also dislike 2 factor authentication. One time my phone broke and my bank wanted to verify my identity to purchase a new phone. Except my phone was broken so I couldn't... Yeah I really don't want to run into that scenario again except worse.
I've actually gone old school with it and I keep most passwords physically written down in a notebook using my own cypher language/pictograms. If someone irl really wants to break into my home, find the notebook, and try to decode it, I'd be in bigger trouble to begin with. It's very unlikely.
2 factor when done right is nice, however phones should Never be a requirement for anything and 2fa should require at least two physical keys before being allowed to be enabled.
Take a string as bytes is bad with weird non-ASCII characters. Been there, been bitten in the ass by it.
At least with e-mail clients different clients on different operating systems use different encoding by default for their passwords.
With a router I could imagine different client apps following different standards.
You don't have to take arbitrary bytes. UTF-8 encoded strings are just fine and easily handled by libraries.
At least with e-mail clients different clients on different operating systems use different encoding by default for their passwords.
The manufacturer obviously also makes the app and can control the encoding.
With a router I could imagine different client apps following different standards.
Many routers can also be controlled via Telnet, which will also use different encodings depending on your OS.
Y'all use UTF8? laughs in Japanese websites
/ can we please stop EUC-JP and SJIS and MS932 and all just switch to UTF8, please, Japan?!
There’s a special place in hell for those who set an upper limit in password lengths.
I sort of get it. You don't want to allow the entire work of Shakespeare in the text field, even if your database can handle it.
16 characters is too low. I'd say a good upper limit would be 100, maybe 255 if you're feeling generous.
The problem is that you (hopefully) hash the passwords, so they all end up with the same length.
At minimum you need to limit the request size to avoid DOS attacks and such. But obviously that would be a much larger limit than anyone would use for a password.
Also rate of the requests. A normal user isn't sending a 1 MiB password every second
What's a sensible limit. 128 bytes? Maybe 64?
I'd say 128 is understandable, but something like 256 or higher should be the limit. 64, however, is already bellow my default in bitwarden
And sure, in theory your hashing browser-side could break if you do that. Depending on how much text the user pastes in. But at that point, it's no longer your problem but the browser's. 🦹
Why are you hasing in the browser?
Also, what hashing algorithm would break with large input?
bcrypt has a maximum password length of 72 bytes.
https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length
Damm, I legit didn't knew there bcrypt had a length limit! Thank you for another reason not to use bcrypt
Scrypt has the same limit, FWIW.
It doesn't matter too much. It's well past the point where fully random passwords are impossible to brute force in this universe. Even well conceived passphrases won't get that long. If you're really bothered by it, you can sha256 the input before feeding it to bcrypt/scrypt, but it doesn't really matter.
Why would you not hash in the browser. Doing so makes sure the plaintext password never even gets to the server while still providing the same security.
Edit: I seem to be getting downvoted... Bitwarden does exactly what I described above and I presume they know more than y'all in terms of security https://bitwarden.com/help/what-encryption-is-used/#pbkdf2
Because then the hash is the password. Someone could just send the hash instead of trying to find a password that gets the correct hash. You can't trust the client that much.
You can hash the password on both sides to make it work; though I'm not sure why you'd want to. I'm not sure what attack never having the plain text password on the server would prevent. Maybe some protection for MITM with password reuse?
Because then that means you don't salt your hashes, or that you distribute your salt to the browser for the hash. That's bad.
You could salt it. Distributing a unique salt doesn't help attackers much. Salt is for preventing precomputing attacks against a whole database. Attacking one password hash when you know the salt is still infeasible.
It's one of those things in security where there's no particular reason to give your attacker information, but if you've otherwise done your job, it won't be a big deal if they do.
You don't hash in the browser because it doesn't help anything.
It helps against the server being able to read the password, so a bad actor (either the website itself or after a hack) could read your password. Which isn't bad if you're using good password hygiene with random passwords, but that sadly is not the norm.
It doesn't. It just means the attacker can send the hash instead of the password.
For that particular website yes, but a salted client side hash is worthless on a different website.
Edit: plus even unsalted it would only work if the algorithm is the same and less iterations are done
If the end user is reusing passwords. Which, granted, a lot of people do.
On the flip side, we're also forcing the use of JavaScript on the client just to handle passwords. Meanwhile, the attack we're protecting against only works for reused passwords, and the attacker is inside the server and can see the password after transport layer encryption is removed. This is a pretty marginal reason to force the complexity of JavaScript.
With comments like this all over public security forums, it's no wonder we have so many password database cracks.
Per your edit, you're misunderstanding what Bitwarden does and why it's different than normal web site password storage.
Bitwarden is meant to not have any insight into your stored passwords what so ever. Bitwarden never needs to verify that the passwords you've stored match your input later on. The password you type into Bitwarden to unlock it is strictly for decrypting the database, and that only happens client side. Bitwarden itself never needs to even get the master password on the server side (except for initial setup, perhaps). It'd be a breach of trust and security if they did. Their system only needs to store encrypted passwords that are never decrypted or matched on their server.
Typical website auth isn't like that. They have to actually match your transmitted password against what's in their database. If you transmitted the hashed password from the client and a bad actor on the server intercepted it, they could just send the hashed password and the server would match it as usual.
If you hash in the browser it means you don't salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.
There's nothing stopping a browser from salting a hash. Salts don't need to be kept secret, but it should be a new random salt per user.
That's not true. If they send hashed password you could salt/hash again on server if you're trying to keep the salt "secret". Their hash should always be the same if they've submitted the same password. You'd just be hashing a hash in that case... but it's the same premise.
The eBay password limit is 256 characters.
They made the mistake of mentioning this when I went to change my password.
Guess how many characters my eBay password has?
-1?
Damn signed bytes!
Just paste it in here and I count the characters for you.
69
oh yeah
You don't store the original text. You store the hash of it. If you SHA512 it, anything that's ever given in the password field will always be 64Bytes.
The only "legit" reason to restrict input to 16 character is if you're using an encryption mechanism that just doesn't support more characters as an input. However, if that's the case, that's a site I wouldn't want to use to begin with if at all possible.
The resulting hash will always be the same size, but you don't want to have an unlimited upper bound otherwise I'm using a 25GB blueray rip as my password and your service is going to have to calculate the hash of that whenever I login.
Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.
If I choose to make you hash it in browser first... Then I simply don't care do I? I can hash/salt again when I get your hash. Edit: There are other answers to the "DDOS problem" that don't require upper bounds.
You can make a client hash it, but if you don't reject large inputs to your API a client can send enough data to DOS you anyway.
And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What's your point.
The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn't make that any less true.
Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?
You were saying the input size doesn't matter because you only store the hash which is always the same size. What I'm saying is that the input size really does matter.
You absolutely should set upper limits on all input fields because it will be abused if you don't. Systems should validate their inputs, passwords included
And I showed you a way that we can make it so it doesn't matter.
Force local hash -> Hash/salt what you get. Password can be a million characters long. You'll only ever get like 128 characters.
Nothing I talked about said to not validate inputs. Just that we don't have to limit a persons password selection.
I'll admit I kind of typed this without thinking it through. In a secured site, the password would be hashed and salted before storing in the database.
Depending on where you're doing the hashing, long strings might still slow you down. That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point. I don't remember what that number is but it certainly isn't in the thousands.
That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we're using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428...) characters. After that you're losing data in the hashing process and by that effect it would be negligible... (There's some wiggle room here in that we can't type hidden ASCII characters so some passwords over 73 characters would fill those spaces... but detecting collisions is silly and non-trivial... better to just not worry about those at all.)
Extended ASCII would be same premise, just 64 characters instead of 73.
The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords... 64 characters is a good number to max out most of them. Databases don't need to store much at all regardless of the length of your actual password. If you're developing an app you can set the database to limit based on the algorithms you're using. If you have no idea what the web-dev will actually use... then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords... that's irrelevant and trivial for storage as hashes.
There's a more practical limit. Using US standard keyboard symbols, a 40 char password is about as secure as a 256-bit block cipher key. That's impossible to break due to thermodynamic limits on computing.
The reason to put a high char limit is to mitigate DoS attacks. It can still be a few hundred chars.
Even 255 bytes with 10 million entries is only ~2.6GB of data you need to store, and if you have 10 million users the probably $1 a month extra that would cost is perfectly fine.
I suppose there may be a performance impact too since you have to read more data to check the hash, but servers are so fast now it doesn't seem like that would be significant unless your backend was poorly made.
Yeah but what if I have one user with 9.9 million accounts? That bastard
Account georg
Oh and also, "change this every four weeks please."
Okay then. NEW PASSWORD: pa$$word_Aug24
Invalid password, maximum 13 characters.
pa$$word0824
Only a maximum of 3 digits allowed
Yep. Having to have requirements that doesn't flow with people very well and requiring constant updates, people WILL find shortcuts. In the office, I've seen sheets of paper with the password written down, I've seen sticky notes, I've seen people put them in notepad/word so they could just copy paste.
This is made worse, because you have to go out of your way for a password manager, which means you need to know what that is. And you need a good one because there has been (and I'm going to generalize here) problems with some password managers in the past. And for work, they have to allow a password manager for that to even be an option. Which you then end up with this security theater.
coughLastPasscough
“Problems”. What an delightfully understated term to use.
the password cannot contains the same sequences of characters as the old password.
and i have seen this requirement in a service that requires changing it every month for some reasons.
and this is to manage a government digital identity that allows to log it in all governments websites.
That's a weird way to say "we store your password in plaintext"
Not necessarily. Presumably the change password form requires entering the old and new password at the same time. Then they can compare the two as plain text and hash the old password to make sure it matches, then if so, hash the new password and overwrite it. Passwords stored hashed, comparison only during the change process. A theme on this is checking password complexity rules during the login process and advising to update to something more secure. It's possible because you're sending the password as plain text (hopefully over a secure connection), so it can be analysed before computing the hash. This even works if the hash is salt and peppered.
Reasonable upper limits are OK. But FFS, the limit should be enough to have a passphrase with 4 or 5 words in it.
Usually 256 bit hash is used. 256 bits is 32 bytes or 32 characters. Of course you are losing some entropy because character set is limited, but 32 characters is beyond reasonable anyway.
The eff passphrase generator has about 2.5 bits of entropy per character (without word separators). Eff recommends 6 word passphrases, and with an avg word length of 7, that's (only) 79.45 bits of entropy that won't even fit in the 32 characters. If there wasn't a password length limit it would be possible to saturate the hash entropy with a 20+ word & 102+ char passphrase.
Of course, but that's because you are using a passphrases. Passwords have a much hogher entropy.
I'd be totally fine woth 32 characters! But I've come across too many websites with unreasonably short (20 characters or less) limits.
Just opened a PayPal account and their limit is 20. Plus the only 2fa option is sms 🙃.
I just double checked and I have TOTP enabled for my PayPal account so it should be an option.
I just found this support article of theirs and it says it can only be enabled through their website and not through the app (why?!) so you might be running into that?
https://www.paypal.com/uk/cshelp/article/what-is-2-step-verification-and-how-do-i-turn-it-on-or-off-help167
Probably people would struggle to scan the QR Code with their smartphone. I think most apps can scan it from a image but obviously this would be unsafe, especially when people sync their screenshot to the cloud.
I can 100% confirm totp exist for PayPal, because I'm using it.
That last part definitely isn't true.
I personally have a Yubikey and OTP for mine. Maybe they don't for your country?
That said, fuck PayPal.
Basically guaranteed to be a clear text offender
"Your password needs to be less than 65k characters long" >:(
Darn, can't use the entire Bee Movie on Blu-Ray as my password then.
I mean you could compress it
Especially since it takes more effort to limit it than leave it wide open for whatever length of password a user wants to use.
nvarchar(max)is perfect to store the hashed copy.English letters? Really? So basically no a-z, only Æ, Þ, Ƿ, Ð?
Ye olde passwarde
What have the Romans ever done for us?
Roads?
Well, yeah. Obviously the roads. I mean, the roads go without saying, don’t they? But apart from the sanitation, the aqueducts, and the roads…
Irrigation! I need to rewatch this, it's been too long.
All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?
Brought peace?
https://www.livescience.com/archaeology/remains-of-7000-year-old-sunken-stone-road-discovered-off-croatias-coast
Nah
Also Œ, Ȝ, and arguably W and U.
Anglo-saxons got the UWU, nice
Would ë qualify?
U_w0t_M8
You remind me of my bank about 17 years ago. Everyone had to have a 10-character password, exactly, and it had to include exactly 2 numbers and 1 symbol. I wasn't very knowledgeable about computers at the time and it already felt dumb.
A few years ago my ISP pushed an update to my router that changed the password requirements, invalidating my passwords. Because I couldn't enter the old password I also couldn't change the password. I had to do a factory reset.
Feels odd to check the password requirements on the enter password screen in addition to the new password screen.
Might be checking the old password on the new password screen. Easy programming mistake to make I guess? Apply the same validation to all 3 password fields...
Ahhh, good catch! You are probably a master of code reviews and QA!
Wow that's a big oops
ISP worker here. Our chosen routers default to an 8 digit password, the first 4 are the last 4 of the mac in hex, which anyone can easily see being broadcast by the wifi network. The last 4 are a part of a unique serial number, but its just 0-9. Ultimately, if you try to brute force this default password, you need 10000 tries. It takes a regular GPU 2 minutes with hashcat. It baffles my mind that companies think this is OK.
17 years ago, jeez. My credit Union's website is like that. Only its between 8-12 characters. No more, no less.
It's terrifying.
At that time my bank allowed up to 6 digits as a password. I kid you not, like a card PIN but for online banking login. I believe the whole banking security relies on their backoffices still running on paper.
That's what my current bank uses for the web portal now to think of it. Client number, and 6-number PIN. I guess they're only doing this because they really trust their "unusual activity" protocols, but I've got a feeling they really shouldn't only rely on those.
underlines
german programmers trying to translate Unterstrich
My unterstrich is chafed.
/^\w{6,16}$/Those cases where an english word gets absorbed even though no one from the origin talks like that. It's also informally called underline here in Brazil lol.
I had one of those “fancy” Vodafone routers included with my broadband which had a stupid rule set on choosing the WiFi password. It’s my network, not yours, stupid router. It can be as insecure as I want.
Anyway the rules were enforced by the JavaScript so it was easy to bypass until I got my own router to replace it with.
It's important to note, that these things are designed for the average user. If you want to change the wifi password, you are by far not an average user. Most users just plugs in and never even think about that, and the number of that kind of users are several order of magnitude higher than the conscious ones. For them it's much more secure to set a random pw. If you let them select a password they will choose
12345orpassword.If you know what you are doing usually it's better to buy your own router where you can change everything the way you like.
If we could magically get the data I'd be willing to bet at least half of everyone thinks they can't change their router password.
Create a randomly generated password and store it in a password manager
Assuming we can use both lower- and uppercase letters (52 in total), with the ten digits and the underscore that gives us 63 characters to work with. A random 16-character combination of these gives us 95 bits of entropy (rounding down), which is secure enough by modern standards, at least for a home router.
Regardless, I understand the frustration of arbitrary limitations preventing you from choosing a secure password in a way that you're comfortable with.
Not allowing 20 character passwords is criminal, my bank does this.
Just do the Password Game to figure out a good one!
Lol. Imagine thinking TP Link takes security seriously.
16 characters was the minimum length a password should be due to how easy it was to crack… something like a decade ago.
Now it’s something like 20 to 24 characters.
Seriously, if your company is defining maximum password length and demanding specific content, it is failing at the security game. Have the storage location accept a hashed UTF-8 string of at least 4096 bytes - or
nvarchar(max)if it’s a database field - and do a bitwise complexity calculation on the raw password as your only “minimum value” requirement.Look at how KeePass calculates password complexity, and replicate that for whatever interface you are using. Ensure that it is reasonable, such as 150-200bit complexity, and let users choose whatever they want to achieve that complexity.
It's TPLink. Budget networking equipment comes with budget security principles.
TP-Link.... TP-Link...
I don't trust your bottom barrel software, TP-Link...
True trash-tier software and hardware. Last year I was having trouble with frequently dropped packets from my office computer. I thought it was a Spectrum issue until I tore everything out and started testing all my ports (modem, router, wall ports, etc). I FINALLY narrowed it down to the relatively new TP-Link dumb router I bought. I threw that piece of trash in the garbage.
Never again.
admin wouldn't even work. It's too short.
Username admin
Password password
As is tradition
Like my router that defaulted to
Root
Root
One of mine defaulted to root with no password set.
"adimin"
I hate that kind of stuff, when I see this I wonder if they hash the password at all
It's because of shit like this, I've had a document containing all passwords and accounts stashed away.
I'm going to copy and paste, fuck anyone thinking I'm going to manually enter their shit.
Why not just use password manager?
not as portable
I ran into the same issue, I didn't want to use a cloud password manager because entrusting literally every password I have to a third party and on the internet sounds absurd to me. KeePass seemed like a good idea for me, but at the time I fell back to syncing the vault by sending it to myself in Telegram any time I made a change. Certainly not ideal
I now just have an RPi self hosting Vaultwarden with Tailscale, and for me that's been the best solution that keeps me happy; it's more secure as someone needs to compromise my Tailnet first, it's not public facing, I'm not trusting a third party to not lose my vault (a la LastPass), but its still convenient.
Keepass and syncthing are great combined. Functions fully locally even when I have no access to my home network, and changes get synced between my desktop, laptop, and phone whenever I have WAN access.
Yeah, I probably would have gone with that solution if I knew about it at the time, but now that I have Vaultwarden I'm pretty happy with it.
How do you handle (and test) backups?
I'm gonna be honest, for Vaultwarden I don't. However, a local cached copy of the vault exists on all my devices that are signed in via the official Bitwarden client, and I have recovered using this method before, so that's my backup strategy.
Seems fair. I was just wondering since I was considering vault warden or keypass + sync thing.
I use a keepass vault thrown in a syncthing directory but like literally any file sync will do. If you get conflicts, KeePassXC can merge them
Yeah, I'm with you on that. Everyone on Lemmy loves password managers, but I don't really like the idea of entrusting all of my passwords for everything with one singular program. I actually also dislike 2 factor authentication. One time my phone broke and my bank wanted to verify my identity to purchase a new phone. Except my phone was broken so I couldn't... Yeah I really don't want to run into that scenario again except worse.
I've actually gone old school with it and I keep most passwords physically written down in a notebook using my own cypher language/pictograms. If someone irl really wants to break into my home, find the notebook, and try to decode it, I'd be in bigger trouble to begin with. It's very unlikely.
2 factor when done right is nice, however phones should Never be a requirement for anything and 2fa should require at least two physical keys before being allowed to be enabled.
Take a string as bytes is bad with weird non-ASCII characters. Been there, been bitten in the ass by it.
At least with e-mail clients different clients on different operating systems use different encoding by default for their passwords.
With a router I could imagine different client apps following different standards.
You don't have to take arbitrary bytes. UTF-8 encoded strings are just fine and easily handled by libraries.
The manufacturer obviously also makes the app and can control the encoding.
Many routers can also be controlled via Telnet, which will also use different encodings depending on your OS.
Y'all use UTF8? laughs in Japanese websites
/ can we please stop EUC-JP and SJIS and MS932 and all just switch to UTF8, please, Japan?!
Adrenamin™
add1more_Dopamin