XF Salting!

James

Well-known member
What is being done about XF's salting algorithms? I read that you support multiple algorithms but what about the default one?

vBulletin use the salt but they use it in a way which renders this salt completely useless. Everyone knows vBulletin's algorithm, the salt is stored in a very subtle *cough* database named "salt" which makes this salt useless. The salt, the password hash and the algorithm mean that this salt isn't doing its role.

I think that the salt should be a unique string that is generated on every unique download (so that everyone's software has a different salt) and I feel that this salt should be stored in the filesystem and not the database.

Yes, it makes your passwords less secure in the sense that one-salt-fits all, but at least if your database is dumped your user passwords are still secure!
 
I think that the salt should be a unique string that is generated on every unique download (so that everyone's software has a different salt) and I feel that this salt should be stored in the filesystem and not the database.

Aren't vBulletin's salts unique for each installation/copy? Having the salt hardcoded into the software so that it's the same on every installation would completely defeat the purpose of the salt. :rolleyes:

As far as storing it in the filesystem, I tend to disagree. It would be much easier for someone to access a file on an insecure hosting environment (or if the file/directory is CHMODed wrong, etc.), than get the database details to access the database (3.8.6 not withstanding). ;)
 
vBulletin generates their salts unique to each user, the salt is then stored in the database in the corresponding row (at least it was for 3.x series). I figure if someone's going to get your password, the salt is there in the table along with it (making the salt useless) and if they didn't design it with this in mind why didn't they just use a single md5 hash to obfuscate the password from the user viewing the table.
 
I figure if someone's going to get your password, the salt is there in the table along with it (making the salt useless) and if they didn't design it with this in mind why didn't they just use a single md5 hash to obfuscate the password from the user viewing the table.

Salts are designed to protect against brute-force attacks and rainbow tables, not someone getting access to your database. :)
 
Salts are designed to protect against brute-force attacks and rainbow tables, not someone getting access to your database. :)

and if you use a filesystem salt then you can prevent someone getting user passwords even if the database is dumped and vice versa. A password is no good without a salt and a salt is no good without a password hash!
 
I notice that Kier looks at the same points as myself:
Therefore, if a hacker exploits a vector to gain access to a password database and the salt values are stored together with the password hashes, it will not matter if the salt value is three characters or three-thousand - exactly the same amount of work is required to and break the hash.

An official response on this would be great! *waits for Mike/Kier*
 
Honestly it just seems like the probability of someone gaining access to the filesystem is greater than someone gaining access to the database. If you have the salt, it doesn't matter if you have the password hash or not. You would still have to brute force it, even if you had the password hash. It's just that now you know you have to do:
Code:
md5("thesalt"+$random_values);

I do certainly hope that they use a better hashing function than MD5, which has been considered cryptographically broken for a while now. :)
 
If you have a randomly generated salt per user and a per site key, you make the hashing moderately more complicated but do not expose the user passwords to rainbow attacks. They would need both the user salts and the site key. The caveat here is that if they get access to the database through a server exploit, they can probably access your files as well.

Since hashing is cheap, this is a moderate solution. If you mix you hashing methods, you make it a little more difficult. If you use PHP's hash() function, you gain access to SHA256, SHA384, and SHA512 algorithms. Whether or not these longer strings are necessary to secure forum passwords is another debate.
 
If you have a randomly generated salt per user and a per site key, you make the hashing moderately more complicated but do not expose the user passwords to rainbow attacks. They would need both the user salts and the site key. The caveat here is that if they get access to the database through a server exploit, they can probably access your files as well..
A filesystem key and a database salt would be the best solution - the chances of users accessing both are much, much slimmer.



Since hashing is cheap, this is a moderate solution. If you mix you hashing methods, you make it a little more difficult. If you use PHP's hash() function, you gain access to SHA256, SHA384, and SHA512 algorithms. Whether or not these longer strings are necessary to secure forum passwords is another debate
Another debate for another day. I don't particularly think it matters with open-sourced software considering the algorithm is completely visible anyway!
 
vBulletin use the salt but they use it in a way which renders this salt completely useless. Everyone knows vBulletin's algorithm, the salt is stored in a very subtle *cough* database named "salt" which makes this salt useless.

This is patently incorrect. Can you explain why you think this to be true?
 
this is the same thread that was posted on vb's website. The way the authentication is done using salt/double md5 is good enough. What you are suggesting is relying on something like TPM and that is massive overkill for a forum package. There is an obvious solution to hackers brute forcing your passwords: force password changes after x days; where x< rainbow/brute force time to solution. Salt is regenerated, password is changed, no more problem. Nobody is going to try breaking that sort of combination when it's much easier to hack cpanel, awstats, or countless other scripts that may be on your server/shared hosting.
 
vBulletin generates their salts unique to each user, the salt is then stored in the database in the corresponding row (at least it was for 3.x series). I figure if someone's going to get your password, the salt is there in the table along with it (making the salt useless) and if they didn't design it with this in mind why didn't they just use a single md5 hash to obfuscate the password from the user viewing the table.

It doesn't matter, if they have access to the database with the password, and they can also get the salt, it's still hashed, you'd have a huge rainbow table per user.. But if you have access to the datatabase it's not important, because you can just change the data in the database anyway.
 
There is an obvious solution to hackers brute forcing your passwords: force password changes after x days; where x< rainbow/brute force time to solution.

This would be extremely annoying to end users. Why not just use a stronger, more expensive (computing-wise) hashing function?
 
go for it. XF is flexible in that area, vb is not.

also gotta think about: how much damage can a compromised user account do?
on my forum.. not much. moderators / admins that's a different story... and you could force password changes on those groups and spare the rest. If you used SHA salt wouldn't even be necessary.
 
and if you use a filesystem salt then you can prevent someone getting user passwords even if the database is dumped and vice versa. A password is no good without a salt and a salt is no good without a password hash!

If you used a salt in the file system and then merged your board or moved it to a different license for some reason, you just lost access to every password. The salt with the record is the only portable way to go.
 
Top Bottom