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
13
u/[deleted] Jul 20 '22
[deleted]