Jump to content



Photo

Why Can't You Hash a Password Multiple Times

password hashing md5 multiple sha1 sha256 php

  • Please log in to reply
56 replies to this topic

#46 Ambroos

Ambroos

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 16-January 06
  • Location: Belgium

Posted 21 July 2013 - 12:30

Is bcrypt hashing secure?

If you use a secure, random salt: yes, probably one of the most secure mainstream solutions there is.




#47 Joe User

Joe User

    Lazy Joe's

  • Joined: 29-May 07
  • Location: Somewhere in the US
  • OS: Windows 8.1
  • Phone: Nexus 5

Posted 21 July 2013 - 18:48

Just another tip, hiding your password creation and verification routines isn't a bad idea.

 

I like to use used an encrypted stored procedure in the database server for logins(In my case MSSQL). You feed it the user name and password, it returns true or false. You can, of course, get more complex, but the design rule was that all logins are validated through the one procedure. You can call it from another proc, from the web server or from any other front end, but that SP was the only way to validate a login.



#48 OP Tjcrazy

Tjcrazy

    Your Average Neowin Guy.

  • Joined: 02-May 09
  • Location: The Cotswolds, United Kingdom

Posted 21 July 2013 - 23:42

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.

 

It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.

 

Am I correct?



#49 +SharpGreen

SharpGreen

    Now with built-in BS detector.

  • Tech Issues Solved: 1
  • Joined: 20-August 04
  • Location: North Carolina
  • OS: Ubuntu 13.04, 12.04 and Windows 8
  • Phone: Galaxy Nexus

Posted 22 July 2013 - 00:48

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.

 

It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.

 

Am I correct?

You should be using salts no matter what you do. But yes, something like bcrypt or a PBKDF solution would be better than using regular hashing methods.



#50 +theblazingangel

theblazingangel

    Software Engineer

  • Tech Issues Solved: 3
  • Joined: 25-March 04
  • Location: England, UK

Posted 22 July 2013 - 01:54

From what I can tell: Multiple hashing a password DOES make it more secure, but only marginally.
 
It's MORE efficient and secure to use more complex hashing methods, like bcrypt and salts.
 
Am I correct?

"Multiple hashing" being more secure - a little bit, yes.

More efficient and secure to use methods like bcrypt and salts - yes and no. Yes, salts absolutely enhance security. Yes, bcrypt (or PBKDF2) is going to be a more secure choice. No, bcrypt (or PBKDF2) are not going to be more efficient, it will require more processing power (on the part of both yourself and an attacker).

My advice again:
  • Stop trying to come up with odd hashing algorithms like this, they're not going to help you at all.
  • Stop using md5/sha1, at least use sha256 or preferably in some cases PBKDF2/bcrypt.
  • Do use a salt and use a different one for each user.


#51 The_Decryptor

The_Decryptor

    STEAL THE DECLARATION OF INDEPENDENCE

  • Tech Issues Solved: 3
  • Joined: 28-September 02
  • Location: Sol System
  • OS: iSymbian 9.2 SP24.8 Mars Bar

Posted 22 July 2013 - 06:36

Just another tip, hiding your password creation and verification routines isn't a bad idea.
 
I like to use used an encrypted stored procedure in the database server for logins(In my case MSSQL). You feed it the user name and password, it returns true or false. You can, of course, get more complex, but the design rule was that all logins are validated through the one procedure. You can call it from another proc, from the web server or from any other front end, but that SP was the only way to validate a login.


I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

#52 sir West

sir West

    Neowinian

  • Joined: 04-April 09

Posted 22 July 2013 - 07:05

what about: sha512(sha256(sha256(sha256(<password>) + <username>) + sha256(<password>) + <password-set-date&time>)) ?

Adding user-specific and different types salting would surely make it harder, no?



#53 The_Decryptor

The_Decryptor

    STEAL THE DECLARATION OF INDEPENDENCE

  • Tech Issues Solved: 3
  • Joined: 28-September 02
  • Location: Sol System
  • OS: iSymbian 9.2 SP24.8 Mars Bar

Posted 22 July 2013 - 07:19

Not really, you're not adding any actual extra work for the attacker, they still just have to come up with one password to test.

Edit: The hard part isn't "How many times do I run SHA", it's "What do I feed the hash function?", adding 3 hash iterations isn't any harder than just 1 hash iteration, it's just ever so slightly slower.

#54 Crimson Rain

Crimson Rain

    Idiot Hater

  • Joined: 29-September 12
  • OS: Windows 8.1 x64
  • Phone: Lumia 1020 Yellow

Posted 22 July 2013 - 07:25

If you are hashing multiple times, it should be with different salts each time.



#55 Joe User

Joe User

    Lazy Joe's

  • Joined: 29-May 07
  • Location: Somewhere in the US
  • OS: Windows 8.1
  • Phone: Nexus 5

Posted 22 July 2013 - 15:59

I can't imagine that being very secure, if somebody attacks your database (Which is pretty much going to be the attack vector) they've then got your custom method for authenticating users.

If the method was properly secure, you could tell the attacker exactly how you're doing it and they still wouldn't be able to break it (Just because the attacker knows you're using bcrypt, doesn't make bcrypt any less secure, etc.)

 

First off, the production database server doesn't see the Internet. It doesn't even have a default gateway. It's locked down to VPN and local server access only.

Second, The stored procedure is compiled with encryption, it's not easily editable, and they would have to break the database security system to figure out how to decrypt it.

Third, I'm using bcrypt, but it's not on the forward facing server, it's out of sight in a stored procedure with much tighter security.

 

So, after breaking the VPN, breaking domain security, and breaking SQL Server security, they've figured out I'm using bcrypt. 

 

Now, if we coded security at the web tier, someone could break into the public facing server and figure out what we're using in far less time. Why make it easy on them?



#56 n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 22 July 2013 - 18:18

If they get access to your web server chances are they'll get access to your database server.

If you think that just because one server itself doesn't have the internet makes it untouchable, you've got a lot to learn. A very early example of netcat was exactly that, hack a web front end, put a netcat remote listener on and then you do what you want to the database server as if it was on the internet.



#57 n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 24 August 2013 - 14:18

Just FYI PHP 5.5 has a new password hashing API;

http://www.php.net/m...ssword-hash.php





Click here to login or here to register to remove this ad, it's free!