First round of hashing could be done client-side, and then send that to the server.
Would be cool to also add salt so that the hash couldn’t get re-used across services even with the same source password/file if somehow captured.
Idea:
Enter username
Server sends salt to client
Enter password or key file
Client computes hash of the password or file with salt added (I have no idea how it’s used. If appended, some hashing functions could truncate the data, losing the salt. If prepended along with truncation, you just made the password even shorter. XOR?)
Client sends hash to server
Server hashes the hash same way as if it was password
If it matches, you’re in
Basically, the hash is your password. Data can be whatever.
Most websites already use JavaScript, so why not.
You could write a browser extension that converts your password to a hash. You could pick the hash yourself so the server has no way to figure what the original password was.
So, I was having trouble sleeping last night and found myself mulling over your idea.
As any good sleep deprived tech I went down a rabbit hole. There are solutions that prepare the encrypted payload on the client side. But, why you don’t see solutions offering you to authenticate with the entire lotr series is that you hit a ceiling really fast where more data is the same security threshold as the former smaller data.
If you want to derive security from large data there’s already a scalable solution in the form of private public key pairs, where the size of the key is directly tied to the security. So if you convert lotr to a prime number you can get somewhere with that approach.
I’ve thought of the point where password length becomes irrelevant as well. Unless there some maths I don’t know that plays a role here, longer passwords become useless when x^n > K. Where x is the character set available for the password, n is the smallest length that meets the criteria of the formula, and K is the hash functions key space. Effectively, this would be due to the fact that brute forcing would be just as likely to find a collision as it would the actual password used.
Exactly, this is equivalent to using a password of a particular length with only hex digits. It may be long, but the original data is completely unnecessary here.
The salt adds nothing, since you can’t change it, as you need to produce the stored hash in the end on the server. There are methods of challenge-response authentication wherein the server sends a random challenge and the client hashes it, but that requires storing the password in cleartext on the server.
It prevents cross-service re-use, should the original password hash be obtained (if other services used the same system).
Example (MD5 in b64 used for simplicity):
Same password is used on website1 and website2. The password is password. password produces KGdV+tBIacpSMyCszg3GpA== which can be used for both websites.
Now, if website1 adds sbo2 as salt, and website2 addsx3e5, you get: passwordsbo2 -> d0bd511zpYqG3//3vLGYRQ== passwordx3e5 -> 788BnQKx7B2KOSju2jviiQ==
So if you are on a corporate network that does MITM (you had to add their root cert) for monitoring, they’ll only see a hash for each website separately, without being able to re-use it.
Though that’s quite a bit of an edge case, and assumes no client modification or other monitoring.
True, I got engrossed in thinking through your proposal and forgotten about the original intent of a salt. Happens to me from time to time, particularly with security topics for some reason.
I’d rather not make the client do anything like that, you cannot trust a client, EVER; what if some script kiddie tries to send the clear passwd by modifyng the request? Ofc it’s a very minor problem but still…
I wouldn’t send the salt to the client. Have it hash the password, then the server hashes that with the salt for comparison and storage.
But that would mean you can’t verify the password complexity server side, which can be bad for certain accounts.
If there would be an advantage to doing so, the server could still do that anyway. You’d just end up storing client salt and server salt.
My main concern was MITM which doesn’t modify the webpage if web UI is used, such as on corporate networks which require client devices to have that network’s root certificate for scanning and activity logging.
I appreciate the enthusiasm but my load balancer will get sad if I let you send more than 1500 bytes.
First round of hashing could be done client-side, and then send that to the server.
Would be cool to also add salt so that the hash couldn’t get re-used across services even with the same source password/file if somehow captured.
Idea:
Basically, the hash is your password. Data can be whatever.
Most websites already use JavaScript, so why not.
You could write a browser extension that converts your password to a hash. You could pick the hash yourself so the server has no way to figure what the original password was.
You would essentially achieve the same thing.
So, I was having trouble sleeping last night and found myself mulling over your idea.
As any good sleep deprived tech I went down a rabbit hole. There are solutions that prepare the encrypted payload on the client side. But, why you don’t see solutions offering you to authenticate with the entire lotr series is that you hit a ceiling really fast where more data is the same security threshold as the former smaller data.
If you want to derive security from large data there’s already a scalable solution in the form of private public key pairs, where the size of the key is directly tied to the security. So if you convert lotr to a prime number you can get somewhere with that approach.
I’ve thought of the point where password length becomes irrelevant as well. Unless there some maths I don’t know that plays a role here, longer passwords become useless when x^n > K. Where x is the character set available for the password, n is the smallest length that meets the criteria of the formula, and K is the hash functions key space. Effectively, this would be due to the fact that brute forcing would be just as likely to find a collision as it would the actual password used.
Exactly, this is equivalent to using a password of a particular length with only hex digits. It may be long, but the original data is completely unnecessary here.
The salt adds nothing, since you can’t change it, as you need to produce the stored hash in the end on the server. There are methods of challenge-response authentication wherein the server sends a random challenge and the client hashes it, but that requires storing the password in cleartext on the server.
It prevents cross-service re-use, should the original password hash be obtained (if other services used the same system).
Example (MD5 in b64 used for simplicity): Same password is used on website1 and website2. The password is
password.passwordproducesKGdV+tBIacpSMyCszg3GpA==which can be used for both websites.Now, if website1 adds
sbo2as salt, and website2 addsx3e5, you get:passwordsbo2->d0bd511zpYqG3//3vLGYRQ==passwordx3e5->788BnQKx7B2KOSju2jviiQ==So if you are on a corporate network that does MITM (you had to add their root cert) for monitoring, they’ll only see a hash for each website separately, without being able to re-use it.
Though that’s quite a bit of an edge case, and assumes no client modification or other monitoring.
True, I got engrossed in thinking through your proposal and forgotten about the original intent of a salt. Happens to me from time to time, particularly with security topics for some reason.
I’d rather not make the client do anything like that, you cannot trust a client, EVER; what if some script kiddie tries to send the clear passwd by modifyng the request? Ofc it’s a very minor problem but still…
You already trust the client with your password regardless.
I wouldn’t send the salt to the client. Have it hash the password, then the server hashes that with the salt for comparison and storage.
But that would mean you can’t verify the password complexity server side, which can be bad for certain accounts.
If there would be an advantage to doing so, the server could still do that anyway. You’d just end up storing client salt and server salt.
My main concern was MITM which doesn’t modify the webpage if web UI is used, such as on corporate networks which require client devices to have that network’s root certificate for scanning and activity logging.
The client salt would need to be consistent and “public” since the client needs it before login. It’s basically useless.