5 ms·
> Scarier still is when it's a server-side response that rejects my password for its contents... Why? Assuming that you have established a secure connection wi
by Freak_NL 10y ago
> Scarier still is when it's a server-side response that rejects my password for its contents...
Why? Assuming that you have established a secure connection with that server (i.e., HTTPS by means of TLS), then it is perfectly fine for the server to check, at the time you are setting the password, if your password confirms to the rules established. And when the password turns out to be suitable, it is okay for the password to be sent to the server as-is.
Now it goes without saying that as soon as you have picked a suitable new password, that the server will store only a (proper) hash — by using BCrypt for example. At no time is the plain text password stored anywhere, and any proper HTTP API will send the password via POST to prevent it from being logged in the server's access logs (which is where it could end up if sent as parameter via a GET request).
There are plenty of services that screw up and try to apply nonsensical rules (such as limiting the length of the password to anything less than, say, 256 characters), but in general this is done to prevent weak passwords. You can't exclusively do this client-side, because in security terms, the client cannot be trusted to actually apply the validation and to generate a proper hash; the client can be bypassed. Of course the client can and should validate any input before the server gets to it, so ideally the server need not even come into it during validation, but the server has the final word.
As user though, you have the responsibility of not reusing passwords anywhere (and you don't, because you sensibly use a password generator as you mention). Don't assume that any service handles security well.
- creshal 10y ago> At no time is the plain text password stored anywhere Hopefully. When I see rules limiting passwords to 16 characters and disallowing SQL special characters, I'm having doubts.
- Freak_NL 10y agoAnd you should; you have no way of knowing if any service is practising proper security or not beyond what you can see (e.g., exclusive use of HTTPS with valid certificates), so assume the worst. It is best to see a password as a shared secret; something you share with a specific service. That means no reuse of passwords if you care about the consequences of that password getting out.
- kasparsklavins 10y agoMy bank limits passwords at 15 characters. The best thing? There is no verification, it just cuts off. Have fun figuring out why you can not login anymore.
- pluma 10y agoFun fact PayPal (used to?) silently cut off passwords when signing up, but not when logging in. And the password rules are of course not shown on the login screen. So good luck remember what length they cut your password down to when your password manager has stored the longer version.
- tssva 10y agoHere is a fun one. My credit union limits passwords to 32 characters and since I use lastpass for my passwords I had it generate a 32 character password when registering at the website. Next day I get around to downloading and setting up their mobile app. Login and get a prompt that since it is my first time using the mobile app. They have sent me an email with a 4 digit code I need to enter before proceeding in the app. The email with the code arrives quickly and I enter the code. Proceed to get an error message "Error 400: This service is not available at this time." Ok, they must be down I'll try again later. The code is good for 24 hours. Next morning find time to try again and get the same error message except this time it also informs me that my account has been locked. Call up customer service and with scarily little information get them to unlock my account. Explain what is happening with the app and the CS rep puts me on hold. Comes back and tells me the IT folks thought it must be a problem because of my email address. "Do you have a normal email address like from Gmail, Yahoo or hotmail?" I release a great sigh and give in to the stupidity I'm about to have to navigate. I provide a gmail address. They change the email associated with my account on their end and tell me I should try again in 24 hours. I do with the same results. Call back again and the CS person puts me on hold again while she reaches out to IT. This time whoever she talks to knows the issue right away. Turns out that when you login to the mobile app for the first time and submit the code it is actually appended to the end of your password and submits it as your password. Which if you have a password with more than 28 characters means you are exceeding the 32 character password max which causes them to return the informative, "Error 400: This service it not available at this time.", message.
- clapinton 10y agoI remember Starbucks was doing it for their mobile app about two years ago, sacrificing security for a "better"/faster UX. It's one of those things that you think "No one would be dumb enough to do this", only to be surprised by the fact that a big player has been doing it for a while.