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?
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.
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.
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!