Both providers derive from the standard asp.net membership providers, so msdn would be best place to find info about hashing and salting.. here's an excerpt from the msdn docs:
The PasswordFormat property indicates the format that passwords are stored in. Passwords can be stored in Clear, Encrypted, andHashed password formats. Clear passwords are stored in plain text, which improves the performance of password storage and retrieval but is less secure, as passwords are easily read if your data source is compromised. Encrypted passwords are encrypted when stored and can be decrypted for password comparison or password retrieval. This requires additional processing for password storage and retrieval, but is more secure, as passwords are not easily determined if the data source is compromised. Hashed passwords are hashed using a one-way hash algorithm and a randomly generated salt value when stored in the database. When a password is validated, it is hashed with the salt value in the database for verification. Hashed passwords cannot be retrieved.
@Dirk The snippet says setting the password to 'hashed' will use a salt, but looking in the DB there is no salt field (I guess the salt could be concatenated with the hash and stored in the password field) however this does not appear to be the case, if I enter 2 users with the same password, then the value in the password field is identical for each (this is what salting is designed to avoid)
So... should we add this to codeplex as a feature we wish to add to the core umbraco providers?
As of 4.7.1 the default membership provider does NOT use a salt value. This is a HUGE security hole. Even though passwords are stroed as one way hashed values in the database they can easily be cracked using lookup tables and rainbow tables.
If you are using any version of Umbraco and haven't made the necessary changes to include a salt you are at high risk of comprimising every user registered on your site RIGHT NOW..
Adding this to the growing list of changes necessary before I launch my own site. If successful I'll post a new "umbraco project" with a revised membership provider and the steps to update a 4.7.1 installation to utizilize it.
I concur that this should be a top priority for Umbraco given the current environment and myriad of cases lately where databases have been compromised and passwords easily cracked using rainbow tables.
There's an excellent article here about cryptographic storage on Troy Hunt's blog (add the blog to your RSS reader, it's invaluable) that's targeted towards .NET developers.
@Joey Hi, did you ever build anything worth sharing regarding salting passwords? we've got a project now which it appears will require salting passwords.
Another bump for this thread - we will need to use some form of membership provider with Umbraco in the near future, but this security issue with the default provider is still a bit of a concern to us...
In the old API - pre 7.1 I belive there was a salt applied (from reading the source) but the salt was the last half of the password - not idea in my opinion.
This means that if you have two matching passwords the hash in the db will be the same, the password hash stored in the db is actuly made of two parts 1st is the hashed password, 2nd is the salt created form the hashed value from the 2nd half of the password (this is from memory so order could be wrong but you get the idea).
Now in 7.1 a new API has been introduced and I am still going through this so can't say how the hash and salting is being preformed.
I've just tested in 7.1.1 in both Members and Users and identical passwords still create identical hashes - at least in the same installation of Umbraco.
Hash and Salt
Hi all
I'm trying to find documentation on securing logins.
I've found you can set passwordFormat="hashed" in the UmbracoMembershipProvider and in the UsersMembershipProvider in the web.config
However, is there a way to 'salt' the passwords? they do not appear to be salted in the database.
Also which algorithm is used to hash passwords?
Murray,
Both providers derive from the standard asp.net membership providers, so msdn would be best place to find info about hashing and salting.. here's an excerpt from the msdn docs:
The PasswordFormat property indicates the format that passwords are stored in. Passwords can be stored in Clear, Encrypted, andHashed password formats. Clear passwords are stored in plain text, which improves the performance of password storage and retrieval but is less secure, as passwords are easily read if your data source is compromised. Encrypted passwords are encrypted when stored and can be decrypted for password comparison or password retrieval. This requires additional processing for password storage and retrieval, but is more secure, as passwords are not easily determined if the data source is compromised. Hashed passwords are hashed using a one-way hash algorithm and a randomly generated salt value when stored in the database. When a password is validated, it is hashed with the salt value in the database for verification. Hashed passwords cannot be retrieved.
Hope this helps.
Regards,
/Dirk
@Dirk The snippet says setting the password to 'hashed' will use a salt, but looking in the DB there is no salt field (I guess the salt could be concatenated with the hash and stored in the password field) however this does not appear to be the case, if I enter 2 users with the same password, then the value in the password field is identical for each (this is what salting is designed to avoid)
So... should we add this to codeplex as a feature we wish to add to the core umbraco providers?
@murray Maybe the salt is random per application, and not per user?
@Morten, Perhaps. 'per user' sound more secure to me, but that's only my guess?
I definitly think that the passwords should be salted per user out of the box.
Any updates on this? Is there any way to go from having an existing "clear" provider and converting it into an encrypted and salted one?
As of 4.7.1 the default membership provider does NOT use a salt value. This is a HUGE security hole. Even though passwords are stroed as one way hashed values in the database they can easily be cracked using lookup tables and rainbow tables.
If you are using any version of Umbraco and haven't made the necessary changes to include a salt you are at high risk of comprimising every user registered on your site RIGHT NOW..
Adding this to the growing list of changes necessary before I launch my own site. If successful I'll post a new "umbraco project" with a revised membership provider and the steps to update a 4.7.1 installation to utizilize it.
I concur that this should be a top priority for Umbraco given the current environment and myriad of cases lately where databases have been compromised and passwords easily cracked using rainbow tables.
There's an excellent article here about cryptographic storage on Troy Hunt's blog (add the blog to your RSS reader, it's invaluable) that's targeted towards .NET developers.
@Joey Hi, did you ever build anything worth sharing regarding salting passwords? we've got a project now which it appears will require salting passwords.
Any update regarding salting passwords?
Has this been solved in Umbraco 6.0.5?
Just bumping this thread as we are also concerned about the security implications with the default membership provider not salting passwords...
I know there are changes planned to the v6.2.0 member API (http://our.umbraco.org/contribute/roadmap), but I can't seem to find any further details.
Another bump for this thread - we will need to use some form of membership provider with Umbraco in the near future, but this security issue with the default provider is still a bit of a concern to us...
I've just created 2 users with the same password in Umbraco 7 and the Hash is the same. So there is still no salting?
Thanks
Dan
Hi Dan,
In the old API - pre 7.1 I belive there was a salt applied (from reading the source) but the salt was the last half of the password - not idea in my opinion.
This means that if you have two matching passwords the hash in the db will be the same, the password hash stored in the db is actuly made of two parts 1st is the hashed password, 2nd is the salt created form the hashed value from the 2nd half of the password (this is from memory so order could be wrong but you get the idea).
Now in 7.1 a new API has been introduced and I am still going through this so can't say how the hash and salting is being preformed.
I've just tested in 7.1.1 in both Members and Users and identical passwords still create identical hashes - at least in the same installation of Umbraco.
This is actually easy to fix. Just set "useLegacyEncoding" to "False" on the membership providers within the Web.config.
http://blog.reneorban.com/2014/10/hash-and-salt-umbraco-passwords.html
is working on a reply...