SMF 2.0 RC4 - Passwords stored without salt

[XxMikexX]

Hi all,

whilst implementing an alternative authentication mechanism for my SMF 2.0 RC4 i found a severe security risk:

Passwords are stored in the db without usage of a an additional salt

Currently the passwords are generated using
SHA1(username + password)

This can lead to hashes which can be attacked using rainbow tables (e.g. user: hell, pw: damn)

I suggest for future versions to generate the passwords including the user's salt e.g. SHA1(username + password + salt)

Any suggestions?!

[Arantor]

That's not a security risk. The passwords are already salted, since you need to create a rainbow table for each username.

[XxMikexX]

As already indicated in my post, for user "hell" with password "damn" there is no need to create new rainbow tables.

Why keeping such a risk when you could easily include the password_salt when hashing the password...

[Arantor]

So, assuming you had access to the database, all you get from that rainbow table is that one password. You'd still need to brute force every other password or generate a rainbow table per username.

And if you have the salt... the same thing applies.

I suppose it would be wonderful for keeping users on SMF and not migrating them to another platform (since plenty of other platforms use the same as SMF does, and plenty of other platforms use far weaker ones too)


I can tell you now, it's not going to change in SMF 2.0, I can't really see it changing in 2.1. That assumes the column's going to change so it knows to actually use it in the calculation (or do it twice, once with, once without, which just makes it easier to risk a collision)

[rawlogic]

I guess if I were smart, I'd create a rainbow table for user "admin".

[Douglas]

No, if you were smart, you'd use 2.0 Final and then see if the issue still persists there.  I know that there was a fix put in as far as the login sequence/username/password was concerned since RC4.

[rawlogic]

I've already verified that SMF 2.0 Final uses the same hashing algorithm. Username+Password. The issue persists.

[Illori]

that does not mean that 2.0 does not have the fix elsewhere in the code. try it out then report back.

[rawlogic]

that does not mean that 2.0 does not have the fix elsewhere in the code. try it out then report back.

The issue is that the password field equals SHA1(username + password), not SHA1(salt + password). That, alone, is the issue. So, the issue persists.

If there's something further to test, please explain because I don't understand.

A salt is, by definition, random. The user name isn't random, and hence not a salt. I'm not arguing semantics. A non-random salt fails to meet the parameters, cryptographically, of serving as a salt.

A square wheel has lost its purpose.

[Illori]

is this still an issue? can a developer comment on this?

[Joker™]

To me it looks like to be a very valid security feature which should be implemented in upcoming releases.

Its upto developers to decide whether they want to implement this or not .

[Arantor]

The point isn't to be cryptographically secure, it's to defeat rainbow tables. The fact that you'd have to construct a rainbow table for every user makes it significantly harder to do.

Honestly, though, going to SHA256 would be more important than adding a further salt (especially since there are legitimate times there isn't a salt value in the DB table)

[Joker™]

The point isn't to be cryptographically secure, it's to defeat rainbow tables. The fact that you'd have to construct a rainbow table for every user makes it significantly harder to do.

Yes to that part as rainbow tables tends to grow larger in number and hard disk space ends up with the arrays of randomly-generated chain-start number. Moreover its going to impact bandwidth too in moving the data around.

Honestly, though, going to SHA256 would be more important than adding a further salt (especially since there are legitimate times there isn't a salt value in the DB table)

Thats upto developers whether they want to proceed with SHA2 or not.

[Arantor]

Thats upto developers whether they want to proceed with SHA2 has or not.

I've heard that line an awful lot. Surely the whole point of even having the discussion is to figure out the pros and cons of making such a decision and then for it to be implemented or not, rather than just trotting out the old 'well it's up to the devs'. I guess there's nothing like taking a little responsibility, is there?

[Joker™]

I've heard that line an awful lot. Surely the whole point of even having the discussion is to figure out the pros and cons of making such a decision and then for it to be implemented or not, rather than just trotting out the old 'well it's up to the devs'. I guess there's nothing like taking a little responsibility, is there?

It seems you have read a lot of our posts in 3hr 20mins .

Well I haven't got much of chance to play with SHA2, but seeing the algorithm and key size of SHA2 it seems to be a better choice over SHA1.

Thats upto developers whether they want to proceed with SHA2 or not.

Reason - If devs decide to take the big step of dropping the PHP4 support completely, then its fairly possible .

[Arantor]

It seems you have read a lot of our posts in 3hr 20mins

Oh, I've read a great many posts as a lurker, in addition to the great many posts I made in my former life. Thing is, the people saying it change but the lines themselves are the same as ever.

Well I haven't got much of chance to play with SHA2, but seeing the algorithm and key size of SHA2 it seems to be a better choice over SHA1.

I certainly wouldn't be in a position to judge its algorithm, I'm not a cryptographic expert, neither a mathematician qualified to answer it, are you out of interest? The key size makes a difference, yes, and it won't even require a schema change.

Reason - If devs decide to take the big step of dropping the PHP4 support completely, then its fairly possible

Considering how there's already SHA1 emulation in the code for hosts that don't support it, I'd say it would be possible to implement SHA256 in the case of a host not doing so. However, it's not about dropping PHP4 support per se, more about having the right minimum requirements. 5.0 won't help you any more than 4.4.x would, but going for 5.1.2 would make a difference and 5.2.0 moreso.