search

gothinkster / react-redux-realworld-example-app

Exemplary real world application built with React + Redux
https://react-redux.realworld.io
MIT License
5.55k stars 2.5k forks source link

Unsafe password post #113

Open Bobwu1 opened 5 years ago

Bobwu1 commented 5 years ago

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 commented 5 years ago

https can solve this problem

glebec commented 5 years ago

@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:

*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!