141–145 of 145 posts
Earlier quoted context omitted.
$ host leftpad.io Host leftpad.io not found: 3(NXDOMAIN) i_do_not_know_what_i_expected.png
haha, too bad those .io domains are so expensive, would make a hilarious joke
Seems like win/win for everyone. In-spec, less confusing for users, and doesn't change behavior for normal form submissions (JS submitters are clearly opting out of browser safety nets).
Earlier quoted context omitted.
The graph I looked at (that I was supposed to link in parentheses, but apparently failed) comes from [0] and actually shows crypt() performance as a function of key length, comparing different hashing alorigthms. Admittedly, not purely a sha256 benchmark, but possibly even more relevant to passwords. It looks pretty linear to me, so extrapolating to 50kB gives me 0.3625 seconds. That being said, I just ran a very sim…
>extrapolating to 50kB gives me 0.3625 seconds It should give you much more than that, considering that the green (SHA256) graph hits almost 0.1s at just 1000 bytes of input. >either crypt() is doing much more than I tought (is salting _that_ expensive?) glibc crypt() is probably doing more than you thought, but it's not salting: in SHA256 mode, various combinations of the key and intermediate hash digests are repeat…
Thanks for the info on what crypt() actually does. I definitely need to look into that some more...
Earlier quoted context omitted.
At the risk of stating the obvious, and sorry if so: doing input length validation client side is very useful for the user's experience, but the server should always validate this too. "... now suddenly I have to revisit everything and add JavaScript magic to check form validity ..." sounds suspiciously like you were relying on client side form validation without server validation, I hope that's not the case. :)
It prevents server-side errors, which I don't handle as gracefully. When the client sends content that it shouldn't have been able to send (i.e. someone tampered with the form) and the server bails out, I don't always bother making it pretty. I'm well aware of the risks in client-side validation, but indeed, as I see in my job often enough (I'm a security consultant), it's a valid remark that not everyone has taken t…
Earlier quoted context omitted.
Why not?
A year after you leave the job, your team is told to build a new auth backend against the database, using a different bcrypt implementation. They just know to use bcrypt, but not about your truncation hack. The deployment is a success. Two weeks later, an angry user (the only one with a 100-digit password) complains that they can't log in anymore. The guy is the company's best-paying customer; the boss is furious. Th…
If you switch to a different bcrypt implementation that does/does not truncate at 72 characters, the server-side truncation keeps all those 73 character passwords working.
If the server-side truncation were not in place, you'd get angry users.