Dealing with User Credentials

Hashing the password at client side and store in server is straightforward, but what if the DB is compromised..

So then hash the hash from client again on the server using a salt and store the 2nd level hash in the DB…

Now when the legitimate user logs in, we’ll do get the 1st hash from client and 2nd from server and compare with the value in DB and if matches, then log the user and generate JWT for him…

So now if the DB is compromised, hacker won’t be able to impersonate the user and login as them, coz all he has is the 2nd level hash, while the Server needs 1st level hash…

For hashing, use a 1 way (algo which drops bits from the data before hashing, so that it can’t be recreated from the output)

http://stackoverflow.com/questions/1054022/best-way-to-store-password-in-database

Storing Secrets (Eg. Secret key for JWT)

ref: https://blog.fugue.co/2015-04-21-aws-kms-secrets.html

CreateKey will generate a key in the KMS service that will never leave the KMS service. Once you create a key in KMS, you can disable it, you can set permissions on who can use it, you can alias it, but you cannot export it. In order to use the keys for cryptography, you use the Encrypt and Decrypt API calls. This is the core security value proposition in KMS: no one can run off with the keys.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s