4
$\begingroup$

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.

Edit: Now everyone should be using scrypt or argon2 for password hashing with unique salts.

Improve this question
$\endgroup$
2
  • $\begingroup$ Why not SRP and encrypt the verifier in the database using a AES and ensure that the AES key is in the configuration of the application server kept segregated from the database and its backups? $\endgroup$
    – simbo1905
    Oct 4, 2015 at 21:00
  • $\begingroup$ And why not bcrypt the password as input to SRP to protect against dictionary attacks as per crypto.stackexchange.com/a/29824/13860 $\endgroup$
    – simbo1905
    Oct 16, 2015 at 16:50

2 Answers 2

Reset to default
3
$\begingroup$

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

Improve this answer
$\endgroup$
6
  • $\begingroup$ 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. $\endgroup$
    – 133794m3r
    Sep 11, 2012 at 0:20
  • 1
    $\begingroup$ @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. $\endgroup$
    – Thomas Pornin
    Sep 11, 2012 at 0:45
  • $\begingroup$ 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. $\endgroup$
    – 133794m3r
    Sep 11, 2012 at 1:07
  • $\begingroup$ 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. $\endgroup$
    – Maarten Bodewes ♦
    Jun 12, 2014 at 13:29
  • $\begingroup$ @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. $\endgroup$
    – Thomas Pornin
    Jun 12, 2014 at 13:33
2
$\begingroup$

tl;dr don't trust HTTPS alone use it as one part of layered security and do use SRP always. bcrypt the password as input to SRP for additional protection. AES encrypt the verifier in the database for additional protection of the offsite backups.

Hashing the password with bcrypt on the client only makes it harder to recover the password if the server's database is captured. It does not protect against interception. 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. 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.

With SRP there can be no replay attack as each login attempt has to perform a password proof for a fresh server-generated random challenge. Using bcrypt alone someone can intercept what the client sends to the server and they can login as the client until the client changes their password. With SRP an intercept is useless. bcrypt of the password as input to SRP slows down a dictionary attack if the verifier is stolen. Encrypting the verifier with AES in the database reduces the risk of the verifier being leaked.

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 operational complexities inherent in maintaining a secure HTTPS site correctly and due to commercial man-in-the-middle software routinely deployed by large corporations.

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 web servers through to application servers, then the 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 web proxy which decrypts, scans, then re-encrypts, and forwards to the external sites. (Edit: Actually a colleague just told me that IE can be configured to offload encryption to the local web proxy although I have not confirmed this personally.) This 'attack' is done to prevent rogue employees from stealing client data or corporate intellectual property. (Or to prevent employees tunneling file sharing protocols over HTTPS). See https://security.stackexchange.com/q/63304/45960 for one example. 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 behavior identical to heartbleed. The application server software was upgraded but the web server 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 went live.

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

Improve this answer
$\endgroup$
2
  • $\begingroup$ 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. $\endgroup$
    – Paŭlo Ebermann
    Jun 12, 2014 at 19:21
  • $\begingroup$ @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. $\endgroup$
    – simbo1905
    Jun 13, 2014 at 6:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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