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?


3 Answers 3


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).

  • Never thought about it this way. I guess the chances of all of the different types of SSL getting hacked are very slim. Apr 22, 2014 at 23:47
  • Thomas , would NaCL over TLS would do no harm , similarly ? Dec 26, 2014 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).

  • Is this similar to the Challenge-Response protocol? Apr 22, 2014 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. Apr 23, 2014 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. Apr 23, 2014 at 3:21
  • According to this answer, OpenSSL.NET supports TLS-SRP. Apr 23, 2014 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.

  • 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, 2014 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, 2014 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. Apr 22, 2014 at 23:51

You must log in to answer this question.

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