The other day I used a website and they didn’t let me pick a password.
They sent me a very secure random one via email 💀 in the year 2025, this still happens.
There’s really nothing wrong with that, it’s a sort of half-baked 1.5FA, I would hope/assume you had to immediately change your password after.
It’s just 1 factor, as they are using “something you have,” i.e. your email account, to authenticate you initially. Anyone with access to the account would have the password, so it can’t count as a unique factor.
99 % of websites even with “2FA” enabled allow to reset all login credentials with an email reset. Or worse, an SMS reset.
aka it’s all just 1FA with the password+TOTP just being there for “convenience”, and they trust gmail’s actual 2FA not to get breached because if it does then the account is donzo.
Not that emailing passwords is good, because users won’t change them and are likely to leak them. However login systems that are just an email with temporary credentials are superior to the standard system with the possibility to reset password by email, since they’re basically that with less attack surface. The service provider never even has to process the user’s password. Literally the only downside is usability, which can be a worthwhile tradeoff.
Alternatively one could do OIDC, but the downside is it only works with whichever authentication providers are setup whereas email registrations work without an intermediary such as google or Microsoft which is a big plus in my book, and might even be a hard requirement in B2B scenarios.
I’m not tech literate anymore, whats OIDC ? I figured out the other ones
OpenID-Connect, the standardized form of oAuth for the sole purpose of authenticating users to third-party services (i.e. google says “yes I certify it is john.smith@gmail.com logging in to your service”).
Much love for responding
Hmm, yup, you’re right, my bad.
I guess it’d help if it still required an MFA code added or something.
The 1.5 is them relying on your email provider to provide the 2factor 😂
Australian Army still does this.
This is asinine and anyone responding that this is normal is asinine as well. You can email a link to reset the password but if you’re sending a plaintext password, even with the intention of changing it immediately, you’re a fucking idiot.
Yeah, I’m shocked with the other responses to my comment…
it’s ok if you need to immediately change it
Some banks do this and then ask you to change it later.
I don’t even know how the fuck this happens.
Enter password
Incorrect
Enter password again, carefully to make sure no typos
Incorrect
Change password to the one you remember it to be
“New password can’t be the same as old password”
😬
Shit sometimes gives me this while using a password manager! The saved password is correct. Even the change password thing says it should be correct. Still tells me it’s wrong trying to use it.
That just means they’re forcing everyone to change their passwords but they don’t want to come out and tell you about it.
If you’re lucky, some overzealous sysadmin is just trying to enforce regular password updates on his users, and makes them expire every once in a while.
More likely, there was a breach of some sort that they want to keep on the hush.
It’s also possible there’s a hidden max password size somewhere, like some fields only counting the first x characters of the password but it’s inconsistent across different forms.
USAA is guilty of this shit. Let’s you set a huge password. Truncates it. Doesn’t tell you about it. Error when logging in.
I want to beat the motherfucker behind this strategy.
E: Kagi too. I removeded out the support and I got a ‘meh, it should have told you’ response. Fix your shit.
Not sure what is worse, not telling you and giving an error or not telling you and letting you log in (ie truncating the password both times, letting you think your password is longer than it is)
The first is more annoying, the second is scummier.
Yep
but they don’t want to come out and tell you about it.
It also doesn’t require a code change to continue blaming the user when you invalidate all current passwords.
It’s a couple database queries to move all current passwords to old passwords, and change current (hashed) password for everyone to “deadbeef”. Nobody can guess a value that adds to their salt and hashes to “deadbeef”, and you get this behavior.
One time, I was trying to recover an old email address from a local ISP domain. They had changed the pw length requirements a few years earlier.
Well, my current password was not long enough, but some idiot designer put the password requirements on the Old Password field as well. I was not allowed to update my password to meet the new requirement because the old password did not meet the new requirements. Morons.
Shit sometimes gives me this while using a password manager! The saved password is correct. Even the change password thing says it should be correct. Still tells me it’s wrong trying to use it.
I had this exact issue with an Instagram account. You’d expect a social media site with 2 billion monthly active users to do better but nope
What gets me is the “password is too similar to old password”.
How do they know? Are they storing them in plain text? I would imagine the hash would change drastically even if I change a single character, no?
I can imagine one legitimate case: when you create a password, they save the hash for the full password as well as the hash for the password without the last character. So if you attempt to change only the last character, they can detect it. They’d need to salt the two separately though.
In theory, they could do the same for every character, but they’d have to save 20+ combinations for that (plus all the salt), so I doubt anyone is doing that.
The strongly recommended hashing algorithms are slow on purpose, and often use up a lot of RAM, too. Multiplying the number of hashes you would need would multiply CPU/memory load for every new password.
No need to store it, you can do the opposite, create 20 variations of the new password, hash them, check if any match with the old password.
Edit : nevermind, it would only work if they added data instead of editing it.
Yeah, but 99.999…% of the time, they’re just storing plaintext.
I dunno about that, probably more like 99.98%.
Cryptographic hashes don’t work like that. One of the defined properties of a strong cryptographic hash is that changing even one bit on the input results in about 50% of the bits of the output getting flipped in a non predictable way. There’s simply no way to tell from looking at two cryptographic hashes how similar their inputs are. If there were, that would weaken the security significantly.
Why wouldn’t it work?
You’re removing the last character before hashing, so the removed character won’t affect the hash value.
Because
they save the hash for the full password as well as the hash for the password without the last character. So if you attempt to change only the last character, they can detect it.
is not how hashing works. You can’t create a subset hash to compare against the set hash.
Let’s say my password is “ILoveUsingSimplePasswords1”.
You remove the last character and get “ILoveUsingSimplePasswords”.
And then I change the password to “ILoveUsingSimplePasswords2”.
Now here are those 3 “passwords” hashed.
- 5c30739dfd7a5df387f9a3e6c08a026831314e8cc8df4f18e3c2a7baddf30bb2
- a78cb4f0ddf5513862e97e20fe8f331d08bbb5aacf0ac14c0b6a0f1b036a7b6b
- 9385bd96fb795abd7204d27990e8c7b2bf929bac772b6f8e3b875e8a313be5cb
Can you tell which of the 3 is “ILoveUsingSimplePasswords” and can you identify where I’ve added 1 or 2 to the end? You can’t because it’s not how hashing works.
This is not what he meant. If the password is xyz he stores the hash (f*) for xyz and xy. When you change your password to xyb, it compares fxyz to the first saved hash and a truncated fxy to the second saved hash, flagging if you’ve only changed the last character. The mask length could be arbitrary and there can be many saved hashes at the expense of making password resets slow.
I get it now. They’re comparing only trunks because the hash of the trunk wouldn’t change.
Yep, that’s what I meant. Pretty sure my company does this, because they can detect this, and I know enough of our IT to believe they’re not storing passwords in plaintext.
You didn’t remove the last character of “passwords2”. When you remove the last character, that becomes “passwords” and therefore has the same hash as “passwords1”[:-1]
They pay a kid in Bangladesh 14c an hour to visually compare the new password against the old one.
“AI”
Just a dude they call al, short for Allen
Usually you have to enter your old password on the same form in order to set a new one.
Alternatively they could run a bunch of common substitutions on the new password, hash, and check if anything matches the old hash.
I mean they could technically check common password modifications and test all of those hashes against your old hash to see, if they’re storing plaintext and you should delete your account immediately.
My guess is the latter is correct
It pisses me off that so many companies store a database of X number of your old passwords in the first place. Like, fuck off twerps, I probably still use those old passwords for at least 20 other logins. When your shitty database is compromised I now have to worry about all of them.
The old passwords don’t have to be stored in plain text. They can still be hashed and salted.
In theory, yes. But unintentional bugs and security flaws exist (cf sites like have I been pwned), and by storing old passwords next to new ones increases the impact of such bugs and flaws significantly, precisely because folks use the same password for different services. Of course people shouldn’t do that, but they do, and as a dev you should be mindful of that.
You’re like, so close.
Don’t reuse passwords between different services, or after a password reset. You’re aware of exactly why that’s a bad practice (a compromise of any one of those services, or an old database of those services will expose that password), so why knowingly bear that risk?
Last time I had to implement a feature like that, I stored a substring of the old password’s hash. If one User in a million gets a False quotation Mark same Passwort quotation Mark message, I can live with it.
Hey, İ know quotation marks are expensive, but since I like your attitude to keeping your users secure you can have some of mine: " " " " "
You can just paste copy them into your next post.
I would like to donate as well:
" " " " ’ ’ “ ” « » ` `
I probably still use those old passwords for at least 20 other logins.
Right at the top of the list of things not to do with a password.
Someone with your Amazon account might assume you use Facebook, Youtube, Steam, and every bank around your location(they know). There’s 2factor, but not everywhere
I mean, that’s true if you reuse your passwords instead of using a password manager that can generate random gibberish… Which is itself a very poor habit exactly because of this very fact?
Even assuming a company follows best practices (a bold assumption that is wholly inconsistent with reality) there’s ALWAYS a possibility of a breach - and it’s not if, it’s only when.
So, everyone should be using a password manager by default.
I like to use keepassXC personally because it’s fully under my control. I don’t really care for ones that are hosted by 3rd parties because that introduces more risk if they get beached, but for many people that’s fine; it’s more convenient for the user. To me it’s important enough that I manage it all locally.
So, everyone should be using a password manager by default.
And an email mask. Life is easier if you can reset a password and change your email after a breach and have the old email disabled and disappear.
Agreed!
The pain with email maskers is when a service doesn’t accept the email as valid… I have 2-3 I use. I start with blur (abine/ironvest, whatever you call it these days) and if it doesn’t work I go to my bench warmers.
Password managers are your friend 🙏
I probably still use those old passwords for at least 20 other logins.
My soul cries for you.
Storing in plaintext? That’s a paddlin’.
Not salting your hashes? That’s a paddlin’.
Sending hashes to the front-end? That’s a paddlin’.
You gotta salt yer hash, that’s how you bring out the flavour!
They could still be doing the validation server side even if you didn’t hit submit, like when you leave the text box.
Nah it pulls your plain text password in after you enter your email to compare it to 🙂
This thread is just a series of people who think they understand.
Thinking you understand when you do not is the real cyber security threat.
This is a password reset form. This requires the user having successfully authenticated or gone through a password recovery form. The best practices in this instance are not the same as the best practices for a login form.
This form can be used to brute force or dictionary guess passwords and infer what they are without a limitation on login attempts. Even if the password has already been invalidated on that service, finding a collision on this service gives you a password that might work on other services for the same email address/username
And waiting for a form submit changes that in what way that cannot also be done on a debounce?
- Aquire password database (it’s properly hashed and salted)
- Create an account and access the password reset form
- Dig into the front-end code to find whatever is doing the hash calculations
- Brute-force a list of common passwords and look for matches
It would still take significant time, but it’s still a vulnerability, especially as technology evolves. You’re right that best practices are different for a reset form, but there are some things that are common (like don’t do hashes in the front end).
I mean I guess in theory they could be sending the password to the backend and validating it against your hash? In reality I doubt anybody would do that tho as it’s a huge load on the server
Well when the website is so helpful and give you instant feedback on the correctness of your password… Then it would do that to hackers as well.
A password reset occurs within a state that has some form of authorization.
Definitely a thing, usually a debounce meaning it waits half a second after the last key stroke to perform validation.
You could use logic to only send it after x amount of seconds without changes, waiting for the specified minimum length, etc.
With the right restrictions, it really wouldn’t be that much different load profile wise to submitting it upon button press.
There’s a high probability that it’s sending the hash (or even the password 😵💫) to the browser and comparing it though which is bad practice. Hell, just having a hash with no salt is bad practice, and sending the salt to the frontend as well would be even arguably worse.
Not even remotely involved with opsec, but sending the password from the client to the server doesnt seem that crazy. It opens you up to people skimning your plaintext password if your connection is not secure, but by that same logic if your connection isnt secure then they can skim your hash. Unless the security on the site is good im sure there is a way to skip the encoding process and log in directly using the hash, so its a relatively small improvement to send the hash rather than plaintext, no? The much bigger issue would be if the server validated it as plaintext, because that would mean the server stores it as plaintext. But if the encoding is done server side, then that would make it significantly harder to crack the hash algorithm.
Im sure im making a mistake with my reasoning here, can you explain it to me?
Edit: ah, i see. I misread your comment.
Yeah the password is usually sent, not in plaintext because you do it on a TLS connection. You can’t do the hashing clientside and send the hash anyway because the value needs to be salted and you’d also be exposing your algorithm choice and other details, or you’d have to do further processing server-side where you could conceal the details in which case I don’t really get what sending the hash gets you because you’d have to do it again.
People seem to constantly forget in web programming that you can obfuscate the client code, but you can’t actually hide it or rely on it solely for validation. The client isn’t something you control. They can very easily bypass any validation you put in that layer.
What is salting in this context?
Using only hashes makes it possible to use what’s called a rainbow table (essentially a database of common passwords hashed related to their plain-text values) to crack the hashed passwords if they’re somehow retrieved from the database. A salt is a separate value, usually unique to each user, that is appended or prepended to the password prior to hashing it. That makes it much harder to crack the password, even if you have the hash in hand.
Ah, makes sense. You are an excellent communicator, I really appreciate it.
Anytime, and I appreciate the compliment so thanks!
The hash or a checksum can be sent to the page to be checked by the same function running in your browser that is checking if the new password has special characters etc.
That would be an extremely bad idea tho, because it would allow a malicious attacker to
- Try random usernames, and if the website returns a hash they know that user exists
- Once they have the hash, and the hashing algoritm, it is much easier to brute-force the password, bypassing any safeguards on the server
Username/password validation should happen entirely server-side, with as little information as possible provided to the client
Username/password validation should happen entirely server-side, with as little information as possible provided to the client
Yyyup. This is why you also why it’s good practice to respond with HTTP 404 if a public user has tried to access user data they shouldn’t have access to, whether it exists or not. Don’t give them the hint that they hit a path that has forbidden data.
Username/password validation should happen entirely server-side, with as little information as possible provided to the client
💯
It’s recommended practice to not even tell them which half of the username/password combination failed upon authentication failures.
It is a password reset from. The username has already be confirmed in a previous step
That still doesn’t make it good practice to send the old password (hashed or not) to the client.
You are making an unfounded assumption that the password is sent to the client which does the check and then shows the message rather than the server doing the check and responding with the message back to the client.
Nah I’m not, look above. There’s a way to do this that isn’t terrible. I just kinda assume that they aren’t doing it properly because I’ve worked in software for decades.
People are forgetting this is a password reset form, not the login form.
Seems like a great way for me to harvest a bunch of hashes to pull down to my GPU rig and crack offline.
Can someone explain why this would be bad?
Edit: ah i got it, before i submit as in while you are typing it in it shows you a message. I thought it was just one of those warnings where it goes “has to have capital letters, at least 8 characters, etc”.
Because in order to know that the password is the same before submission, it has to store it in plaintext (or I guess it could hash every input and compare it immediately but no way that’s happening).
Idk how you came to these conclusions. They might be storing it plain text and comparing directly, sure. Any website might be. But there is nothing about this that indicates that they are actually doing that for sure. They could absolutely just be comparing the hash after each input. The problem that for sure is happening is that they have sent the hash tot the front end, i.e. in the web page elements that the user can inspect, and they are verifying your current/used password(s) on the fly without even a submit attempt counting against them. All of which means a password farmer could just harvest the hashes for every username they try, and/or use bots to put in a username/password, hit “forgot password”, and then brute force the stored current/password(s) without any red flags being raised.
Plus if the front end is hashing with each keystroke, I feel like the security of the final hash is far, far, less secure to any observer/eavesdropper.
If the password is
hunter2and the front end sends a hash forh, thenhu, thenhun, etc., then someone observing all these hashes only has to check each hash against a single keystroke, then move on to the next hash with all but the last keystroke known. That hash table is a much smaller search space, then.“hunter2”, you say?
Puts on shades
“I’m in.” rapid keystrokes
Following on your theme of charitably assuming at least the possibility of a safe implementation, this could certainly be done without surfacing the hash on the front end.
It could be that each keystroke triggers an API request which sends the current input, then the API hashes it and compares that to the original, entirely in the backend.
Not likely, but possible.
Fair, it could, yes. The bigger problem was definitely the ability to brute force the passwords though, as surfacing the hash still leaves them encrypted which isn’t super valuable without access to the hashing algorithm.
Right, so the hashing and comparison of hashes also can happen in the back end, and the API response can just be true/false whether it’s a match or not. That way the hashes and the hashing algorithm could all stay private.
The comparison API would of course also need its own rate limits and backoff etc to ensure it cannot be used to bruteforce attempts until you get a ‘true’ back.
All in all it’s a terrible idea though and nobody should actually do this.
We’re all assuming there isn’t a “current password” field right next to “new password” on the reset form. Most of them do, though there are arguments that they shouldn’t.
Name names
Is it good to reveal weak systems? Like just naming names here is that effective to prevent people from being compromised more or less than they already are?
I want to know if its something I use, but i also dont want to contribute to outing weak systems without also informing the system people first to let them know.
I’m genuinely curious, i dont actually know just seems risky to me to create a hitlist of soft targets
I think the best practice is to inform the company of the flaw, and if they don’t fix it in an appropriate time, then call them to the world. If they have a flaw that can be used by hackers, then the hackers probably already know about it.
Hmm i suppose my concern then is for the situation you think unlikely: they dont know and neither do bad actors. Okay that makes sense
Now I’m curious about why would the hackers already know? Or where does your confidence come from?
Cause hackers are smart and motivated. If a random memer found the flaw by chance, then one of the million black hat hackers that spend their time looking for these flaws had also probably found the flaw.
I’m struggling to figure out what the problem is, aside from UX annoyance (like the IDE panicking before you close a brace or sth). Eventually whatever you end up typing is being sent to the server anyway, and if that’s not inherently problematic, what’s the problem with intermediates being sent? Is the problem XHR requests on events other than clicking? Why?
It is implied that it was made using comparing to a plaintext password sent back from server to the user’s browser to compare.
deleted by creator
