¿Bcrypt (4) (= 4 iteraciones) versus SHA512 o algo diferente con sal única por contraseña?

Antecedentes:

I want to add a login to my small site, which is an online php application, which I'd like to build to be able to bear much user activity in the future.

Before I look further into implementing LightOpenID I want to add a normal login. The book I was learning from is called Head First PHP & MySQL (2008) and the final code of the chapter uses SHA('$user_password') as part of the mysql query.

As I take interest in Jeff Atwood's writing I'm well aware of bcrypt as of scrypt. But seen as there's no php implementation of scrypt and having no dedicated server to run it, I decided to at least look into implementing bcrypt for now.

However I'm not completely naive, I know I should watch out not to overextend my very humble hosting resources. The php app itself should always come first before anything else concerning resources.

Andrew Moore's method seems nice (though I'll have to see how to implement it on php 5.2.17 which my host uses) and it comes with a tip for hardware speed:

You should select a number of rounds that results in 200-250 ms of work. Part of the reason why bcrypt is secure is that it is slow. You must ensure to have a number of rounds that keeps that characteristic. – Andrew Moore

Another user states that for him running microtime() gives 0.314 for Bcrypt(9), which thus would be near optimal.

La pregunta:

Seen as I only have very humble resources at my disposal and I'd like to make the best of them, leaving most for the php app itself, am I still better off using Bcrypt(4) instead of something else?

Bcrypt(4) returns true almost instantly, but does it still keep that characteristic Moore talks about?(Would that be the part concerning RAM that makes it harder for GPU bruteforcing?) Or would SHA512 o algo mas actually be as fast but more secure at this point?

I'd expect Bcrypt(4) to win in this situation, but the hell do I know right? :p

preguntado el 28 de julio de 12 a las 20:07

5.2 is ancient. Either yell at, or replace, your host. -

It's a very decent host otherwise, while being amazingly cheap, I think this is more of a upgrade to a virtual dedicated server, than a change host entirely, issue. Which is something for the feature. -

3 Respuestas

Security is always about what you are trying to secure.

If you are more concerned about your resources than about your security, bcrypt(2) is already overkill. No hacker will ever try to break that for a normal application, having easier target sites like LinkedIn and many others, which just use functions from the sha family, with a single iteration, and unsalted. They will go for the 'low hanging fruit'. Or they could keep trying to hack your application, just not in the password encryption part.

SHA-512 is not much more secure than SHA-1 as password hashing algorithm [1], it has not been designed for that purpose. They can still be used as primitives for creating secure cryptographic algorithms though, but that's something no single person should do. To be considered secure, crypto algorithms must be public to be peer reviewed, and must pass the test of time. And obviously, must be designed for what you are going to use them. MD5, SHA-X, etc. are cryptographic algorithms, but weren't designed for storing passwords.

Just add or remove rounds to your bcrypt. In this case I would use 1 or 2. Also keep in mind that 1 round != 1 iteration. They are increased exponentially. If you read about how bcrypt works, you will see that there is much more to it than just iterations. For example, you mentioned 'unique salt per password'. Bcrypt already has that.

[1] For other things it's obviously more secure

Respondido 29 Jul 12, 00:07

I didn't put much focus on details of the log part, as I understood it 4 stands for $log_2_rounds which is "log of the round count" (as Matthew Flaschen wrote in the comments there). And yes I know that the salt is already an integral part of the generated hash in bcrypt. - Suzy

@Suzy Well I'm sorry that you didn't like my answer, but you are not gonna find anything better than bcrypt. You already know scrypt, but you won't be able to take advantage of it. And even if you could, there's no point in worrying about this. - ChocoDesarrollador

I didn't said I didn't like your answer :p It's informative, I'm just not immediately hitting accept on the first answer I get. - Suzy

"SHA-512 is not much more secure than SHA-1, it has not been designed to be so." eso es incorrecto. The although SHA-512 is uses similar techniques to SHA-1, the inner workings of a round of SHA-512 are much more complex and more difficult to break. The inner block size and output size have been expanded as well. Why do you think they designed the SHA-2 family in the first place? It's not speed, SHA-1 is faster than any SHA-2 algorithm. - Maarten Bodewes

@ChocoDeveloper I'm downvoting as the the information that I've indicated is incorrect. This is a question about security and your advice should take that into account. I'm not trying to bash you in any way, and I would be happy to upvote instead if you change or update the information. You could e.g. indicate that using SHA-1 or SHA-2 isn't all that important for key derivation functions, instead of the blanket statement that "SHA-512 is not much more secure than SHA-1". Your answer is otherwise certainly correct. - Maarten Bodewes

You should look at security of the system, not just of bcrypt.

Certainly, if you want to store passwords, bcrypt or PBKDF2 is the way to proceed. Make sure you use a sufficiently large, random salt per user or password. Then try to maximize the number of iterations. If that's small, then it is small, but any iteration more is better than nothing.

Note that this does little against eavesdropping or man in the middle attempts (MitM). You should use SSL for that; the password or the hash (if you do the hashing client side) can be replayed otherwise.

Furthermore, if you want to protect against brute force attacks (attackers trying the most common passwords) you should create (or copy) a good password management scheme. Limit the amount of incorrect logins and try to let the users create strong passwords. Also limit the amount of information you return to your user regarding incorrect logins, that user may be the attacker.

Respondido 28 Jul 12, 23:07

Yeah I was already planning on setting something up to force users into creating safe passwords. And even of making a small paragraph explaining as to why it matters and suggesting semi-passphrases. =) - Suzy

I'll look into client side hashing later, I'm not sure if there are downsides to it other than running it in slower javascript on a possibly very slow machine, which perhaps makes it require a speed test. But it could give the user the option to choose his/her own iteration count! (along with taking some strain off the server!) - Suzy

What exactly do you mean with "limit the amount of information" though? Would it be wrong to communicate the amount of attempts left for the chosen time interval? Like: "You have 4 attempts left, after that you'll have to wait 1 hour before trying again." - Suzy

E.g. many sites nowadays say "username and password combination are invalid" instead of mentioning which one is wrong. Returning how many login attempts are left may be required not to piss your users off, of course. Nobody is helped with an uber secure system that nobody uses. But mentioning that you've got one attempt left may be enough. - Maarten Bodewes

Or would SHA512 or something else actually be as fast but more secure at this point?

Slowness is a major feature of password hashing algorithms (of which, bcrypt is one, but SHA-512 by itself is not) - the slower your algorithm is (relative to other algorithms), the harder it is for an attacker to brute force passwords based on the hashes. From this perspective, a single round of SHA-512 is less suitable than bcrypt for the purpose of securely storing passwords, because it is considerably faster.

In my opinion, the best approach to take is to pick a password hashing algorithm (bcrypt, PBKDF2, scrypt) and then tune the work factor to give you the best tradeoff between speed and security, given the computing resources available to you and the characteristics of your system. A higher work factor = more secure, but also more resource-intensive.

The good news is that users typically use your login function infrequently compared to other functions, so the impact of a slower/resource intensive login function is generally not a big problem.

Respondido 29 Jul 12, 00:07

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.