Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A question about a better place for storing the salt? #1

Open
adzhazhev opened this issue Oct 13, 2019 · 0 comments
Open

A question about a better place for storing the salt? #1

adzhazhev opened this issue Oct 13, 2019 · 0 comments

Comments

@adzhazhev
Copy link

Hi, I've been reading your blogs about asp API + SPA client for quite sometime since I needed a simple solution for having local accounts with a combination of an api. I don't want to use IdentityServer, no matter whether it is AzureADB2C, self hosted identity server that comes along with asp core or something like Auth. So I was just going through your git repos and I saw you updated thing for 2.2 and 3.0 and I started looking at the code(might be a work in progess, since you don't yet have a post about this one) and I couldn't figure something out. I'm a bit inexperienced in the field of Cryptography but I have a 5 years of experience as a web dev with asp(before core).

  1. I saw that you definitely need some kind of a app secret for signing the JWT token.
  2. I see that when it comes to generating the password hash as a salt you are using a randomly generated key by hmac (which later you need for a password verification).

using (var hmac = new System.Security.Cryptography.HMACSHA512())
{
passwordSalt = hmac.Key;
passwordHash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(password));
}

Okay so the ideas are:

  1. Don't keep plain text pass
  2. You also need the salt to verify the pass hash. Every user has unique password salt generated on his registration.
  3. Now here's where I am having a big question mark over my head. Isn't it better to generate a new secret to use as salt for all users and keeping it away at AzureKeyVault for example(as I am doing now with my secrets). So in case you have a db breach of some kind and your data is exposed in the current scenario if they know which hashing algorithm you are using + the salt saved in the db and there you have the users passwords as plain text. As opposed to my idea where you need to get the secret also, which is much harder this way.

I totally might be missing something fundamental or you might still be working on this of course, I would just like to understand what I am doing exactly since it's my first time doing a new project literally from scratch and I don't want to do stupid mistakes that might become a big pain in the ass for everyone :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant