.NET SSL login security

Bcrypt on the client is wrong -- this just means that someone can copy the encrypted value, and still log on.

I think you probably want to do challenge-response on the password. Send a one-time code to be hashed with the password (the challenge), and check that it matches what the server expects (the response). This avoids sending any sensitive info over the wire.

So I don't want to store their clear text password in my database. When they signup from the website I would like to BCrypt their PW with their own custom salt. Then store the BCrypt'd value along with the salt in the database.

So given that, now when they sign in from the client application I couldn't just send a challenge down to the client to hash and send back. Wouldn't I have to send the original salt and a challenge code. BCrypt their password with the salt to get the same value stored in the database, then hash with the challenge code and send back to the server. Then the server would take their BCrypt'd pw in the database and hash it with the same challenge code to compare.

Is that valid and secure?



Also, is there any way I can let them signup securely from a client program instead of a website? I'd prefer to do it that way personally. How do things like Steam keep it secure since it's a client install?

The point of requiring bcrypt is to force the SERVER to do a lot of work to verify the password. This is so that any brute-force attacker would similarly have to use that same amount of work to brute-force a password.
You can receive the password unencrypted from the client, if you use SSL/TLS for the communication, such as with HTTPS. Then you can use bcrypt on the server, with salt, and you'll be good.
Challenge/hash for passwords is only required if you are communicating over a clear channel, and in that case, you really need to store something equivalent to the clear-text password in the database. If you store a hash, and verify that the client can calculate hash(challenge, hash(password)), then the client can solve the challenge without knowing password, only hash(password) (which you store in the database).

Also, is there any way I can let them signup securely from a client program instead of a website?
[/quote]
Sure. Exactly what you need to do depends on your definition of "securely". Ensuring the client details are encrypted is relatively easy. However, there are other issues:

• How are you going handle certificate renewal and revocation?
  
• What about requiring users to have a valid email address (e.g. requiring the user to click on a link delivered to said address to activate their account).
  
• If not, how are you going to manage an "I forgot my password" system?
  
• Do you want to require a CAPTHCA to prevent automated account creation?
  
• Does account sign-up involve sensitive personal information or banking details, or is it just nickname/password?
  
• ...
  
  These issues are solvable in both a custom client and a browser, but probably a lot more work in a custom client than in a website / browser situation.
  
  

  
  How do things like Steam keep it secure since it's a client install?
  [/quote]
  I don't understand your question. The browser is also a "client install". They are both equally secure or insecure, depending on your point of view.
  
  From the user's point of view, their machine is the most trusted. From the server's point of view, the client's machine cannot be trusted (without evidence, e.g. username/password). From an attackers point of view, the client's machine is often the vulnerable "weak link" that can be compromised to steal an account.
  
  Again, you need to define the properties of a "secure" sign-up before we can start talking about it.

You can receive the password unencrypted from the client, if you use SSL/TLS for the communication, such as with HTTPS. Then you can use bcrypt on the server, with salt, and you'll be good.
[/quote]

Thanks, that's what I was looking for.


Thanks for the thoughts rip-off