-2

I am developing an api project which will have users who will be registering and logging in and out of an mobile application. I will be devloping this application using web api .net core 5. I want to handle the authentication of users via logging in based on a valid jwt token.

My question is which type of hashing is suitable for storing the hashed password in the database. Here are 2 types i have been looking at, which one is more secure?

//sha256 method from the system web helpers namespace
var hash1 = Crypto.SHA256("password");

//hashpassword from the system web helpers namespace
var hash2 = Crypto.HashedPassword("12345");

Both are from micorosft/.net libaries so i am under the impression that they are both secure, however I have noticed there are some websites have a decryption mechanism for sha256. I am edging towards the hashedPassword method in the Cryto class...

user19329953
  • 73
  • 4
  • 5
    `some websites have a decryption mechanism` - no. because it's a _hash_, and hashes, by definition, can't be decrypted. you can only find collisions. which is why you should add _salt_ - if you insist on hashing your passwords yourself. maybe you should look into using a pre-made auth framework, like asp.net identity instead. no need to worry about details like that yourself – Franz Gleichmann Jul 05 '22 at 11:02
  • 4
    Neither, both lack sufficeint salting to protact the hash! – Jamiec Jul 05 '22 at 11:02
  • 3
    You shouldn't *only* hash passwords, you should also at least [salt the passwords](https://en.wikipedia.org/wiki/Salt_(cryptography)) (and don't reuse the same salt for multiple passwords!) – MindSwipe Jul 05 '22 at 11:03
  • 1
    Does this answer your question? [Rfc2898DeriveBytes vs Sha2 hash generation for passwords](https://stackoverflow.com/questions/13393698/rfc2898derivebytes-vs-sha2-hash-generation-for-passwords) – marsze Jul 05 '22 at 11:23
  • 1
    @MindSwipe The `Crypto` class already hashes the passwords internally: https://stackoverflow.com/a/17758221/2060966 – marsze Jul 05 '22 at 11:25
  • @jamiec - apparently the hashPassword function salts the password already - Crypto takes care of creating a salt for you. You don't need to create one. It is stored in the string returned by Crypto.HashPassword - https://stackoverflow.com/questions/17693918/system-web-helpers-crypto-wheres-the-salt – user19329953 Jul 05 '22 at 11:25

2 Answers2

2

SHA256 uses the SHA256 algorithm while HashPassword uses RFC 2898.

As for the differences, have a look at this post.

You should opt for HashPassword, as it automatically generates a salt for you. Also, the RFC 2898 is considered more secure, as it's intentionally slowed down, which makes it harder to brute-force.

Note: both are hashing algorithms, not encryption algorithms, so neither can be "decrypted" by definition.

marsze
  • 15,079
  • 5
  • 45
  • 61
  • 2
    No, do not use SHA256 for password hashing it's too quick. RFC2898 (or PBKDF2) is currently acceptable. Even better would be Argon2id – phuzi Jul 05 '22 at 13:13
  • yes i am opting to using RFC2898 due to the built in salting done for you. I could useSHA256 and provide a salting mechanism myself, but i rather opt for one that is done by default so RFC 2898 wins it for me. – user19329953 Jul 06 '22 at 13:52
0

I've seen bcrypt recommended a few times as a password hashing algorithm due to its ability to support a varying number of iterations within the algorithm to protect against today's ever more powerful CPUs/GPUs when trying to crack them.

George Stocker's very informative answer includes some good resources for reading up on this subject.

lee-m
  • 2,269
  • 17
  • 29