0

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 ?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
pietà
  • 760
  • 1
  • 11
  • 37

3 Answers3

2

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

Danny H
  • 366
  • 2
  • 7
  • Hashes aren't encryption. – j-u-s-t-i-n Dec 02 '15 at 20:59
  • Yes you are correct and probably should have worded my answer differently and will edit my answer accordingly. In the use case he was asking about, just hashing the passwords and saving them should be fine. after reading your answer, I'm curious why you think it would be necessary to encrypt an already hashed password – Danny H Dec 02 '15 at 21:16
  • I'd also like to add, I'm sure there are times where it might be necessary to encrypt a hashed password. I just feel like it may be an extra level of complexity with no substantial benefit 90% of the time. I'm not really arguing with you, just honestly curious and wanting to be as proficient as I can be – Danny H Dec 02 '15 at 21:22
  • Encrypting the hashes adds an extra layer of protection. If I have all of the hashes in your db I could easily write a script to run through a pw dictionary hash each pw and compare the output to the db. Now I know the original password for each matching hash. – j-u-s-t-i-n Dec 03 '15 at 13:51
  • You can say "easily" if you want, but a hashed password with random salt is extremely time and resource consuming. Not saying encryption on top of the hash isn't useful, just that its not worth the extra layer of complexity/overhead in 90% of applications. – Danny H Dec 03 '15 at 14:40
  • You didn't suggest a random salt. Plus these random salts also need to be stored somewhere associated with where it was randomly used or how can you compute the same hash twice. Does it not? – j-u-s-t-i-n Dec 03 '15 at 15:44
  • My second sentence "**When the user creates and account, salt and hash their password before saving**". As far as storage goes, bcrypt builds their salts into the hash ( [A Thread on how that works](http://stackoverflow.com/questions/6832445/how-can-bcrypt-have-built-in-salts) ). All we are talking about are login credentials. Just as @TheGreatContini mentions in his blog, its more likely that the attackers are going to be interested in your other data anyway – Danny H Dec 03 '15 at 17:39
  • Apologies, I somehow missed the salting part... should have made it bold in answer ;) – j-u-s-t-i-n Dec 03 '15 at 17:53
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/

TheGreatContini
  • 6,429
  • 2
  • 27
  • 37
0

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.

j-u-s-t-i-n
  • 1,402
  • 1
  • 10
  • 16