I'm creating a web API in .Net for a web application. I'm wondering what the industry standard for login authentication is.

I know that most people believe that sending cleartext username/passwords over SSL is enough security, but I don't want to place all of my trust that SSL won't be broken in the future and I'm a firm believer in security in layers.

How else can I add more layers of security to my login authentication besides SSL and cleartext usernames/passwords? Client side encryption? Challenge-response?


If you believe in layers, then add some layers. For instance, run your SSL within another SSL, and arrange for the two SSL layers to use distinct algorithms (e.g. the outer SSL works on AES encryption and an ephemeral Diffie-Hellman key exchange, while the inner SSL uses RC4 encryption and RSA-based key exchange). This is undoubtly layered, and, as far as layers go, probably the best that you can get (notably, it is relatively obvious that you do not harm your security that way).

| improve this answer | |
  • Never thought about it this way. I guess the chances of all of the different types of SSL getting hacked are very slim. – Chrisgozd Apr 22 '14 at 23:47
  • Thomas , would NaCL over TLS would do no harm , similarly ? – hulkingtickets Dec 26 '14 at 11:59

Given the problems we've seen with SSL recently (both CA-side issues and implementation bugs), I agree that having another layer of security protecting the password is a good idea. The best option I know of is the Secure Remote Password protocol (wikipedia, Stanford, crypto.SE) -- ideally, combined with a slow hash function like scrypt or PBKDF2.

Using SRP, a network-based attacker who has completely broken the SSL layer cannot gain any information about the password (or anything that can be used for e.g. a pass-the-hash attack), and even a complete server compromise will only leak the verifier (which would require a dictionary attack to recover the password).

| improve this answer | |
  • Is this similar to the Challenge-Response protocol? – Chrisgozd Apr 22 '14 at 23:48
  • It's a form of challenge-response protocol, but unlike some others it doesn't require that the server store anything password-equivalent (i.e. anything that could be used to impersonate the client). BTW, this could be combined with Thomas Pornin's suggestion by using TLS-SRP as the inner SSL layer. – Gordon Davisson Apr 23 '14 at 3:17
  • I've been looking at SRP tonight, and i'm trying to find a sample in c# but there doesn't seem to be any. – Chrisgozd Apr 23 '14 at 3:21
  • According to this answer, OpenSSL.NET supports TLS-SRP. – Gordon Davisson Apr 23 '14 at 3:42

Since you're building an API from scratch, you could implement a hashing function where a SHA256 (or whatever) hash is put on the username and password matrix and submitted. In this way, only the hash is sent over the wire. This isn't an end-all-be-all solution, but it's just another layer.

| improve this answer | |
  • Assuming SSL is compromised, as this thought exercise requires, this does protect the username/password from direct exposure. However it does not protect it from eventual compromise by brute-force against the hash. It also doesn't protect it against reuse by the attacker - effectively, the hashes have become the username & password and the attacker would just replay those over the wire. – Iszi Apr 22 '14 at 22:26
  • @Iszi - Correct. You're really looking at the confidentiality of the password and username. Granted, nothing is hack-proof anymore, hence why the OP wants layers of security. Pass-the-hash is a very real issue in this scenario, but again, this is focused on the confidentiality of the password. This idea is actually inspired by my irritation with password length limits on website authentications (as properly implemented hashing on passwords shouldn't have a length limit). – PTW-105 Apr 22 '14 at 22:32
  • @Iszi - Provided that each user has a different hash, the attacker would have to run a dictionary attack on each separate hash that they were able to obtain. Since you're saving the hash in the database already, it also might be useful to change up the hash every so many days which would add another layer of security. I'm a little bit weary of storing the hash in the database at all, just adds a little bit of security to know that even if the attacker got the whole database, if there are no hashes its impossible to get the passport out. – Chrisgozd Apr 22 '14 at 23:51

Your Answer

