1

Imagine situation:

  • Application might or might not be run via SSL/TLS
  • Application should not know password of the client because client might reuse passwords

Wouldn't then combined client-side and server-side password hashing work the best?

How would creating password work:

  1. User enters password into a field.
  2. Local side javascript hashes the password with salt being provided user name
  3. This hashed data is transmitted over network to the server.
  4. Server adds randomly generated salt to the hash and rehashes both into a new hash. This new hash and server-side random salt are stored

How would login work:

  1. User enters password into a field.
  2. Value of "login" field is taken as salt and local side javascript computes hash.
  3. This hash is transmitted over the network to the server
  4. Server takes the salt stored for that user, combines hash with salt and hashes it.
  5. Server compares new hash with stored hash, if matches, user successfully logged in. If they do not match, user is denied access.

What would be a disadvantage to this approach compared to standard approach with transmitting plaintext password over the internet and then hashing and storing it on the server?

Improve this question
3
  • Can you clarify Local side javascript hashes the password with salt being provided user name? I'm unsure what it means. Also, what is the login field? Do you mean username, password, or other?
    – Neil Smithline
    Jun 16, 2015 at 14:58
  • Well basically salt would be username.
    – Enerccio
    Jun 16, 2015 at 15:00
  • Predictable salts are subject to precomputation attacks. So, for common usernames, the client hashing will be providing little value over a clear-text password as the attacker could have generated rainbow tables. Forcing random usernames will reduce or eliminate this threat, but at great inconvenience to the user.
    – Neil Smithline
    Jun 16, 2015 at 15:05

3 Answers 3

Reset to default
2

In your scheme, you are substituting the password by it's hash. The hash becomes the password. An attacker who is able to sniff the hash can authenticate to your server with it without knowing the password. The attacker just has to craft a correct HTTP request and send it to your server, or edit the javascript of your login webpage in his own browser to reuse the hash he just sniffed.

In the end, hashing the password in the browser just increase the complexity of the authentication protocol without increasing the security in any way.

Improve this answer
3
  • But that would be the same if password was transmitted in plain. However, that way the password would be compromised, while now only hash would be compromised.
    – Enerccio
    Jun 16, 2015 at 16:25
  • And so what? The point is the attacker can authenticate as a legitimate existing user. This is what the authentication is meant to make impossible. (As a side note, the user is not supposed to reuse passwords; if a leak of one of his password compromises other accounts, this is the user's problem, not yours.)
    – Anonymous Coward
    Jun 16, 2015 at 16:31
  • 1
    And being that usernames can typically be chosen by users, there's a chance that they reuse the username and password across sites.
    – Neil Smithline
    Jun 16, 2015 at 17:48
1

There isn't so much a disadvantage of using javascript to hash the password, but there is little advantage. This does provide protection against a passive capture, but doesn't offer any more security over SSL.

Attacker has an Active MiTM or has control of server

In the case the attacker can Man in The Middle a connection between client and server, the attacker can substitute the javascript library with his own, thus defeating any protection.

Attacker obtains a passive capture

In the case the attacker obtains a passive capture of the traffic between the client and server. If the website isn't using SSL, then the website traffic is vulnerable to a MiTM, so while a passive capture can't be cracked the attacker would just position themselves in the middle. If the website is using SSL then the plaintext is already protected. Note, you could make an argument for protection against SSL where the website doesn't implement perfect forward secrecy and the SSL Certificate is stolen.

If you are interested in browser implementation of crypto, you should check out RFC 2617 which discusses how to implement password hashes in HTTP Authentication. Ideally, the browser would expose an interface to a crypto library, but there are some issues to consider. For example, in the scenario you outlined above, the lack of a nonce would make the user vulnerable to a replay attack.

Improve this answer
3
  • The problem I face is that application is done for client and then they will prepare runtime themselves, and unless they want to use SSL there is little we can do. Thus I am trying to make it as secure as possible without relying on the runtime environment.
    – Enerccio
    Jun 16, 2015 at 15:01
  • If I am reading this correctly, you are saying that you are essentially handing over the application (client and server code), but that you can't enforce the implementation of SSL. In that case, I would argue that implementing client side javascript to create a password hash isn't worth the effort, for the reasons outline above. It provides little security benefit but adds to the implementation complexity.
    – amccormack
    Jun 16, 2015 at 15:07
  • @Enerccio "as secure as possible" without SSL (TLS) is not secure. It is like saying I don't have a lock on my house door so I will use a piece of tape to be "as secure as possible" given that tape is more secure than nothing. Security is built on layers and one of those layers is that communication between client and server can be encrypted and authenticated. If it can't then you have no security and a bunch of complexity won't change that. Simple version is that without TLS an attacker simply feeds the client a compromised library which does not hash the password.
    – Gerald Davis
    Jun 16, 2015 at 18:18
0

What would be a disadvantage to this approach compared to standard approach with transmitting plaintext password over the internet and then hashing and storing it on the server?

  1. Users who use multiple computers, some with JavaScript turned on and some with JavaScript turned off, would be unable to authenticate from some of their computers and may not know why. I'll admit this is probably a very small group of people.

  2. If the transmitted hash is intercepted, it can be used by an attacker as the password with only some modification to the JavaScript (as stated by Anonymous Coward).

  3. If implemented naively, this would effectively make the username case sensitive, but that could be mitigated by having JavaScript convert the username to lower case before using it as a salt.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .