How can I add a layer of security to cleartext passwords and SSL?

Question

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?

score 2 · Answer 1 · answered Apr 22 '14 at 21:50

2

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

answered Apr 22 '14 at 21:50

Thomas Pornin

326,555
60
792
962

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

score 1 · Answer 2 · edited Apr 13 '17 at 12:48

1

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

edited Apr 13 '17 at 12:48

Community

1

answered Apr 22 '14 at 23:30

Gordon Davisson

2,611
1
18
13

Is this similar to the Challenge-Response protocol? – Professed3376 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 03: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. – Professed3376 Apr 23 '14 at 03:21
According to this answer, OpenSSL.NET supports TLS-SRP. – Gordon Davisson Apr 23 '14 at 03:42

score 0 · Answer 3 · answered Apr 22 '14 at 22:00

0

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.

answered Apr 22 '14 at 22:00

PTW-105

1,397
9
7

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. – Professed3376 Apr 22 '14 at 23:51

How can I add a layer of security to cleartext passwords and SSL?

3 Answers3

Linked