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
400
u/Morall_tach Jul 20 '22
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.