97,170 reputation
12144270
bio website
location
age 70
visits member for 3 years, 9 months
seen 13 hours ago

I SHALL DEVOUR YOUR HEART AND FEAST ON YOUR SOUL (so don't bug me).


Jul
13
comment How do I prepare for Certificate Authority end of business?
If the last available CRL has a nextUpdate field in the past, and no newer CRL is produced by the CA, then systems that validate the certificates ought to reject them, because "certificate revocation status cannot be ascertained". Web browsers are an exception, since they just don't really bother honouring revocation.
Jul
13
answered How do I prepare for Certificate Authority end of business?
Jul
13
awarded  Caucus
Jul
13
awarded  Great Answer
Jul
13
comment Password rules: Should I disallow “leetspeak” dictionary passwords like XKCD's Tr0ub4dor&3
My main point is that users should select non-weak passwords on their own volition -- the more rules you enforce, the more users will find creative ways to generate weak passwords, instead of producing strong passwords. However, the system must still project the idea that strong passwords are important, and a minimal length is, in my view, the best compromise: not too harmful since users are ready to accept such a limitation (they feel that they understand it), and still a good conveyor of the idea that there is such a thing as security.
Jul
13
awarded  digital-signature
Jul
12
comment Password rules: Should I disallow “leetspeak” dictionary passwords like XKCD's Tr0ub4dor&3
@SteveJessop: by my logic there should be no lower limit on password length. However, if the system accepts (for instance) three-letter passwords, then quite a lot of users will feel invested with the sacred mission to warn you (the sysadmin) about the folly of three-letter passwords, and simply reading all these complaints will consume a lot of time. Enforcing a minimal length is something that average users understand and accept, and serves as a signal that you actually mind security.
Jul
12
awarded  Populist
Jul
11
comment Password rules: Should I disallow “leetspeak” dictionary passwords like XKCD's Tr0ub4dor&3
On a more conceptual level, the main problem is trying to force the user to choose a "strong" password. To get decent security, the user should understand what makes a password good or not. "Password rules" such as enforcing a punctuation sign are not effective for that; in fact, they make the user believe that '.' is somehow "more secure" than a letter like 'k', and that is counterproductive (it makes it less probable that the user will actually understand things). Security requires user cooperation, which feeds on freedom and pedagogy, not rules.
Jul
11
awarded  Good Answer
Jul
10
awarded  Nice Answer
Jul
10
answered Why are there very expensive and cheap SSL same type certificates?
Jul
10
answered Password rules: Should I disallow “leetspeak” dictionary passwords like XKCD's Tr0ub4dor&3
Jul
10
awarded  Nice Answer
Jul
9
awarded  Nice Answer
Jul
9
comment How to do client side hashing of password using BCrypt?
That kind of client-side hashing is called "server relief". There is a lot of theory on that subject. I suggest beginning with this answer.
Jul
9
comment How to do client side hashing of password using BCrypt?
Using a combination of the user name and the server name as salt is still better; you still have salt collisions when a user changes his password (the old and the new hash can still be attacked in parallel). The really general method for doing client-side hashing is a two-step protocol where the client first sends the target user name, then gets the salt, computes the hash with that salt, and sends the result back -- and the server must still do one extra hashing (a fast one) so that what the client sends is not what the server stores.
Jul
9
comment How to do client side hashing of password using BCrypt?
Using a static salt on the client really removes all security implied by the client-side hashing. With a static salt, the hash result becomes the new "password" that grants access when sent to the server. By using a "static salt" you just spent a lot of computing cycles for nothing. Using the user name as salt is much better, but still implies collisions that help the attacker (i.e. the attacker may optimize things by precomputing hashes, e.g. as a rainbow table, for user name "admin", because most site using that software will have a user named "admin").
Jul
9
awarded  Guru
Jul
9
awarded  Good Answer