Skip to content
This repository has been archived by the owner on Sep 8, 2021. It is now read-only.

Unsafe password post #113

Open
Bobwu1 opened this issue Jul 18, 2018 · 2 comments
Open

Unsafe password post #113

Bobwu1 opened this issue Jul 18, 2018 · 2 comments

Comments

@Bobwu1
Copy link

Bobwu1 commented Jul 18, 2018

I noticed that the password is send as plain text through: (username, email, password) => requests.post('/users', { user: { username, email, password } }),

From my basic security understanding, isn't this very unsafe? As a realworld example, shouldn't the password be hashed using SHA512 or something before being sent over the network?

The backend is then supposed to add salt/pepper (and hash it once more if necessary) before storing it in the database right?

Is my understanding of web security best practices correct?

@ghost
Copy link

ghost commented Aug 1, 2018

https can solve this problem

@glebec
Copy link

glebec commented Feb 4, 2019

@Bobwu1 if you are not using HTTPS, then it (almost*) doesn't matter if you hash in the client or not, as all the backend knows is whatever string is being posted – which an attacker can intercept. Basically, HTTP isn't acceptable as a transport for any kind of sign-in credential.

If you are using HTTPS, then there does not seem to be a lot of point to hashing in the frontend, because you should hash (& salt) in the backend anyway. That's because it's not advisable to store credentials as received from clients directly in the db – you cannot necessarily guarantee that all clients will actually hash the password before sending it.

There is potentially an argument for "double" hashing (client and server side) even over HTTPS. Specifically, if the client hashes before sending, then if the sent hashed password ends up in some server log somewhere (a common breach!), attackers could still use it to sign in to your server… however, if the user had reused a password from another site, attackers wouldn't be able to use the logged hash to sign into other sites. Oof! So in other words, hashing at both ends makes it just that much less likely that a security mistake has actual consequences.

At the end of the day though, the golden rules here are:

  • Use HTTPS
  • Hash & salt on the server (at minimum)

*Note, I have seen some clever back-and-forth schemes that involve server and client sending each other random bits and both hashing in such a way that in theory you can send passwords over HTTP, but since the page content itself could be modified in a man-in-the-middle attack, it's sort of a moot point. Use HTTPS!

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

No branches or pull requests

2 participants