how to encrypt data in database and reuse it to authenticate users

Question

I'm developping an application with Spring MVC, and I want to add the security aspect to my authentication.

In my application I have the login and the password are registred in the database and any one who has access to it can see the login and the password clearly.

I want to have data encrypted in the database so that I will be sure that no one can use or divulgue them . I've searched in the net but I found that there are some algorithms which may encrypt data such as md5 ,but the problem it's irreversible.

Could some body help me ?

Answer 1

Why is it a problem that the encryption of passwords is irreversible?

When the user creates an account, salt and hash their password before saving. I prefer using bcrypt .

When the user logs in, you can use bcrypt's checkpw to compare the users credentials to the hashed ones saved in the db. Having them irreversible(undecryptable) ensures that if someone gains access to your db, they don't get all of your users passwords as well

I haven't used BCrypt with java before but I just glanced over this tutorial and it seemed like it may be a good starting place for you

Edit : Just realized he was using jBCrypt but the differences in the two should be very minimal

Edit2 : Here is a pretty good article on cracking passwords that are found in the database and a reason I recommend bcrypt and why you should use one-way encryption

Answer 2

I agree with Danny H, but wanted to address the other half of your question too: protecting the login (usually an email address). Most people ignore the need to protect it, but for website that want to maintain secrecy of their customers (not just Ashley Madison but also medical websites), then you'd want to add a layer of protection for the other data.

First, a reference on protecting the password: Secure Salted Password Hashing . Use either bcrypt, scrypt, PBKDF2, or argon2.

Now what about protecting the login? You can actually do a similar thing for protecting it, but you will need a fixed salt for it (for passwords, the salt must not be fixed!). Let's assume bcrypt is used for my example below.

Consider how the user would login: User enters his login id and password. System applies bcrypt to login id with fixed salt to look up user in database. From that, system gets the user's password salt, and system computes bcrypt on user provided password with salt to see if it matches hashed password in database. If so, user is granted access. Therefore, system granted access without storing the user's login id in plaintext form in the database.

What about user forgetting password? No problem if the login id is the email address: the user enters login (email address) on forgot password page, system applies bcrypt with fixed salt on user entered email address to see if the user exists in database, and assuming yes, then emails the user a secret link for password reset. Within the database, we have to associate that secret link to this user to make sure he only resets his own password (not somebody else's!).

What if the database is exposed? Anybody could determine if a specific user is in the database by computing bcrypt on that user's email address and looking for a match in the database, but nobody is going to be able to reverse the entire collection of email addresses, which is a big improvement over the present situation.

I discussed this idea in a blog of mine more than 2 months ago, see: https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/

Answer 3

MD5 is a hash function which is not reversible - it is not an encryption function. Hashes give the same output for a given input every time, that's why they work. Hashing would work in the scenario you described because the users who could see the hashes wouldn't know the original password - that said, it still sounds like a bad idea.

Ideally you would hash the passwords then encrypt the hash and other users wouldn't be able to see these values encrypted or not. That would be my suggestion, but if you choose only to encrypt the passwords RSA encryption would work just fine.