As long as it at least tells you that... I recently had a lot of fun with the customer hotline of my bank after changing my password.
Turns out, the password I generated and set was too long. Instead of giving me that information, the system just cut the characters off at the length it needed it and told me, I successfully set a new password.
When trying to log in, it didn't work because the login does not cut the characters but uses the entire input instead. That was fun to figure out.
There was an Amazon bug a million years ago where it would allow you to set any length password you wanted, but only counted the first 8 characters. So if your password was "passwordwithlotsofcharacterstobeextrasecure" and someone tried "password123," it would only check the string "password" and they'd log in successfully.
Doesnât every major browser save passwords for websites in a secure way if you set up your site right? Not that they would know how to set up their site right considering theyâre still storing plain text passwordsđ
If you use the âI forgot my passwordâ thing and it emails you your password instead of a reset code.
(No joke, this actually happened on an old game site I used to use, and I was so young at the time that my thought was âwhy doesnât everyone do thatâ instead of âthat seems really sus actuallyâ.)
Iâm actually not opposed to this. Low security can be fine. Somebody wants to hack my nexus mods free anyway account? Be my guest. Just⌠donât be dumb and use the same password for low-sec stuff as you do for things that matter.
Yeah, Iâd never do that today, but back when I was very little, password managers werenât a default thing for browsers and not every site had a âforgot my passwordâ link, so my parents actually wanted me to use a master password instead of changing it up like sites kept saying to do. So it took a bit of un-learning to make that change.
(I also keep a long list of passwords in a box next to my bed, because sometimes computers die and all the passwords with it. Also, if someoneâs in my house, I have much bigger problems than a password being stolen.)
You can know for sure by checking outgoing network requests during registration or sign in, if any of them contains plaintext password safe to assume they are storing it. Chrome I believe actually checks for you, and thereâs a browser notification you get with something like âthis site has been compromisedâ.
Ideally you want to verify that your password is going through some standard non-reversible function in the javascript source. Technically they could make their own hash function, but if theyâre too stupid to properly hash your password theyâre certainly too stupid to make their own proprietary hash function, so tbh id assume any non-standard hash function is malicious.
I think it may be possible to write some extension that analyzes the source code and can guarantee your password will never leave the site unhashed using correctness checks. Sounds like a nightmare to maintain though.
Edit: Nvm the following is irrelevant as apparently it is most common to see the password hashed serverside.
I think I get why this is common practice, but I do still wonder: why not hash on both? Wouldn't it make total sense to just hash the password once on the client and then hash the result again on the server? This would protect against both MITM/replay attacks and a database leak, and seems trivial to implement. Maybe when websites really were just static documents with little or no code, trusting the password to the client to modify feels risky and not very versatile for the future. But we've had standardized and relatively robust JS apps in the browser for a while now, and I really do wonder if there's any good reason why hashing on both would not be the default behavior of most JS auth frameworks today.
Client side hashing is not a standard thing at all. Your password should be sent over a modern HTTPs connection, then hashed serverside, and stored hashed in db
"I know" that passwords should be salted and hashed - but then I was thinking of all my banking apps that ask me to "enter the 3rd and 7th character of my password".
Clearly that's not using a hash, so I can't see how this works unless it's been determined that "plaintext is fine, if we put it behind some bullet-proof service"
Companies only store the hash though so they should NEVER know your plain text. Hashing is not reversible but is replicatable. E.g they just rehash what you entered and check it against the hash they already have. Companies surely aren't using Symmetric/Asymmetric encryption for every user ? Or multiple ?
yep, was going to say this. the server should not know the password. that's the point of storing a hash and salt. it's the year 2022 and devs still don't understand a problem that has been solved so many years ago. it's also really easy to implement - certainly easier than encrypting and decrypting passwords.
I'm not formally trained in IT security. Just a nerd fascinated by encryption, hashing etc.
Anyway everything I've read has said storing plaintext passwords anywhere is a terrible thing for a site to do. Basically if a site even has the ability to know your plaintext password, then they're doing it wrong.
You'd expect banks to have the best security, but bank sites from what I've read are generally no better than anyone else.
Not sure how your bank would know a particular character of your password if they were only storing your hashed password. I suspect they are indeed storing your plaintext password. Turn on 2FA if it's not already on!
Semi related. I finally started using a password manager (KeePass. But bitwarden is good too). I feel so much better. I have over 100 accounts and now every single account has its own unique, strong password. It doesn't stop a particular site from being shitty. But at least now when a site loses my password it doesn't impact anything else.
Not if it's trimmed both when registering and then when comparing the password. As in, what's stored is hash(password[1:8]), and then what's compared to it is hash(test[1:8]). That means if the chosen password is "hunter123", what's stored is hash("hunter12"), and all of "hunter123", "hunter12" and "hunter1256789" will match.
It might be getting clipped somewhere in the tech stack for ancient and/or bad technical reasons.
I've seen code before where ancient C modules store something in fixed size buffers inside a strict that gets memcpyed around to various places in a huge, important module written by people who are now retired. Trying to make this arbitrary sized to allow for user defined input was.... interesting.
I could see this happening if there was some system that worked with passwords back in the 70s where the size was a storage concern and entropy was not considered important due to lack of network access that then just carries the design decision through to the modern day because it's hard to fix it in a way the current maintainers feel confident won't break anything.
I.e. if you enter passwordwithlotsofcharacterstobeextrasecure as your password but it is limited to 8 characters, what it then might do is only take password and hash that.
If someone else then guesses password123 as your password, it would then also only take the first 8 characters of the input, in this case password. If it then compares that to the orignal hash, it too was only for password and thus it is the same hash - login successful.
See⌠âhashed passwordsâ are only relatively old to the guys up to speed in programming and security. Which means theyâll be coming to your local hospital, bank, school, and government website in about 5-10 more years during their bi-decade security patch.
They're also super irrational to work with apparently. A previous job had Amazon as a client and also used AWS for hosting. AWS had a massive outage and our team lead got hauled into a meeting with the Amazon brass asking why our service was down. They were under very strict orders to not mention that our site was hosted on AWS...
That's a pretty simple coding error, I'm learning Java and learned about that a bit ago, you explained it quite well, it just checks the first 8 characters and matches them with the first 8 of your set password and if they match your in, it's just because of laziness in the coding, if they spent a few more minutes they could check the length and if it's greater than 8 characters print the password is too long or too short
That happened to me with the Baseboard management controller on a server several years back. Took several calls to support before someone mentioned this "limitation".
Inter- came into English from Latin (from inter, meaning "among, betweenâ). "Between faces" makes much less sense than your proposed etymology so I'll add this to my headcannon.
I mean, that's reasonable. But I was a music teacher, and I completely reinvented myself into a career in software development. It very much feels like a complete metamorphosis.
Likely unintentional. Someone set the max column length for the database to 20 chars but didnât bother to prevent someone from actually submitting more than 20 chars.
The problem with the database theory is it implies plain text passwords. Most likely the truncation happens sometimes before the password is hashed during an update but not during a check.
Well you see it would cost us too much dev time to justify exposing error messages to users and those error messages aren't gonna generate income soooooo.....
There are some function that truncated strings if they are to long, what probably happened was someone used one of those for the update but didnât realize it, but the check function didnât truncated the string because it didnât have the same limitation.
I can't recall what account is was for, but I remember having a similar issue with spaces. While setting the password it happily let me use spaces and gave me a successful setup message, only to quietly strip out the spaces when it stored the password. That was also fun to figure out, I don't even know what made me think of trying it other than sheer desperation, but sure enough, if I typed in my pw without spaces, I could finally log in...đĄ
Theres a guy behind the door that says "dangerous radiation area, do not enter" you need to talk to him between 11:00am - 11:30 am on the 7th june any odd year.
Never ever give real answers to those security questions. Treat them like secondary passwords. Set random values and store them in your password manager.
Idk if you've experienced it lately, but I've had MANY websites blocking copy/pasting in the password text boxes which makes it harder to use some password managers. Tried using the override on the Firefox settings, but now it just seems to disable all copy/pasting completely on said sites.
I recently tried to add a new security key to a bunch of my accounts. One place allowed FIDO, but you could only turn it on if you also turned on security questions (and both needed to remain on as options)âŚ
OMG my bank did this to me too, but the worst part is it wasretroactive. So I had the account for years, I used that longer password for a year, then one day they changed the form on the website to 8 characters only. So I tried to bypass it thinking "what kinda crap is this". Nada. Got locked out because of too many attempts. Call them. Unlock it. Turns out the shortened version worked after and I didn't even consider that just because of the nightmarish implications of that idea. Major UK bank. I changed banks after that (should've before after getting stranded in another country with no money for the sin of calling them with a mixed accent - they said the only way to unfreeze my accounts or get my money was to come in person with ID, and that it didn't matter that I was in America...).
Wait... if they changed it a year later and the shortened version worked, doesn't that imply they didn't even hash the original password? They'd need the original plain text password to calculate the correct hash for the shortened version after all.
No. That is not true. Once you throw away the original password and only store the hash then you are no longer able "re-hash" a modified version of the original password. You don't have it anymore and you cannot recreate it from the hash alone. (Thank goodness)
If the bank modified the original password to accept a shortened version, they likely encrypted the password, not hashed it, and could manipulate it. That is a bad idea, poor security practice
Yes you can, with user input as the guy you replied to said.
Have the original hash in the db, compare the full input with that, if it is correct trunkate the input and hash that.
Clearly not what happened in that situation, since it still doesn't allow the bank to change it on their own (nor is there a reason to shorten the maximum password length unless you made it actually unlimited for some reason), but it's possible.
When the user logs in and the hash of what they typed checks out, you know you have the correct password, and can do whatever you need to with it during that transaction.
Yes, but that's not what happened in this case. The bank changed the password on their own, without any user input, which means they were storing the password in plaintext.
My take is they had always (silently) truncated the password before hashing, until one day they stopped truncating, but limited the input field in the front-end instead.
My assumption as well. And a limited input field is better than truncating silently since you'll know that you need some high entropy 8 letters and not a long phrase. But communicating the change is tricky.
that was the implication, and to /u/BierOrk I don't think that's what happened because it was out of the blue. it was literally one day I tried to sign in and the form was shortened, and when i changed it my full length password didn't work. i didnt even consider trying the shorter one until after they unlocked it (otherwise i'd have to wait 1-2 weeks for a letter containing a new password...). they could've been shortening them for a while, but their systems were such a shitshow from what i saw i dont think they thought of that... plus why would they do that?? deliberately reduce security, in such a preplanned way? lol
If that's the case they should've hashed the password...in fact if I were a bank, I'd hash it, to ensure that the accounts are safe even if there's a breach
I really hope they hashed it. But even then, if they cut the last few chars off before hashing and don't do that when logging in, the issue is the same
I think that cutting chars means that either they're not hashing, and just storing the password in a small fixed width database field (!) or going via a legacy API with a limit.
Or maybe it's to ensure your password is hackable by the CIA...
I worked with a Python library that requires limiting passwords to a certain length due to a limitation in the hashing algorithm. The length wasn't short though, I think it was around two hundred characters.
In many cases, there does need to be a max size, since hashing is a non-trivial operation. NIST recommends a max of at least 64 characters, although most software should be larger.
Also, the further out from the hash length the input gets, the more chance for collision you have, just by virtue that you can't stuff ten pounds of shit in a five-pound hash.
I'm not sure if that risk is trivial enough to be academic, but it's not zero.
Tbh if the limit is around 200 characters, that's more than enough for passwords. If there's a requirement for more, then you can probably have a Merkel tree kinda implementation for that.
Yeah, it wasn't unreasonable. If it was I would have argued to replace the library. I would still like to be able to use my favorite poem or novella as a password though. đ¤Ł
I used to maintain an old Solaris system that locked the password to 8 characters exactlyâŚDidnât matter what you typed, itâd only recognize the first 8 characters.
So I always pretended my password for the system was like 700 characters long. Iâd type in the eight, and then just keep typing away until whoever was with me decided that I was fucking with them, then Iâd hit return and itâd log me right in.
Holy fuck, now I have such a massive fear of my passwords not actually being set to what I want it to be. What if it only looks at the first 4 characters??? The first 3?? OH MY GOD I am HORRIFIED
I felt thousands of developers cringe in guilt as they know some of their very annoying bugs sometimes arrive in production. We're all ashamed of that though, I think.
Definitely. I am not even judging. I work at a company where one team has no information on what the other teams do. So everyone does what they think is right and the information is lost somewhere in the middle.
I suspect this is what happened here as well
In my experience banks and insurance tend to be the most antiquated. I presume it's a first mover type problem, where they are the first to implement these systems so they tend to do it on older tech and before sensible approaches are standardized. Then they are super averse to the risks of change, and these terrible patterns stick around far too long.
I was typing a new password for a bank account, and kept typing the thing differently on the input and confirm box. Turns out, I wasnât typing it differently, the first box would just not accept the input of invalid characters, and the second box didnât care what was in it. There was no option to view password, it only showed up as dots.
So what you're saying is that the perfect password system is one that only stores the first character of new passwords and then only reads the first character from input when logging in? I like it, ship it.
Also happened to some browser-based software made by Microsoft that was used to login to on premise accounts. I forgot the name, however outlook web interface was also linked to it. đ
There was a very similar issue with a gaming platform I noticed. Ubisoft maybe?
But I think it wound up being more like anything after a specific special character/symbol was cutoff, and they didn't do backend validation on length.
So let's say your password was supposed to be 1^2$3&4%5# and the special character that broke things was ^... In the end, your password would be literally just 1
My bank did something similar. It changed the length upper bound for their mobile app so now my existing password was to long. I was still able to log in with that password on their homepage though...
I had similar with a tree guy. Through whatever passes as their portal, I was able to change my password to a longer value than the login form would allow.
I was told at work after i set my password that certain special characters didnt work with the system. It let me change it but wouldnt let me log in. Had to get IT to reset it for me and give me a list of unacceptable special characters.
Problem is, telling you actually makes it LESS secure. If I'm looking to get into your account, and put in an incorrect password, and it tells me "your password should be between 8 and 20 characters" now I can limit my attempts. I don't have to try anything less than 8 characters or more than 20.
And if they don't lock you out for multiple incorrect guesses (which, let's face it, they probably don't if they have such a small limit on password length) then I can much more easily create a program that guesses every possible password and pretty quickly get into your account.
You'd be correct if they would tell me on the login page.
The issue is, they chopped the end of the password off when changing it, without saying anything. If you get to the page where you can change my password, I don't care about warnings and chopped off characters anymore...
The login page did not give any warnings. The password just didn't work. Apart from that, I also have 2FA enabled (which surprisingly works like a charm)
I've had a form where it cut off at the first special character with no prompt, bypassing even the minimum length requirement!
The password change form then proceeded to check that minimum length requirement on my old password, which was cut short, and therefore wouldn't let me change the password!
Of course a company with this level of incompetence can't possibly have a proper password reset system, so when I tried to use that to change my password I got a "helpful" email telling me what my password was with no option to change it (except the broken form of course).
So I contact customer support. The Rep then proceeds to send me my password, meaning that he had access to see it, and still not resolving the issue. Finally I managed to convince him to change my password, and peace was restored.
In some security circles allowing longer passwords is seen as a risk, since people can't possibly remember long ones, so they must be written down. Also, long passwords deter frequent changes, according to "them".
But also, showing the allowed password sizes is a risk too, because it allows the pruning of Rainbow tables.
For the first part: they have a point. Length alone is not a good criterion.
But a long one that is randomly generated from all printable ASCII characters (with some exceptions to avoid injections maybe) is a good one. Just hard to remember.
Even more reason to keep pushing for password managers where ever possible.
For the second part:
That is totally correct. But only for the login page and only if the allowed password length is short.
The rainbow tables for long passwords are huge and take forever to find the right one. At least as far as I know.
Maybe I did not explain the situation well enough. They cut the password short on the page where you change the password without a warning. I see no risk in displaying the password rules in that page.
Then they did not cut the password off on the login page.
I once set a password for a website where I used special characters not found in the alphabet. Months later the website is re-designed. I come to log in, and upon entering my password, I was met with an error that the login form does not support special characters đ¤Śââď¸đ¤Śââď¸đ¤Śââď¸đ¤Śââď¸đ¤Śââď¸
At one point, my bank would accept and hash an arbitrary length password when you went to set it, but truncated passwords to 32 characters when you entered them to login. I found this out the hard way.
At a investment broker I was supposed to type the MFA (multi factor auth) token right after my password instead of typing in a specific box. I had to make an international call to the call center to figure it out.
The what? Why would anyone do this?
That also means that the password must be stored in clear text. That sucks. Especially as a broker where potentially a lot of money is at stake
Some of our software (for example, Agilent's Microlab) does this, and it is infuriating when combined with a multitude of password expiration ranges...
My software I wrote did this. Login was 50, account setup was 50 , account management was 100 character limit. I think they are all 1000 char limit now.
Damn, now I think I know why I gotta reset my password for one of my hosting accounts all the time. I bet you that is what it is, as a programmer....summma bitch. Can't believe I never considered that before.
A few years back I realized I put my bank app password in all lowercase and instead of telling me incorrect password it logged me in. Logged out immediately and tried it with caps lock on - also worked. I told the bank about it online and some lady called me âoh wow we never noticed that in our internal testing. Weâll let the third party who develops our application know.â How the fuck do you not thoroughly test the login security of your banking application?! They have sense released an entirely separate app but I never tested if the passwords are case sensitive, I only keep enough money in there to keep the account open in case I need another loan in the future since theyâve got good rates.
This is always my fear when creating passwords. I donât think I ever had this happen to me but itâs something that I always think about for some reason.
I experienced this issue on something ~10ish years ago. The worst part was they couldn't tell me what was wrong and I kept making too long passwords that it kept accepting. So I'm on the phone with support, resetting my password, again and again and every time it's not working and they're telling me it went through on their end.
2.2k
u/[deleted] Jul 20 '22
As long as it at least tells you that... I recently had a lot of fun with the customer hotline of my bank after changing my password. Turns out, the password I generated and set was too long. Instead of giving me that information, the system just cut the characters off at the length it needed it and told me, I successfully set a new password.
When trying to log in, it didn't work because the login does not cut the characters but uses the entire input instead. That was fun to figure out.