network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 10 months |
| seen | Feb 25 at 20:43 | |
| stats | profile views | 8 |
|
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? |
|
Jul 14 |
comment |
Recommended # of rounds for bcrypt @Andrew: The speed of my own system should not be leading for the number of iterations. It is the current speed of the brute-forcers that should dictate how many iterations are considered safe. Hence my question: how many iterations are nowadays considered safe? |
|
Jul 14 |
asked | Recommended # of rounds for bcrypt |
|
Jul 14 |
comment |
Challenging challenge: client-side password hashing and server-side password verification Sorry for the sloppy wording. Let me rephrase that: SRP looks like the perfect solution for the challenge-response problem, but still requires client-side password hashing. Thus I still have the dilemma of choosing between less hashing rounds client-side, or skip the challenge/response and do all hashing rounds server-side. |
|
Jul 13 |
awarded | Commentator |
|
Jul 13 |
comment |
Challenging challenge: client-side password hashing and server-side password verification I studied the protocol. Am I right that one still needs to calculate the PBKDF2 client-side? If so, using SRP only helps the challenge-response, but does nothing to improve the key stretching. |
|
Jul 12 |
comment |
Challenging challenge: client-side password hashing and server-side password verification Thanks for the suggestion. This looks indeed useful. Unfortunately, I was only able to find two Javascript implementations (srp-js, which appears to be abandoned/incomplete), and Clipperz (which is bulky and requires a 430 KB Javascript download each time a user tries to log in). Native support by the major browsers is currently limited to Firefox. I read this Nonetheless does this seem the way to go. I keep looking for a lightweight SRP implementation in Javascript + PHP. |
|
Jul 12 |
revised |
Challenging challenge: client-side password hashing and server-side password verification Slightly changed wording to improve clarity |
|
Jul 12 |
awarded | Editor |
|
Jul 12 |
revised |
Challenging challenge: client-side password hashing and server-side password verification Corrected spelling of eavesdropper |
