27

For instance, lets look at a common login system for a website

  1. HTTPS connection is made
  2. User submits credentials via POST
  3. Server-side code hashes the password and looks if it matches the user name
  4. Session is initialized, and a key may be issued to log in again without passwords ("remember me")

This is generally the status quo right now, where passwords are all computed on the server. But, if we do the following client-side it's considered a bad practice:

  1. HTTPS connection is made
  2. JavaScript calculates the hash (may request specific user salt)
  3. Script sends AJAX with the user/hash values
  4. Server-side code looks if the password's hash and user name match.
  5. Session is initialized, and a key may be issued to log in again without passwords ("remember me")

Can someone explain why this other method is considered bad practice to do it CS instead of SS? Both transmit over SSL, both create the secure hash, and both authenticate should be be considered reliable with well-written code. Both are susceptible to XSS and other bad design.

AviD
  • 72,138
  • 22
  • 136
  • 218
Incognito
  • 5,204
  • 5
  • 27
  • 31
  • 5
    This may help http://stackoverflow.com/questions/1380168/does-it-make-security-sense-to-hash-password-on-client-end – zedman9991 May 18 '11 at 14:20
  • 2
    I always assumed that at least part of the reason was accessibly. Your second example relies on javascript, and would not work for clients without js support. However, i'm interested to see why this would be a bad idea from a *security* standpoint. Over HTTP at least, I would assume this would at least somewhat increase the "security", since compromising the session does not immediately yield the user's password (which they likely use for other sites). – crazy2be May 18 '11 at 22:05
  • I'll let the answers address the general question, but to make your two proposals even remotely similar (i.e. someone at the server doesn't get to see the client's authentication token), then Server side step 3 needs to ALSO be client side step 4. Further, "hashes" is incorrect at step SS3, the new CS4, and very likely at CS2 as well; applies a standard password hashing function is what is required - BCrypt, SCrypt, or PBKDF2 with as large a work factor/iteration count as possible under peak load. Additionally, the salt in all cases must be random and long (8-16 bytes). – Anti-weakpasswords Mar 27 '14 at 02:03
  • This would have the same effect as storing passwords in plaintext. – Cano64 Jun 23 '19 at 01:11

9 Answers9

38

What you've described isn't improving the security of the system. Its not a matter of opinion or emotion, security just doesn't work that way. In your example the hash(salt+password) is now your password. If it wasn't over https, then an attacker could just replay that value. Also you didn't really address owasp a9 aka "firesheep" style attacks.

rook
  • 46,916
  • 10
  • 92
  • 181
  • 3
    OTOH, if you hashed (salt+password+nonce), then it becomes a *one time* password (no replay); that, however, is kind of pointless over HTTPS (not to mention that the browser already implements that as HTTP Digest Auth). – Piskvor left the building May 18 '11 at 19:42
  • 1
    @Piskvor actually the SMB protocol did something very similar. A CVE was issued because the nonce would repeat after a couple thousand tries. If you sniffed the wire looking for the Nonce, then you can keep trying to replay the login until the server reuses the nonce. – rook May 18 '11 at 19:55
  • 5
    well, if you reuse it, then it's hardly a *nonce* anymore, is it? ;o) Just goes to show that Security Is Hard. – Piskvor left the building May 18 '11 at 20:13
  • +1 for good answer and showing me owasp. Could be useful for explaining threats to less technical people. – Stephen Paulger May 20 '11 at 09:48
  • @rook, I see alot of your answers, and I'm wondering What's your age? – Pacerier Mar 29 '15 at 07:22
  • @Pacerier I'm in my twenties, and I first started releasing exploits when was in my teens. – rook Mar 29 '15 at 19:44
  • @rook, Ic, do you study compsci? – Pacerier Apr 05 '15 at 17:28
  • @Pacerier In my mind, hacker is just a title earned by a highly skilled engineer. No programmer wants to write insecure code, and in order to be a successful penetration tester you have to understand how the application works better than the engineers who wrote it. Studying compsci and understand the theories behind application design is just the first step. – rook Apr 05 '15 at 18:40
  • @rook, Ic, so you study penetration testing. – Pacerier Apr 06 '15 at 01:56
  • 1
    @Pacerier I am a penetration tester, I study how software is built and how it fails. – rook Apr 06 '15 at 23:36
