CODEWITHSUNDEEP
c#databasehashpasswordssalt-cryptography
Oleg Yanytskii
Oleg Yanytskii

Reputation: 95

How can I check that password is correct if I add random salt?

I'm trying to secure my c# app. I know that we MUST store password hash and salt in DB. So my question: How I can compare that password is correct if I use Random salt? (Random salt gives random values each time). I also have the code below

 public static string HashPassword(string p, string s)
    {
        var combinedPassword = String.Concat(p, s);
        var sha256 = new SHA512Managed();
        var bytes = UTF8Encoding.UTF8.GetBytes(combinedPassword);
        var hash = sha256.ComputeHash(bytes);
        return Convert.ToBase64String(hash);
    }

    public static String GetRandomSalt()
    {
        var random = new RNGCryptoServiceProvider();
        var salt = new Byte[1024];
        random.GetBytes(salt);
        return Convert.ToBase64String(salt);
    }

I am open to other suggestions in general.

Upvotes: 2

Views: 898

Answers (2)

Adam G
Adam G

Reputation: 1323

I am open to other suggestions in general.

I will preface this post by making a broad point but I believe it is widely enough held to not constitute an "opinion".

If you are doing this "to secure your app", stop now. There are much better solutions like BCrypt, Scrypt and Argon which take care of all this for you and protect against threats that most people haven't even considered. These of course include salt(s) internally, so understanding what they are for and how they work is still a useful endeavour. For approximately the same amount of code, you will be handling the credentials a lot more securely than the posted code indicates. Google them for details.

If you are just doing this as "an exercise to understand how it all works", continue reading.

So what is salt exactly and why is it useful for protecting security?

Salt is additional entropy that is not part of the user's password, but is instead known to or invented by the server at the time the password is hashed and stored. The generated salt must be known to the server when validating your password. There are many ways it can be stored. It may be the first/last/middle/every8th/whatever n characters of the password hash stored in the database. It may have its own separate field. It may even be based on other facts immutable like Primary Keys of the user record itself.

The threat model that this protects against could be described like this. Consider a database that was compromised and now held by a malicious actor. The challenge is, given the malicious actor holds the credentials (in hashed form), can we stop them from guessing people's password (at least without trying some sort of dictionary or brute force guess attack.

If you thought hashing solved that problem, then I will give two possible scenarios:

1. Two users may use the same password

If the password is hashed but not salted, then two users who choose the same password will end up with the same hash. And even if the password isn't "terrible", the other user may reveal your password by whatever they entered as the "Password Hint". If the passwords were salted, then the fact that the password hint gave away the other user's password doesn't leak the fact that the same password would work on your account.

2. Rainbow tables

If you have enough time and compute power, you can generate (or download) a set of rainbow tables. These are basically key-value pairs, where the key is the hash and the value is the original password. These are generated in reverse. That is to say, take a string, hash it, add the hash as the key and the original string as the target. To lookup, you simply lookup the hash key and see what value comes back. Near instantly. With a long enough original string though, it won't have been pre-computed so it won't have a hit in the rainbow table. If I know the salt you are using and the hashing algorithm, I can still do my own dictionary attack or brute force attack, but suddenly I am required to try each guess in turn until I am lucky, so if your password is good, I will not find it in "reasonable time".

The precise answer to your posed question

How I can compare that password is correct if I use Random salt?

Your verification process needs to know or derive exactly what exact salt value was chosen for the hash process. The salt may be randomly generated, but if so it needs to record the exact value used.

Upvotes: 3

Hiển Lếch
Hiển Lếch

Reputation: 11

First , you have to get salt in database by username , then hash it with posted password , finally compare it to password stored in database

Upvotes: 1

Related Questions