Member Avatar for scaiferw

I'm dipping my toe in the water of salted passwords by upgrading an older webapp, and would like to present the rough outline of how my system would work in the hope that those with more experience than I might tell me if I'm going in the right direction;

In general terms:

***** SET/CHANGE PASSWORD *****

$salt = md5(time());
$salted_password = hash('sha256', $salt . $_POST['password']); // Hash the password

Insert $salt and $salted_password into the database user table

***** LOGIN *****
Pull salt from database
Prepend salt to submitted password, generate SHA256 hash to compare against password from db

Attempt to pull user record from database using username submitted and password hash just generated:
"SELECT * FROM usertable WHERE user = '...' and password = '...' LIMIT 1" (username and password values are escaped)

If row count is less than one, present error message and close page.

Otherwise, set cookies, user is logged in.

Am I on the right track here? From what I've read, a sha256 hash with a unique salt of 32 characters would be pretty robust, but I'd like to have someone else look at this to tell me if there's some glaring, or even subtle, logical error here.

Your assistance is appreciated.

Rob

Edited by scaiferw
  • 4 Contributors
  • 8 Replies
  • 194 Views
  • 4 Hours Discussion Span
  • Latest Post Latest Post by diafol
Member Avatar for blocblue

You're going along the right lines, although one reason for salting passwords is that if your database should be comprised, your passwords cannot easily be broken.

By storing the salt in the database, you're almost entirely removing that added protection.

I would suggest either:

  1. Using a single salt for all passwords and storing it elsewhere (separate from your database). If using a single salt, you need it to be constant. Using time() would not provide a constant salt.

  2. Or if you really want to store it in your database, making the algorithm that salts the passwords far more obsure - e.g. split salt into separate parts, reverse it, then append to beginning and end of the password. I.e. something that cannot be easily replicated without the codebase.

Edited by blocblue
Member Avatar for scaiferw

From my reading, it seemed that a constant salt introduces a significant weakness, and that storing it in the database is fine (or even necessary with unique salts) as long as it is unique for each user.

I could obfuscate the salting as you suggest, but realistically, I think that if someone gets to the salts, they're already inside so trying to lock the door at that point seems futile - what do you think?

Further comment by one and all is welcome.

Edited by scaiferw
Member Avatar for blocblue

I disagree that having a single salt is any weaker. And nearly every open source software I have used, e.g. WordPress, Kohana, FuelPHP, etc all use a single salt for their authentication.

With regard to locking the door seems futile, it depends how your application is breached. If the server is compromised, then you're royally screwed and a salt won't do anything anyway.

If your database is compromised through SQL injection, then having the salt stored in the database would be a huge security flaw. But SQL injection wouldn't mean the hacking party would necessarily have access to your source code too.

Member Avatar for scaiferw

Good comments, thank you. A particularly good point that hacking the db doesn't mean access to the source code.

Always useful to get another perspective rather than just going with what I have.

Member Avatar for Dani

We salt passwords uniquely for each user and store them in the database, because that is how vBulletin did it. When we migrated to our own platform, it just made sense at the time as the easiest way to not require everyone to create a new password.

In order to log into the site, both your username and encrypted (yet unsalted) password are stored in an encrypted cookie that uses the same salt for everyone. So, even if you did gain access to the database, you wouldn't be able to do very much with it because you'd be unable to rebuild a usable cookie in order to log in.

Member Avatar for blocblue

In order to log into the site, both your username and encrypted (yet unsalted) password are stored in an encrypted cookie that uses the same salt for everyone. So, even if you did gain access to the database, you wouldn't be able to do very much with it because you'd be unable to rebuild a usable cookie in order to log in.

Isn't the point that most hackers will attempt to find the raw passwords from the hashes stored in a compromised database using dictionary attacks and the like?

They'd then be able to login using the standard website login functionality.

Member Avatar for Dani

Actually, yeah, I suppose you're right.

Member Avatar for diafol

Some time ago, I started double hashing pws (with salts in first hash only). Does this provide any additional protection? I assumed it did as rainbow tables wouldn't work. But, is there a flaw to this way of thinking?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.