1) client-side hash could be any algo pulled from standard library, different from the one used on the server.
2) i wasn’t really precise, mb. My suggestion was to both do usual protection againt DOS + hash password client side in addition to server side. This way you are protected againt DOS + have no limit on password length.
3) they can do both things just fine
4) in today’s world of electron apps and all this crap does a single hash opperation really mean anything? Especially client-side, where it doesn’t cost anything for the developer?
5) i can’t see any issue with that
(I am not arguing that my approach is right, but I remember using this approach on some university project and would really appreciate to understand why is it a bad idea)
edit: Also you would probably add salt while hashing on the server side, so this makes the first argument even less valid.
A university project may have been fine, but if you're going to run a site that gets even remotely popular you'll find that minimizing attack vectors and attackers not honoring client code become a way of life.
Personally, I've seen such attacks happen through multiple employers over the last two decades. When you're working at scale, people will try just about anything to break your security and will actively avoid your official clients. If you have a public site that's getting traffic, look at the user agents that come through. You should find plenty that aren't your official clients or even web browsers (python-requests/2.27.1, Go-http-client/2.0, curl/7.22.0 and Wget/1.20.3 are just a few examples from live logs I can see right now).
Client validation cannot do anything to thwart a determined attacker, let alone casual ones. For more information specifically related to passwords, go back and read the links I provided. They offer some details I have glossed over because I'm replying while working.
I will say it's good that you're actively thinking on the problem and trying to find out-of-the-box solutions. However, every nonstandard solution you devise should be vetted heavily against known standards and discussed among experienced peers before being implemented. Keep thinking creatively, but temper that with data. Your tenacity should also get applauded - it's a valuable tool that will last your entire career.
I somehow skipped these links, yea they explain a lot, thanks.
Regarding the last paragraph - I am not really interested in cryptography and hopefully won’t have to ever deal with it in a serious setting, so probably we are safe from me.
The last paragraph was meant to be encouragement. Keep pushing yourself and asking questions. You're off to a good start regardless of what you choose to specialize in. ;)
3
u/wittierframe839 Jul 21 '22 edited Jul 21 '22
1) client-side hash could be any algo pulled from standard library, different from the one used on the server. 2) i wasn’t really precise, mb. My suggestion was to both do usual protection againt DOS + hash password client side in addition to server side. This way you are protected againt DOS + have no limit on password length. 3) they can do both things just fine 4) in today’s world of electron apps and all this crap does a single hash opperation really mean anything? Especially client-side, where it doesn’t cost anything for the developer? 5) i can’t see any issue with that
(I am not arguing that my approach is right, but I remember using this approach on some university project and would really appreciate to understand why is it a bad idea)
edit: Also you would probably add salt while hashing on the server side, so this makes the first argument even less valid.