Reputation
1,813
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
11 23
Impact
~96k people reached

Apr
7
awarded  Notable Question
Apr
7
awarded  Yearling
Sep
10
awarded  Notable Question
Apr
12
comment Prevent denial of service attacks against slow hashing functions?
Since knowing the strength score lets you discard passwords without testing them, this solution weakens the password's protection. I'm not convinced that a "basic encoding to mask the real password strength score" would help here, since if the server can decode it, then presumably an attacker can too (which is why we use iterated hash functions in the first place).
Apr
7
awarded  Yearling
Mar
4
awarded  Nice Question
Feb
22
comment Why was the private key of the Superfish certificate so easily extractable?
Adding to what mehasse and Stefano said, legitimate programs that do this will also warn you about the security risks beforehand.
Feb
19
revised Are web scrapers fooled by obscured emails anymore?
Use example.com as an example domain, not email.com
Feb
19
suggested approved edit on Are web scrapers fooled by obscured emails anymore?
Jan
23
awarded  Popular Question
Nov
5
awarded  Popular Question
Jul
30
awarded  Nice Question
Apr
7
awarded  Yearling
Mar
26
comment When and where do I hash a password?
@jhoyla Ah I see. It seems easier to just hash it one more time on the server side.
Mar
26
comment When and where do I hash a password?
The way to make it work is this: The client sends the server the user name, the server responds with a salt and number of iterations / difficulty. The client hashes the password given that information and sends it to the server. The server then hashes it one more time, then validates it against what it has stored. I'm not claiming there's no downsides, they are: (1) the server gives away the fact that the user name is valid (most websites do this anyway though) (2) there's an extra round-trip to request the salt and (3) this doesn't work for all clients (pointless in JavaScript for example).
Mar
26
comment When and where do I hash a password?
Hey don't turn this into a strawman. My argument was specific: There's no reason to hide the hash function or salt. I agree with you that JavaScript cryptography is pointless, but the question was about client-side hashing in general, and not all clients are JavaScript.
Mar
26
comment When and where do I hash a password?
It doesn't matter. The hash function can be public and it won't hurt your security at all.
Mar
26
comment When and where do I hash a password?
I'm not arguing against double hashing. I'm saying lowering the iterations every time doesn't help at all (because the password is still the same, and the attacker only needs one hash to break it).
Mar
26
comment When and where do I hash a password?
Yes, but the server can hash whatever value it gets (the pre-hashed password) before storing it. Just because the client hashed the password doesn't mean the server can't too.
Mar
25
comment When and where do I hash a password?
I think you're skipping a step though. Allowing the client to hash the password doesn't preclude the server from doing it too.