0

I'm reading a lot about security lately and something really bothers me. I'm using Node.JS and I wanna store user data in the database. I currently hash the password on the server and then I save it to DB. But when the user sends data to the server he sends just plain text. I think that is the wrong approach. I'm using Bcrypt btw.

The method that I wanna use is: when a user need's to sign in I hash the password on the client, and then I send a hashed password with a salt to the server. The server then hashes the password again and stores the result in DB alongside with the first salt, that the user has passed. That means I have serverHash(userHash(userPassword)) and userSalt.

When the user then does log in, I wanna fetch him a userSalt from DB and hash his userPassword using that salt. Then I send userHash(userPassword) to the server and then compare userHash(userPassword) and serverHash(userHash(userPassword)).

Is this method good and secure, or is there a better way to do this, can I maybe use some third-party library or I can get away with this approach?

EDIT: If someone bumps into this, don't do this, TLS will probably do the job, if not there are certificates that will help I think, I'm not 100% sure, but don't take my word for it but.

1 Answers1

0

Purpose of Database Hashing Password

hashing password in server solve worries about accidental access to database. where we consider server script are executing in a safe environment.

Authorized User can leak any data without protection

when a user login using username/password we will give him/her Authorization to Actions and view some Data .

if any crackers intrudes:

  1. our server script
  2. client browser or
  3. intermediate media (network interception)

our goal (protect authorization) will be ruined.

so hashing the password on client-side dosen't solve any issue, if a cracker can access to client-side area or intercept the traffic data.

for example : an authorized admin, with heavy password protection mechanism, can leak html data which tends to be admin-only viewable, if a cracker just intercepts network traffic.

Solution : Traffic Encryption

instead of sending hashed-password to server-side, The connection should get Encrypted like with SSL.

Todays Web Development

in Web Development its a good practice to to use HTTPS (Http+Ssl) when dealing with sensitive Data and Actions (scenarios which includes logins)

even in modern browsers, they show a Warning when dealing with html <input type='password'/> and not using Https.

Abilogos
  • 4,777
  • 2
  • 19
  • 39
  • 1
    Thank you for your answer, i realy appreciate it, but i was reading and looks like https in fact does help a lot, but even tho I'm using https, it doesn't mean that I have 100% secure connection. Thats what I wrote question in the first place. I mean from what I have read look like somebody could be listening to connection, and if somebody does, that means that I am giving him a plain user password. – Mihailo Petrovic Jan 12 '21 at 17:43
  • if someone listens on connection, just considers he wont able to see the plain password, but he will see sensitive data which authentication goal was going to protect them from this cracker. – Abilogos Jan 12 '21 at 17:46
  • even though, if cracker can access victims browser, he/she can access both password and sesitive-data. – Abilogos Jan 12 '21 at 17:47
  • 1
    i suggest to use a certificate within Https to prevent crackers from **man-in-the-middle attack** – Abilogos Jan 12 '21 at 17:48