16

It has to do with the general scope of what you are trying to protect. If you are developing a server-side application, you are trying to protect the server from both the user and his client system. Having the user's system (ie, the client) do your security work for you doesn't really help the server stay protected. There's usually an assumption that when the client is doing something, even it if it working at the behest of the server (in terms of JavaScript delivered by the server) that the client is innately untrusted, because a hacker can take control of the client side app and submit input separate from the JavaScript.

A server hashes password to inhibit issues resulting from the disclosure of the password store. If an attacker gets a hold of the password hashes, it should be impossible to make use of them by sending the passwords from a hacked client machine - because the server is doing its own hash. If the server delegates this work to the client, then the server is also delegating a security function.

This all depends on how you define your boundary of protection. If you have reason to believe that there is absolutely no threat from the client machine and that not client system could ever be hacked, then this issue goes away... but I don't know of any web system that can assuredly make this claim.

bethlakshmi
  • 11,606
  • 1
  • 27
  • 58
  • 1
    You could have two layers of hashing to mitigate against the problem you describe in the 2nd paragraph, as HTTP Digest does (with a nonce on the 2nd hash). The first HA1 is stored on the server and the client knows how to compute it (when the user enters the password), and the client is also able to compute HA2. Hashing on the client side isn't really an issue (of course, the server has to verify what the client sends against the hash it computes itself). – Bruno May 18 '11 at 16:38
  • I'd also say that a server hashes passwords firstly to protect the user's passwords (and only as a consequence, protect itself, because good client protection benefits the whole system). If a password stored has been leaked, it's usually a sign of a problem on the server first. Computing the hash to verify on the client or on the server doesn't really make a difference here (provided the server verifies the result against what it trusts: its own hashed password store, of course). – Bruno May 18 '11 at 17:00
  • 1
    @Bruno - First comment - I'm afraid I don't get what you're driving at here... there's a whole lot of hashing in what you propose and I don't see the value of it - if the server has to recompute what the client does based non a pre-hashed piece of data, why have the client make the hash at all?; second comment - I agree, but I'd skipped this since the point of the question seemed to be - why not delegate things like hashing to the client. – bethlakshmi May 19 '11 at 14:00
14

The core reason is not hate... it's insecurity. A general principle is to trust nothing you don't have control of. In the case of a user authenticating to an application, unless you provided the laptop to the user, configured its controls, and those of the environment it sits in, you can't trust it.

The traditional way to look at it is that if an attacker has physical access to a computer they can do whatever they like.

With a simple browser that just sets up an encrypted link there is very little that can be compromised, with a thicker client any functionality client side could be compromised.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
10

If you're calculating the hash on the client side, you add the risk that an attacker only needs a hash of a user's password to log in instead of the actual password. You could probably get around that by sending a nonce to hash the password with (basically a per-session salt), but then you'd still have to hash that on the server side too, so why bother doing it on the client at all?

Brendan Long
  • 2,878
  • 1
  • 19
  • 27
8

I'm not sure if people "hate" the mechanisms you describe on the client side.

I think this has more to do with legacy practices and uneven support on the client.

Firstly, you need JavaScript for implementing this, if you want to do it via form-based authentication. HTTP Digest provides something similar natively, and is supported by most browsers (including those without JavaScript support), but it doesn't "look good" and cannot be integrated very well with the general branding of the website. To be fair, having some identifiable branding where you're going to enter your password can be a good thing from a security point of view too. In addition, one of the major shortcomings of HTTP Digest implementations in browsers is that the popup boxes don't look much different from those that use HTTP Basic, which doesn't offer any protection.

Secondly, as far as I'm aware, JavaScript cryptographic functions support vary from one browser to another. While it can sometimes be tolerable to have inadequate support for certain features across browsers, being able to log in is quite fundamental and that's something you never want to be broken.

Finally, you still have to trust the code sent by the server, so there's no benefit here if you're logging in via HTTPS anyway. When you send your password over HTTPS, you're effectively giving it to the server and trusting the server to handle it correctly. If you don't trust the server enough to give it your password, there's no point trusting it with the JavaScript it sends you to perform the authentication.

