7

I'm using the default identity stuff provided by ASP.NET 4.5 MVC and Entity Framework. I can create users with passwords and the hashed password shows up in the database. I'm trying to figure out if that hash is generated using the no-longer-trusted SHA1 algorithm or the SHA2 algorithm (be it SHA256, SHA512, etc).

Articles which seem to say it defaults to SHA256:

https://www.asp.net/whitepapers/aspnet4/breaking-changes#0.1__Toc256770148

http://kosmisch.net/Blog/DotNetEssential/Archive/2015/2/1/aspnet-membership-default-password-hash-algorithms-in-net-4x-and-previous-versions.html

Articles which seem to say it defaults to SHA1:

https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/consumer-apis/password-hashing

https://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

When I follow the chain down, I end up inside the PasswordHasher.cs class -> HashPassword() -> Crypto.HashPassword() which I can see is using Rfc2898DeriveBytes which then has a bunch of stuff about HMACSHA1.

So are my passwords getting hashed by SHA256 or SHA1? Easy way to default to SHA256?

If it helps, here is a dummy password taken from my local environment: AIPfkvy5v59jmVZdPpU9QfUMoToCQ+Rp3dBT7m9RwMKZai5/61REkN/0InCtxKPUOQ==

Scott Decker
  • 4,229
  • 7
  • 24
  • 39
  • 1
    [Comments](https://github.com/aspnet/Identity/blob/a8ba99bc5b11c5c48fc31b9b0532c0d6791efdc8/src/Microsoft.AspNetCore.Identity/PasswordHasher.cs) on the source code says SHA1 in version 2 and SHA256 in version 3 – Thangadurai Nov 16 '16 at 05:56
  • @Thangadurai and version 3 is only available in ASP.NET Core, not in ASP.NET 4.5 right? – Scott Decker Nov 16 '16 at 06:12
  • Looks like the default hash algorithm has been changed to SHA256 from .NET 4.0 onwards. I couldn't find any official docs which says about this change. – Thangadurai Nov 16 '16 at 06:30
  • @Thangadurai what are you basing that on? The articles I included? The code still looks like it's using SHA1 – Scott Decker Nov 16 '16 at 22:54

1 Answers1

3

So it looks like the answer is neither exactly:

From the comments in the ASP.Net Identity Source Code

Version 0: PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations.

See also: SDL crypto guidelines v5.1, Part III)

Format: { 0x00, salt, subkey }

Ultimately the hashing algorithim is SHA1, but it is not a simple SHA1 hash of the password, or even a SHA1 + salt hash.

It is worth pointing out that SHA1 is considered "broken" for digital signatures due to a mathematical attack, reducing the computational effort of generating a collision to just-about feasible levels.

This does not apply to hashed passwords.

Links for further reading.

Is SHA-1 secure for password storage?

https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

https://en.wikipedia.org/wiki/PBKDF2

https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Rfc2898DeriveBytes and HMACSHA1

ste-fu
  • 6,879
  • 3
  • 27
  • 46
  • If it's using SHA1 or using SHA1 a thousand times over with a salt, it's still using SHA1. I'm looking for a way to default it to use SHA256 without porting the entire application over to ASP.NET Core – Scott Decker Nov 16 '16 at 22:53
  • @scottndecker Why? – ste-fu Nov 17 '16 at 09:47
  • Because SHA1 is no longer considered secure and is expected to be widely vulnerable in the next year or two. – Scott Decker Nov 17 '16 at 15:25
  • @scottndecker Have you any resources links showing that it is broken for password hashing? – ste-fu Nov 17 '16 at 15:29
  • if MS is upgrading to use SHA256 in new version of password hashing algorithm (they are) and the general concensus is that the SHA1 algorithm is vulnerable to attack (it is), then it'd be much better to upgrade to SHA2 now rather than later – Scott Decker Nov 20 '16 at 03:34
  • SHA1 is vulnerable to **collision** attacks (ie signing certificates). 1000 iterations of salted HMACSHA1 is not "broken". There is no shortcut to brute forcing the passwords. Upgrading (as MS are) is not wrong, nor is using the best available in a new project. Migrating a project between frameworks solely because of SHA1 is not necessary. – ste-fu Nov 21 '16 at 09:37
  • good point and I appreciate you explaining that a bit more. I also came to the conclusion that it's basically "secure enough". Additionally, I think I may have a way around it entirely (3rd party Identity Provider) so I'm going to try out that path. – Scott Decker Nov 22 '16 at 17:37