Skip to main content
Software Engineering

Return to Question

Make the problem and proposed solution clearer
Source Link
Seth Falco
Seth Falco
  • 141
  • 5

Suppose one wishesplans to implement an account systemauthentication for their service/websiteweb app.

  There have been cases, like with Instagram for example, where passwords were accidentally stored in plain text due to accidentally logging themlogs.

While Iwe'd hope never to never make thethis mistake, iswe're thinking it viablemight be best to do an unsalted SHA512 hash on the front endclient-side, and senduse that as the effective password to hash again with bcrypt on the back end insteadserver-side? Should the same or

This way, if a similar mistake everwere to be made, at the very least it's not a plain-text password as the realuser's original plain text password waswould never even sentleave their machine. As a result, it can't be stored in the first placeour systems.

This assumes that on server-side, but the back end willwe still use bcrypt to salt, and hash the password, and store the effective password securely?.

While I understand an unsalted hash isn't particular strong, ifThe motivation is that in the scenario ofthat a mis-configuration which does somehow log or by any other means store the unhashed passwordmisconfiguration occurs, at least aan unsalted SHA512 hashed passwordstring is stored rather than ainstead of the user's original plain-text text password?

For example:

  1. User inputs password on front end.
  2. SHA512
  3. Send to Server-Side
  4. bcrypt
  5. Store result in database

(Assume HTTPS. This is configured for web serverstill bad, and SSL is configured on MySQL.)but in theory, less so?

Is this a viable setup, or done by anyone? Is there anything wrong withand are the justificationexamples of services doing this?

Suppose one wishes to implement an account system for their service/website.

  There have been cases with Instagram for example where passwords were accidentally stored in plain text due to accidentally logging them.

While I hope never to make the mistake, is it viable to do an unsalted hash on the front end and send that to the back end instead? Should the same or similar mistake ever be made, at the very least it's not a plain-text password as the real password was never even sent in the first place, but the back end will still use bcrypt to salt, hash, and store the password securely?

While I understand an unsalted hash isn't particular strong, if in the scenario of a mis-configuration which does somehow log or by any other means store the unhashed password, at least a SHA512 hashed password is stored rather than a plain-text password?

For example:

  1. User inputs password on front end.
  2. SHA512
  3. Send to Server-Side
  4. bcrypt
  5. Store result in database

(Assume HTTPS is configured for web server, and SSL is configured on MySQL.)

Is this a viable setup, or done by anyone? Is there anything wrong with the justification?

Suppose one plans to implement authentication for their web app. There have been cases, like with Instagram, where passwords were accidentally stored in plain text due to logs.

While we'd hope to never make this mistake, we're thinking it might be best to do an unsalted SHA512 hash on the client-side, and use that as the effective password to hash again with bcrypt on the server-side?

This way, if a similar mistake were to be made, at the very least the user's original plain text password would never leave their machine. As a result, it can't be stored in our systems.

This assumes that on server-side, we still use bcrypt to salt and hash the password, and store the effective password securely.

The motivation is that in the scenario that a misconfiguration occurs, an unsalted SHA512 string is stored instead of the user's original plain text password. This is still bad, but in theory, less so?

Is this a viable setup, and are the examples of services doing this?

Source Link
Seth Falco
Seth Falco
  • 141
  • 5

Client Side Hashing + Server Side Hashing

Suppose one wishes to implement an account system for their service/website.

There have been cases with Instagram for example where passwords were accidentally stored in plain text due to accidentally logging them.

While I hope never to make the mistake, is it viable to do an unsalted hash on the front end and send that to the back end instead? Should the same or similar mistake ever be made, at the very least it's not a plain-text password as the real password was never even sent in the first place, but the back end will still use bcrypt to salt, hash, and store the password securely?

While I understand an unsalted hash isn't particular strong, if in the scenario of a mis-configuration which does somehow log or by any other means store the unhashed password, at least a SHA512 hashed password is stored rather than a plain-text password?

For example:

  1. User inputs password on front end.
  2. SHA512
  3. Send to Server-Side
  4. bcrypt
  5. Store result in database

(Assume HTTPS is configured for web server, and SSL is configured on MySQL.)

Is this a viable setup, or done by anyone? Is there anything wrong with the justification?