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 hunter2 and the front end sends a hash for h, then hu, then hun, 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.
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.
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.
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.