9

In the login service, a user is posting a json as payload to a Spring RESTful login service like below:

{
 "username": "john",
 "password": "doe"
}

Once the Spring RESTful service receives the call, it compares the password with the one store in the database in plain text.

I see two problems in the current implementation.

  1. The password is sent through HTTP as a POST payload in plain text.
  2. The correct password stored in the database is in plain text.

For issue 2, I decided to use bcrypt to encrypt the password stored in the database as mentioned in this post. Is this a good way?

For issue 1, I don't know if there is a best practice for it. Can some one share your insigts? Thanks!

Edit:

Sorry that I forgot to mention that the client and server talks through HTTPS. And the password is sent in POST payload.

In this case, the solution to issue 2 (store bcrypted correct password) in the database is okay, right?

What about in issue 1, in this case, the password can be sent in the post payload in plain text?

Community
  • 1
  • 1
blue123
  • 2,937
  • 7
  • 27
  • 29

3 Answers3

9
  1. Use HTTPS.
  2. Password should be in request body, so use POST.
  3. Don't hash the password before sending.
  4. Compare hash stored in the db with hashed received password.

There is no reason to encrypt passwords. It's a bad idea. They should be hashed and preferably salted. In case someone stoles your database, it'll be harder to compromise your users' passwords.

How to securily store passwords.

Community
  • 1
  • 1
xenteros
  • 15,586
  • 12
  • 56
  • 91
  • Hi @xenteros, I can meet 1 and 2 as you mentioned. But in the post payload, the password is in plain text? Thanks! – blue123 Dec 14 '16 at 08:32
  • @blue123 if you use HTTPS, the payload and everything else is encrypted with SSL / TLS / whatever before it leaves the browser. – walen Dec 14 '16 at 09:41
  • @xenteros "There is no reason to encrypt passwords. It's a bad idea." I'm not sure if I agree? Suppose I step up to a PC of someone whose password I want to steal, and convince them to let me use the PC ("I want to show you something"). Then I open a tab and without them noticing open developer tools, ask them to sign on to an application that sends plain text passwords. Then, when the user isn't looking ("Hey, can you look up the weather forecast on your phone?"), I can look in the developer tools and see their password. There are probably other scenarios. – Software Prophets Jun 20 '18 at 21:01
  • @OutfastSource once you get physical access to someone's device you can do whatever you want despite the fact whether he uses password encryption or not. – xenteros Jun 20 '18 at 22:29
  • @xenteros So we should just give up if someone gets access? The idea behind security is that we make it so difficult that there are no practical schemes to circumvent. Add a nonce (one time unique string stored on the server), send that nonce with a login request, encrypt that nonce using the password, decrypt on the server side using the user's password and compare it to the nonce (lots of details left out). You never send the password and the nonce is destroyed after the one use. Even if I have information from physical access, it does me no good. Encrypting the PW gets closer, nonce best. – Software Prophets Jun 21 '18 at 11:48
0

As I understood, you want to hide/secure even when saving password. So that nobody can see password from request body. Password should be hashed when saving in database. Even anyone steel your db he won't be able to compare passwords because he will get hashed password. Usually, we send request body in logs from where we can take body in case of any error occurs for testing. You can stop request body to send in logs file only when you are saving password only. In this way, only user will know the password. None of the developer can get password. But this can be a problem when user will get unknown error that you will have take care separately.

Abhishek
  • 648
  • 7
  • 8
-1

I am not shure to understand your requirement. If you want the good practice, so xenteros is right :

  1. Use HTTPS.
  2. Password should be in request body, so use POST.
  3. Don't hash the password before sending.
  4. Compare hash stored in the db with hashed received password.

There is no reason to encrypt passwords. It's a bad idea. They should be hashed and preferably salted. In case someone stoles your database, it'll be harder to compromise your users' passwords.

If you absolutly want to use HTTP and not HTTPS you can hash your password with javascript. Don't use encryption with javascript. Someone can reuse it to decrypt the password. And in general don't use encryption to store password for security reasons.

fastest MD5 Implementation in JavaScript

you should trully prefer the solution of xenteros

Community
  • 1
  • 1
DamienB
  • 419
  • 1
  • 6
  • 20
  • instead of authentication via HTTP, he can just skip authentication. – xenteros Dec 14 '16 at 08:26
  • Sorry that I forgot to mention that the client and server talks through HTTPS. And the password is sent in POST payload. In this case, the solution to issue 2 (store bcrypted correct password) in the database is okay, right? What about in issue 1, in this case, the password can be sent in the post payload in plain text? – blue123 Dec 14 '16 at 08:39
  • Do not hash your password with JavaScript! A simple MITM attack can modify inject your hash code and recover the plain text and it is already deployed country-wide in some parts of the world. – Star Brilliant Jun 07 '18 at 03:15