Password may not contain: select, insert, update, delete, drop

Post by duskwuff » Tue, Jan 23, 2024, 4:38 PM UTC

berkes wrote: post #249

duskwuff wrote: post #137

Earlier quoted context omitted.

No, it isn't. If a user's password leaves the web application in any form other than a hash, something nonstandard and probably bad is going on.

Hashing is hardly ever done client side. Most often server side, which is fine, because it's not the same as "storing plain text". In fact, if you rely on client side hashing, you are not only making the app a lot less accessible (it will only work with JS enabled), the security is worse, because now you are publishing a salt to the client. Or you are working with unsalted hashes which is hardly better than just plai…

Post by [deleted] » Tue, Jan 23, 2024, 10:18 PM UTC

actuallyalys wrote: post #160

duskwuff wrote: post #139

Earlier quoted context omitted.

That still introduces a fairly serious vulnerability. The lack of salting on the "password uniqueness" database makes it a juicy target; an attacker with access to the database can attack those passwords, then try the ones which are known to be valid from there against the salted passwords in the user database.

I wonder if there’s some way to mitigate this by either only keeping the uniqueness database long enough to identify duplicates and then deleting it or by using this on lower priority systems that people may reuse passwords from for your higher security one. In either case, the small number of bad passwords you would identify that you couldn’t come up with yourself or find on common password lists probably makes this…