4 ms·

>(1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords. Actually, one I've run into is web-framework-level secu

by Pxtl 2y ago

>(1) they must have SQL injection bugs all over the app and (2) they probably aren’t hashing passwords. Actually, one I've run into is web-framework-level security systems that are hard to disable. Stuff that prevents users from keying in, like XSS attacks. It's not that the password field is being used unsafely, it's that the web framework they're stuck on makes disabling security on a certain text field more complicated than it needs to be and telling the users "screw it, don't use this character in that password" is easier than figuring out how to get the Rube Goldberg machine to do what you actually want. Back-end languages aren't hot garbage like html+js+css so usually it's normal proper BCrypt in the back. Obviously a modern web framework won't have this problem, but a lot of sites are old and still running on messy cobbled-together piles of JQuery.

PaulHoule 2y ago
I had that problem with ASP.NET back in the day. The creators seemed to think it was impossible to properly escape user HTML against Javascript injections and sometimes you just had to destroy bad strings completely. It was trashing API keys and passwords which is a problem when "the customer can't log in". I didn't have a hard time disabling this behavior at all though. My feeling is that it is impossible to "live with it" because I didn't know exactly what rules I had to follow to not get strings corrupted.
malfist 2y ago
There's also the chance that this is because "security made me". More than a few times I've written properly sanitized and parameterized applications, and security came along after the fact and told me we had to prevent input of certain characters. Didn't matter that we handled it just fine, didn't matter that it was safe to put it in. Security's argument was that some other team, some where, at some future time might somehow reuse our data and not follow the same best practices. So no special characters in your password because some engineer in the future might possibly introduce a bug.

by Pxtl 2y ago

PaulHoule 2y ago

I had that problem with ASP.NET back in the day. The creators seemed to think it was impossible to properly escape user HTML against Javascript injections and sometimes you just had to destroy bad strings completely. It was trashing API keys and passwords which is a problem when "the customer can't log in". I didn't have a hard time disabling this behavior at all though. My feeling is that it is impossible to "live with it" because I didn't know exactly what rules I had to follow to not get strings corrupted.

malfist 2y ago

There's also the chance that this is because "security made me". More than a few times I've written properly sanitized and parameterized applications, and security came along after the fact and told me we had to prevent input of certain characters. Didn't matter that we handled it just fine, didn't matter that it was safe to put it in. Security's argument was that some other team, some where, at some future time might somehow reuse our data and not follow the same best practices. So no special characters in your password because some engineer in the future might possibly introduce a bug.