I'm late to the party and need to be caught up. I'm doing my homework looking things up. I know that I don't want unsalted challenge-response CRAM, I want salted challenge-response SCRAM.

I think ASP.NET MVC sends cleartext passwords over the wire from what I can tell, and relies on https for security. WebSecurity.Login has username and password fields that are exposed in the controller.

I know I shouldn't roll my own security. Preferably I want to implement a standard that is easy to use and hard to screw up. I want people who work with the code 10 years from now to be able to support/upgrade it without pulling out their hair.

Just in case I need to do some heavy lifting, I have been looking at CryptSharp's sCrypt implementation. On Tony Arcieri's blog I he has a this image comparing different hardware costs to crack a password.

enter image description here

I don't know how legit this is or exactly what the numbers mean (10 char KDF vs a 80-char text KDF), but what I understand from the grid is that SCrypt is fast (64ms) if you know the password, but costs a lot of hardware resources / money to generate a rainbow table for it, and that it can cost substantially more hardware resources than either PBKDF2 and Bcrypt. Please don't mistake this for me pretending to know anything about these 3 KDFs, I'm blindly trusting the internet here.

Also if I end up having to implement SCRAM myself, am I correct in my understanding that the client and server need to generate the same value? And if so, are there any best recommended javascript+server KDF implementations that get along better than others?

Any insights you guys have will be much appreciated, I'm really in the deep end here. Thanks!

1 Answer 1


If you are talking about a web site, there is no benefit to protecting the password on the wire.

If the connection between the user and the website is compromised, an attacker can send the user compromised pages/scripts that leak the password before encrypting or hashing it.

A client-side key derivation scheme in JavaScript will also be unpalatably slow, whereas an attacker would be able to use fast native code instead.

So if you need to protect the password on the wire simply protect the whole connection using SSL, and leave it at that.

  • Thanks bobince. I tested out SCrypt with .net code and it was reasonably fast. Waiting 1 second to ensure that stolen passwords can't be brute forced and are rainbow proof is probably worth it. Dec 9, 2013 at 1:06
  • 1
    And yes IE and FF were unacceptably slow. SSL should be good enough. Dec 9, 2013 at 1:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .