249 reputation
23
bio website zofrex.com
location United Kingdom
age 27
visits member for 3 years
seen Jul 24 at 14:47

Software engineer, strengths are Java, TCL, JavaScript, PHP, and breaking things. Weaknesses are functional languages, breaking things, and "you write some weird code sometimes".

Greatest moment: crashing the Linux kernel. Worst moment: Almost getting banned from #debian because they thought I was trolling.


Jul
16
comment Is this password migration strategy secure?
@fgrieu isn't being slow part of the point of bcrypt and scrypt?
Jul
12
awarded  Yearling
Aug
2
awarded  Beta
Jul
15
comment Is using slow password hashing on the client side easier attackable than on the server side?
@PaĆ­loEbermann let us continue this discussion in chat
Jul
14
comment Is using slow password hashing on the client side easier attackable than on the server side?
Your assumption is incorrect, generating valid bcrypt hashes is trivial. Have you actually tried this in production? Is hashing passwords on login actually slowing down your server? If it isn't then I would stop worrying about it. This smells like premature optimisation, and in this instance I don't think the speed/security trade-off is worth it. You are completely scuppering security to the point where your usage of bcrypt is 100% ineffective, massively increasing complexity, and rolling your own security rather than re-using something well studied.
Jul
14
comment Is using slow password hashing on the client side easier attackable than on the server side?
On turning the hash into a password: I don't see why it would be significantly harder to brute-force a SHA-1 hash given the constraints that the input must be a valid bcrypt hash. You still have the same probabilities of a collision, the same number of expected passwords to hash to see a result - you just place some arbitrary restrictions on the format of the input.
Jul
14
comment Is using slow password hashing on the client side easier attackable than on the server side?
On speed: Currently, you hash passwords so fast on login that it contributes zero to load. If you increase that to even adding 1% to overall server load, you will have made it orders of magnitude slower for attackers to break into accounts at the same time. It's a clear win. Hashing passwords is such a small, easy, and relatively infrequent thing for a web application to do that I absolutely refuse to believe any website needs the full speed of SHA-1 or MD5.
Jul
14
answered Is using slow password hashing on the client side easier attackable than on the server side?
Jul
13
comment How can a random salt for a hash function work in practice?
Salts definitely don't need to be secret. If you don't know the motivations for using them, you might find this answer interesting stackoverflow.com/questions/2583203/salt-passwords-and-security/…
Jul
12
awarded  Teacher
Jul
12
answered How can a random salt for a hash function work in practice?
Jul
12
awarded  Supporter
Jul
12
comment What are the benefits of the two permutation tables in DES?
Excellent amount of detail! We were taught at university that it made hardware implementation easier, but not why, so thank you for your answer.
Jul
12
awarded  Autobiographer