1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XF Salting!

Discussion in 'XenForo Pre-Sales Questions' started by James, Aug 4, 2010.

  1. James

    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!
  2. Erik

    Erik Well-Known Member

    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). ;)
  3. James

    James Well-Known Member

    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.
  4. Erik

    Erik Well-Known Member

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

    James Well-Known Member

    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!
  6. Forsaken

    Forsaken Well-Known Member


    If you scroll down to 'Seasoned Authentication' you'll see that Kier talks about password security (Not for XF, just in general).

    I am sure whatever method they've used is likely to be one of the better options, and highly secure.
  7. James

    James Well-Known Member

    I notice that Kier looks at the same points as myself:
    An official response on this would be great! *waits for Mike/Kier*
  8. Erik

    Erik Well-Known Member

    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:
    I do certainly hope that they use a better hashing function than MD5, which has been considered cryptographically broken for a while now. :)
  9. James

    James Well-Known Member

    I'd bet they're going to use SHA1, SHA256 or even SHA512 to be honest - anything more secure than MD5!
  10. Koleckai

    Koleckai New Member

    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.
  11. James

    James Well-Known Member

    A filesystem key and a database salt would be the best solution - the chances of users accessing both are much, much slimmer.

    Another debate for another day. I don't particularly think it matters with open-sourced software considering the algorithm is completely visible anyway!
  12. Koleckai

    Koleckai New Member

    Well with 256 and 512 byte strings, your rainbow tables are exponentially larger so there are a lot more combinations to check.
  13. Erik

    Erik Well-Known Member

    Visible-source software. Not open-source. ;)
    Derek Ivey likes this.
  14. Enigma

    Enigma Well-Known Member

    This is patently incorrect. Can you explain why you think this to be true?
  15. Brandon

    Brandon Active Member

    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.
    Derek Ivey likes this.
  16. Floris

    Floris Guest

    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.
    Eriksrocks likes this.
  17. Erik

    Erik Well-Known Member

    This would be extremely annoying to end users. Why not just use a stronger, more expensive (computing-wise) hashing function?
  18. Brandon

    Brandon Active Member

    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.
  19. Mike

    Mike XenForo Developer Staff Member

    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.
    Ceri May likes this.

Share This Page