3 ms·
I always wondered about that too- I recently came across a discussion somewhere that the password limit should be the max allowed for the POST to that website.
by Tyrannosaur 9y ago
I always wondered about that too- I recently came across a discussion somewhere that the password limit should be the max allowed for the POST to that website. Or maybe a bit less, to help prevent DOS attacks.
I always thought the password should be hashed client-side. Supposedly that has some problems and it would still need to be hashed server-side as well.
So I have a proposal: client-side, hash the password. Can use any hash, although hash selection does limit the password security to its output. That hash is the new password sent over the wires to the server, that does proper password handling, but it is guaranteed a password of (say for SHA-256) 256 bits; if it receives a password that doesn't look like SHA-256 output it can automatically throw it out without even checking.
The client can then store the hash-input in his password manager, and it can be literally anything that can be thrown at the SHA hash. Is this feasible?
- e12e 9y agoSee http digest auth - which is considered obsolete. Mostly because it was conceived as a "more secure" way to send credentials over a clear-text channel: https://tools.ietf.org/html/rfc2617#section-3 https://tools.ietf.org/html/rfc2617#section-3 The main issue with a "new" approach vis-a-vis basic etc, is that you need client support (will it work without js). Then there's the question of what you're protecting against: if an attacker knows you accept a single round sha1-hashed pw, it's still easy to brute force through login, but it might require custom rainbow tables to account for the extra hash round. But you'd be better off with a standard pw stretching / storage scheme for defeating off-line attacks.