0

I have a registration form contains username and password. Then i have to submit it from client to server side (jquery ajax to php). My question is, should i hash it from the client (salt + password) before sending it to server? Then store the hashed password and salt to the database? Because I'm worried. I know that user can see the request in network.

I just want to know other's idea and better explanation in this kind of situation.

EzLo
  • 13,780
  • 10
  • 33
  • 38
Lurcan
  • 3
  • 1
  • 5
  • 4
    encrypt with TLS/SSL – 1565986223 Apr 14 '19 at 12:59
  • ok. if i use HTTPS/SSL is it necessary to hash password at client? or should it be done at server? – Lurcan Apr 14 '19 at 13:13
  • No. You should probably read more about the encryption. Using TLS/SSL, whatever is transmitted from client is encrypted and then decrypted on server side. If any attacker intercepts the transfer, they get the encrypted data. – 1565986223 Apr 14 '19 at 13:15
  • so that means, assuming that i'm using TLS/SSL, then is it ok to send password plain text from client (ajax jquery) to server (php)? – Lurcan Apr 14 '19 at 13:20
  • Yes. It is not `plain text` however. Everything the client sends is encrypted. read https://stackoverflow.com/questions/470523/how-does-ssl-really-work – 1565986223 Apr 14 '19 at 13:21
  • Yes. That is correct – 1565986223 Apr 14 '19 at 13:29
  • @naga-elixir-jar Sorry if I misunderstand you, but SSL or not, you must hash your passwords. Because you should not store passwords as plain-text in your database. – unlut Apr 14 '19 at 17:30
  • 1
    @unlut hashing on server side, not client side. read OP's question – 1565986223 Apr 14 '19 at 17:46
  • @naga-elixir-jar I see your point, but isn't main goal hide user data from everyone else? By storing user's password in plain text in the server side (not in database, I am talking about memory) you are exposing user password to everyone who has access to server side. Are malicious admins, attackers who has gained access to server and probability that people use same password at different places not a concern? – unlut Apr 14 '19 at 18:15
  • @unlut well then the business have got more serious issues to address – 1565986223 Apr 15 '19 at 05:57
  • Yes, im gonna store password as hashed in the database. But what i want to clarify is, if where should be safe to hash the password, in client or server – Lurcan Apr 15 '19 at 06:43
  • The complete book of password auth: **At signup**: 1. input text at clientside. 2. send plaintext password through HTTPS (or WSS) to server. 3. server receives plaintext password. 4. hash the password. 5. store hashed password (and possibly salt). **At login**: 1. input text at clientside. 2. send plaintext password through HTTPS (or WSS) to server. 3. server receives plaintext password. 4. server retrieves hashed password (and salt). 5. server hashes the sent password (using salt). 6. server compares stored hash and new hash, authenticate if equal, refuse if not. – Amadan Apr 15 '19 at 07:55
  • (Some algorithms will automatically deal with salt for you, e.g. bcrypt; so the last couple of steps are merged/simplified.) – Amadan Apr 15 '19 at 07:56
  • @unlut The idea of performing the hash before storing it in the DB is to secure the DB in case it gets stolen. If the adversary can read out application RAM then that's a different attack factor. That would be harder to protect against. Still, it is something to keep in mind, it is definitely possible to deep-freeze DRAM and put the DRAM modules in another computer *including* the information that is kept in there (!). – Maarten Bodewes Apr 16 '19 at 10:58

0 Answers0