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
add comment

1 Answer

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
@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
add comment

Your Answer


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.