Password encryption question? salts...

[sourcy]

I have been reading about salts and password encryption, and as such, I wrote this code:

 

 

public function encryptPass($pass, $username)

{

return hash("sha256", "*&*IUujh432" . $username . "12 4398123" . $pass . "jka*&8234hF" . $username . "98fas<HD*F234");

}

 

Is this safe? The reason I am asking is I read that using a user's username is a bad idea since, it's easily guessable as being a hash.

 

However, I feel with adding it in twice in random spots, along with server side random salts is enough to prevent it being easily cracked?

 

Thoughts?

 

And obviously not my real salts.

Edited January 7, 2013 by sourcy

[scootstah]

However, I feel with adding it in twice in random spots, along with server side random salts is enough to prevent it being easily cracked?

 

Eh, no, not really. If using it once isn't secure, then using it twice isn't secure either.

 

Use something like PHPass. Cryptography is hard, you can't just pull some random crap out of your ass and expect it to be secure.

Edited January 7, 2013 by scootstah

[haku]

I usually salt with the timestamp of the user registration.

[sourcy]

I usually salt with the timestamp of the user registration.

 

I feel that this is such a widely used suggestion that it's almost pointless to use it.

 

My new solution is this: md5 their password and then take the first 16 characters (50%) of the returned string and use that as the other part of the salt.... (so it'd still use their username, but also now this two, so no two hashes are the same regardless of matching passwords)

 

I'm not sure how smart this is either.

Edited January 8, 2013 by sourcy

[haku]

 

 

I feel that this is such a widely used suggestion that it's almost pointless to use it.

 

Just because it's widely used doesn't make it any less valid of suggestion for a salt. Or if you feel it is, then you'll have to elaborate as to why.

[sourcy]

Just because it's widely used doesn't make it any less valid of suggestion for a salt. Or if you feel it is, then you'll have to elaborate as to why.

 

I don't feel that it's invalid, in fact, I'm not really sure what's a good idea and what's not. However, that said, I do have some background in security with regards to the web, securing sites, and how to break them.

 

I'm implying that since attackers have access to all of the same information re: how to secure a system, they also know common tricks that are used such as use a time-stamp.

 

Therefore, they can still likely guess that their salt may be a timestamp, or something similar.

 

However, realistically, an attacker would create an account on the site, register, and then when they've compromised the DB, find their own hash and work out how it could possibly be encrypted. (works unless the password is salted within the actual encryption function). Somethings an attacker theoretically might think of using are username, timestamp or even a column field named "salt" lol.

[haku]

If a hacker has compromised your database, then your salts become pretty irrelevant, as they can get access to your file system by including PHP code in a database column, executing it, and thereby gaining access to the file system which will then give them your salt logic.

[Jessica]

There are various levels in which data could be compromised. It's entirely possible to data to be leaked and not allow inserts. Also just saying PHP could be placed in a database, doesn't mean it can be executed unless the existing PHP code allows for that. Which is a good reason to NEVER DO THAT.

[scootstah]

The only purpose of a salt is so that an attacker must crack each and every hash to obtain the password. That's it. It doesn't have to be super secret, and it doesn't matter if the attacker knows what it is. They still have to generate the hashes individually, so it has served its purpose.

 

Running hash functions on random bits of data is doing absolutely nothing in regards to security. If you have a good hashing algorithm, it doesn't matter if the attacker knows how it was computed. They still have to brute force each hash individually. If you use something secure like bcrypt, this will take an unfeasible amount of time (read: years) and so it's just not going to happen.

 

So to summarize: using a good hashing algorithm means that even if your database is compromised, and even if an attacker knows what the salt is, and even if the attacker knows how to construct the hash - you're still safe.