Reputation
358
Top tag
Next privilege 500 Rep.
Access review queues
Badges
1 4 10
Impact
~17k people reached

  • 0 posts edited
  • 0 helpful flags
  • 2 votes cast
Oct
4
awarded  Good Question
Sep
25
awarded  Yearling
Sep
14
awarded  Famous Question
Jul
11
awarded  Nice Question
Jul
7
awarded  Notable Question
Jun
6
awarded  Nice Question
Mar
27
answered Mysql - two-way encryption of sensitive data (email addresses) outside of Apache, PHP and MySQL
Sep
23
awarded  Notable Question
Jun
24
awarded  Popular Question
Mar
29
awarded  Teacher
Feb
24
awarded  Popular Question
Jul
20
accepted Challenging challenge: client-side password hashing and server-side password verification
Jul
17
awarded  Scholar
Jul
17
awarded  Supporter
Jul
17
accepted Recommended # of rounds for bcrypt
Jul
16
comment Recommended # of rounds for bcrypt
@D.W. wrote "please be prepared to listen to the answers you get", sorry if I gave the impression being pedantic or stubborn. Perhaps as a non-native English speaker my comments conveyed the wrong message. I do appreciate all answers, and try hard to understand the rationale behind them.
Jul
16
revised Challenging challenge: client-side password hashing and server-side password verification
added 302 characters in body
Jul
16
comment Recommended # of rounds for bcrypt
I have a hard time understanding the reasoning that my platform determines the amount of hashing rounds. A client-side Javascript bcrypt implementation can do about 2^6 rounds on a legacy mobile device, my most recent hardware can do 2^13 rounds. However, you commented elsewhere that "12 rounds is almost certainly not enough". How can the speed of my implementation be relevent? Perhaps this just means I need to buy faster hardware and can't run a secure website on an old Pentium 4 which does 2^4 rounds?
Jul
15
comment Recommended # of rounds for bcrypt
Ah, I thought 2^(current_year-2000) was just an arbitrary example. Ok, so 12 rounds in 2012.
Jul
14
comment Recommended # of rounds for bcrypt
I am aware I should match Moore's law. But that is exactly my question: how many iterations are nowadays considered safe given the current speed of the brute-forcers?