Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

OK, here's the two different ways I was thinking about making the authentication for the login thing to store the passwords securely.

The first is the following.

Client hashes password bcrypt(username.static_salt.password)(cost is 7)

this is mostly to make it harder for someone to get in trouble if they reuse passwords in other places/to make me feel better.

then they send it to the server. The server then hashes it with bcrypt again(cost is7) there is a per-user salt which is appened to the user's password and hashed together. Another static salt stored in the code(ie for bcrypt itself) is in there. And we have another salt stored on the server(ie no database).

The other one is to use srp6a except to use bcrypt(with the same cost as above) for H(). Which of these is more secure in the long run against an attacker once they get the database. the N is going to be 2048bits.

Also assume all of this is done over TLS/SSL. I'm personally leaning towards the first one, but I want to be sure before I commit to one or the other.

share|improve this question

2 Answers 2

You should not assume that you will have good SSL/TLS in the form of HTTPS to your clients for reasons which I will outline in detail below.

Hashing the password with bcrypt on the client only makes it harder to recover the password if the servers database is captured. With SRP you get more benefits as described in this excellent answer by @poncho:

The security goal behind SRP is that an attacker that could either pretend to be a client (and attempt to log into a server that knows the key), pretend to be a server (and allow clients that know the key to attempt to log in), or actively monitor (and modify) the communications between a valid client and a valid server, would learn nothing from an exchange, except possibly whether a single password is valid or not.

As @Thomas points out if you have SSL/TLS such as HTTPS then in theory you know that you are talking to the correct server, with no man-in-the-middle, so you are safe. This theory is demonstrably unsound in practice due to the operationally complexities inherent in maintaining a secure HTTPS site correctly and due to commercial man-in-the-middle software routinely deployed by large corporatations.

The Heartbleed bug leaking unencrypted text from the server had existed for long enough that an estimated 17% of HTTPS sites were vulnerable. Once it was a known attack people demonstrated it against famous sites damaging the reputations of those sites. Those sites could have been secure had they used SRP over HTTPS.

Many large corporate websites only use HTTPS into the public facing DMZ and then use plain text from the webservers through to application servers, then plain text from the application servers to the database servers. This potentially risks plain text passwords being leaked in log files, or being recovered by malicious employees or contractors maintaining the infrastructure. SRP protects against this.

Large enterprises such as global financial services firms routinely run main-in-the-middle scanners between their employees and external HTTPS sites. There is commercial software for this which is not widely advertised. (I know someone who was a consultant for HP installing such software for large corporates for two years). This relies on the fact that employees use a browser which accepts a certificate from the corporate webproxy which decrypts, scans, then reencrypts, and forwards to the external sites. (Edit: Actually a colleague just told me that IE can be configure to offload encryption to the local web proxy although I have not confirmed this personally.) This 'attack' is done to prevent rogue employees stealing client data or corporate intellectual property. (Or to prevent employees tunneling file sharing protocols over HTTPS) Such software may leak passwords into log files or have a bug which compromises passwords or be maintained by malicious employees or contractors who might attempt to recover passwords.

Finally I have personally seen a mistake in upgrading an online banking website where a misconfiguration between the versions of software deployed led to behaviour identical to heartbleed a decade before. The application server software was upgraded but the webserver plugin was not correctly updated to the matching version by the deployment script. The website ran fine yet pen testers throwing scripted attacks at the site got back plain text chunks of memory. They captured the customer support managers password whilst she was doing testing of the upgraded in a test environment (accessible via IP whitelist only) the week before the release was to due to go live. We rapidly fixed it then added two factor authentication to the site at considerable cost. Had we known about SRP and had used that we would have been less vulnerable had the pen testers not found the problem before the software upgrade we live.

In short don't trust HTTPS alone use it as one part of layered security and do use SRP always.

P.S. Even if you use two factor authentication you should still use SRP for the password to guard against a social engineering attacks where someone get the password then rings customer support and impersonates the customer saying that they have lost their token and is given a one-time override.

share|improve this answer
    
Your answer explains why HTTPS is to be considered not secure enough, though it doesn't answer the question at all, which is whether SRP or a double bcrypt is better. –  Paŭlo Ebermann Jun 12 at 19:21
    
@PaŭloEbermann Yes you are correct. Thanks for not downvoting. Since the other answer at this time says that the point of SRP is to remove the need for SSL/TSL yet people should use both my enthusiasm got the best of me. –  simbo1905 Jun 13 at 6:04

The point of SRP is to remove the need for the SSL/TLS certificates. With SRP integrated into SSL/TLS (as per RFC 5054), you get mutual client/server password-based authentication and can do without any of the dreadful certificate business; and yet the protocol is still resilient to offline dictionary attacks.

If your SSL/TLS still uses a server certificate then there is little point in using SRP; the client already knows that it talks to the right server, and can send the password as cleartext within the tunnel (or a hash-of-password if you really need that to sleep at night).

share|improve this answer
    
I wanted the ability there to make it as hard as possible to have someone figure out the user's passwords once they get the database. I'm planning on using ssl/tls upon the time I'm officially releasing it, because I'd rather not pay for the certificate until it's ready to go out. So basically then, SRP is for non-ssl, and it provides next to no additional security to passwords at rest when compared to plain bcrypt with teh work factor cranked up as time goes on. –  133794m3r Sep 11 '12 at 0:20
1  
@133794m3r: if you want to combine SRP with bcrypt, use bcrypt on the password on both client and server, and use the output of bcrypt as the "password" that SRP wishes to use. –  Thomas Pornin Sep 11 '12 at 0:45
    
wait, so just so I understand this all. SRP would only allow me to have salts that the users or any potential hacker can ascertain correct? My previous comment was rather stupid and I'm going to delete it along with unedit my edited question. –  133794m3r Sep 11 '12 at 1:07
    
One of the reasons for a PBKDF used on the server is to make sure that if somebody steals the database, then the other person cannot log in. Calculating the output on the client and sending it over removes that advantage. You could do the PBKDF (bcrypt) twice - once on the client and once on the server - if you want to keep the output of the PBKDF secret to attackers as well. –  owlstead Jun 12 at 13:29
    
@owlstead: there are two distinct points: 1. we don't want to store on the server something which is "password equivalent"; 2. the complete processing, from the password to whatever is stored on the server, must be proper "password hashing" with iterations and salts. You can have that with PBKDF2(password) computed on the client side, and SHA-256(PBKDF2(password)) stored on the server. That way, the server-side operation is very fast, and stealing the server's database still does not grant easy entry. –  Thomas Pornin Jun 12 at 13:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.