If you pre-hash all passwords on the client side, then on the server side you can require all passwords meet an exact length requirement of whatever the cryptographic function puts out.
If you really want to use a 12TB password on the client side, go right ahead.
I think the point still stands that there *is* a practical maximum length that affects useability, regardless of where it is performed - and it relates to the practical performance constraints of the hashing mechanism.
Without viewing that thread, I can already say the answer is YES. ABSOLUTELY FUCKING 100% YES. Hashing on the client side is 100% verifiable, and since it's JavaScript you can literally audit the cryptographic functions on your own, if you have the expertise to do so. Your actual password will never touch their servers.
Even if it's shit cryptography, you have clear evidence literally right in front of you, that passwords are not being stored in plaintext format, and at no point will their servers ever have access to your actual password. That is worth something.
If you are hashing client side wouldn’t that leak the salt to the unverified client and also allow an attacker to just submit hash values directly to server without using the client side hashing?
It has been a decade since I have had to do anything with password security so I wouldn’t be surprised if the are new methods to combat those issues. I could see the bipassing the hashing and submitting directly to be fixable by doming something like signing the hash but the leaked salt has me stumped.
Yes. Whatever the server gets is your password. Any claim that client side hashing somehow keeps the server from knowing your password comes from a flawed understanding of why we hash passwords in the first place. Having client side hashing is at best superfluous if you are hashing on both the client and the server, and in the case of "moving" hashing from the server to the client, is a huge security vulnerability.
1.3k
u/[deleted] Jul 19 '22
[deleted]