|
|
|
|
|
|
by GordonS
2268 days ago
|
|
|
Hmm, I can see some benefits to the scheme, such as using the client's CPU cycles, and the plaintext password never having to be sent to my servers. Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme. As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries. TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users. |
|
|
The code doing the client-side hashing is just as secure as the rest of the client interface. You don't compromise anything by doing it.
Still, it's easier to do the extra hash locally on the server if you need it.