Bruno
  • 10,765
  • 1
  • 39
  • 59
  • 2
    +1 for "if you don't trust the server". Also if the server knows the hash and you can just log in with the hash, then the hash becomes the password effectively. – Stephen Paulger May 18 '11 at 14:23
  • @StephenPaulger, about hash/password, yes indeed. Unless you're using SSO or client-certificate authentication, authentication is biased towards having the server calling the shots on what the password ought to be (pushed to the extreme, it could even reset your own password and lock you out of its services). In that context, "ownership" of the password is shared between the user and the server anyway. – Bruno May 18 '11 at 14:35
6

For your specific example there is at least one business reason and one security reason that it might not be done that way.

Business reason

  • User requires Javascript. This is not necessarily always enabled.

Security reason

  • Passwords are normally stored hashed with a salt. You would need either a constant salt, which would make it less useful; share the specific user's salt, which adds complication and again makes it less useful (though not to the degree of having a constant salt); or perhaps a username based salt.

Not all systems do avoid using a system like you describe, Lastpass calculates hashes on the client-side (described in a Security Now podcast (transcript).

Stephen Paulger
  • 191
  • 7
  • In terms of storage, you could store the equivalent of the "HA1" hash in HTTP Digest (that's more or less using a username salt indeed). – Bruno May 18 '11 at 14:19
3

Doing any security on the client end has one huge problem: you assume the client is going to behave well. What if they don't? So you let them calculate a hash...now you got people using pre-calculated hash tables banging on your server at super-fast rates, taking out one of the major benefits of hashing: their slowness. If you don't do that, but have the server do the hashing for the client, then you can have the client request zillions of strings to hash, slowing down the server... So basically it's 'pick your poison.' You have to pick the answer based on domain-specific knowledge: do you trust your users? Is it internet facing? If it is, then you probably don't want to trust the users.

Learning about protocol analysis is probably the best way to understand why you don't want to let clients do much security-related. Replay attacks, precomputing attacks, they all happen because you give clients too much freedom, too much choice. Read about Needham-Schroeder-Lowe protocol, how it came about, how they discovered an attack, and what's the fix, it's a great demonstration of how you want to build a protocol that is safe from malicious clients.

Marcin
  • 2,508
  • 1
  • 15
  • 14
1

To answer your question it suffices to understand the point of hashing passwords.

The reason passwords are hashed is to store a derivative instead of the actual password. This prevents mallory from logging into the server as alice even if he would have compromised the database of the server (a quite common problem). You always hear about credit card numbers being disclosed and not passwords, because the hashed passwords are not vulnerable in this way.

This also prevents mallory from discovering a password that alice might be using on other websites/software.

It might be noted, although not necessary to answer your question that a salt is used on servers when hashing. This is done to prevent rainbow table attacks, because it is possible to iterate random passwords and hash them with commonly used hashing algorithms to store them in a table. Mallory could now retrieve the passwords again by doing a table lookup. This is common technique for recovering operating system passwords. (at least windows does/did not use a salt). The essence of a salt is that it is unique per installation/website as well as secret (it will usually be stored in php/config files rather than in the database with the rest of the passwords).

On client side security. What you propose is not really client side security, as you just propose to omit a step from the procedure of storing passwords. Note that every user is free to use a hash as a password.

The point to understand is that you should always do security on the receiving end of some connection (especially but not only on a publicly accessible service). Since a web server can be connected to by anyone you cannot trust anything that comes in. Any security that might have happened on a client has to be done over, because some attacker might easily bypass that security.

As a counter example, note that the client also has security. When the browser is the receiving end, it will restrict access to the host file system for example to scripts on websites.

1

Sorry to be late to the party...

The answers are all right that by using the received hash as-is to compare against your database, you have made the hash the new "password". However, if you add a random challenge (aka "nonce") the hash transmitted can no longer be used as the new password.

I strongly disagree with those answers that generalize that client-side security is a bad thing. We are using client-side hashing (using a salt and a nonce) on a high-profile website for years. Mainly for two reasons:

  1. Avoid plaintext passwords from accidentally ending up in server logs
  2. Prevent "wandering eyes" of system administrators from learning passwords

Using client-side hashing we will never be exposed to the users' plaintext password, and have thus reduce our liability.

We are currently trying to engineer key stretching into the system, which proves to be a bit harder. See Challenging challenge: client-side password hashing and server-side password verification

Community
  • 1
Jason Smith
  • 1,551
  • 2
  • 11
  • 12