1

I've developed my application to use salted SHA-512 password hashes.

If a hacker were to obtain the hash, what can I do to protect against the hacker using Greasemonkey to alter the login page so that the password is not hashed? The attack vector I foresee would enable them to type the hash they've acquired into the password input and then the Greasemonkey-altered page sends that info as is (w/o hashing the entered password which is the actual hash).

That is just one example of how an acquired hash could be used. There are other ways the site's code could be altered with Greasemonkey to achieve the same result.

I can't think of any ways to prevent / protect against this type of attack.

Has anyone here come up with something?

ic3b3rg
  • 14,629
  • 4
  • 30
  • 53
  • 6
    You should be hashing your passwords server-side. Then, there is little risk. – Brad Jun 11 '12 at 17:59
  • That would require transmitting the password in plain text – ic3b3rg Jun 11 '12 at 18:01
  • 5
    Never hash passwords on the client side - this way the hash becomes the password and you are still transmitting it in "plain text". Use SSL to protect the password transmission. – Wladimir Palant Jun 11 '12 at 18:02
  • @Brad: Thanks, I think I 'get' it now. I'm now wondering if there's anything about my session authentication that I can improve - details are below in a comment on Rich Bradshaw's answer. – ic3b3rg Jun 11 '12 at 18:32
  • @WladimirPalant: Thanks to you as well. – ic3b3rg Jun 11 '12 at 18:32

2 Answers2

7

Hash your passwords on the server. Use SSL to protect over the wire.

Rich Bradshaw
  • 71,795
  • 44
  • 182
  • 241
  • OK, I think I'm starting to understand why this is the solution. I'm trying to wrap my head around this stuff. – ic3b3rg Jun 11 '12 at 18:08
  • Once the user has logged in, I create a session-specific, time-limited code which I store in the database and as a cookie in the client. This is used for all further communication in the session. Any improvements I should make here? – ic3b3rg Jun 11 '12 at 18:24
  • You language should have Session cookie support built in already, but yeah, that's the idea. – Rich Bradshaw Jun 11 '12 at 18:32
  • This answer does **nothing** to guard against Greasemonkey exploits! – Brock Adams Jun 11 '12 at 21:10
  • If javascript can mess up your auth, it isn't auth. There is no way that JS should be able to interfere with your auth process. – Rich Bradshaw Jun 12 '12 at 07:08
  • Ah, Brock, I see you are not talking about Alice trying to gain elevated permission on Bob, but a 3rd party trying to steal Alice's credentials. That's usually out of scope as that's for Alice to ensure doesn't occur. – Rich Bradshaw Jun 12 '12 at 07:10
  • Nevertheless, that is the issue stated by the question. `"what can I do to protect against the hacker using Greasemonkey to alter the login page"`, etc. The only risk in the stated scenario is to Alice (unless the site/app disregards typical security practices). Either way, this answer protects neither Alice, nor the site from the stated type of exploit. The bad guys will be able to establish an SSL connection just fine and login with Alice's credentials. – Brock Adams Jun 13 '12 at 01:18
  • Yes, but reading his answer, it sounds as if he is hashing in JS, then passing that to the server. Which is an insecure way to go about this. – Rich Bradshaw Jun 13 '12 at 07:09
1

This question is about vulnerability to Greasemonkey intercepting passwords, right?

In that case, SSL does nothing to protect against theft of the user's credentials, the password (or hash, or whatever) will be obtained right from the user's browser and transmitted to the bad guys via GM_xmlhttpRequest().

If you try to encode or hash the password, client-side, Greasemonkey can intercept or even replace the responsible JS.

See "Can a website know if I am running a userscript?", you can make it harder for a script writer but, ultimately, if the bad-guys can get the user to install a Greasemonkey script (or worse, a full-on add-on/extension) then you can only make it harder -- not impossible -- for the user's account to be compromised.

I wouldn't even worry about it until/unless you have evidence that a malicious script or add-on is in use. Ultimately, the user is responsible for keeping his browser, and client-side interactions, secure.

Things you can do to make it harder (not impossible) for a scripter:

  1. Monitor your logs, checking for unusual activity (should be doing this anyway).
  2. Take protections against bots in general, see "When the bots attack!", for example.
  3. Warn user(s) if an actual script or ploy is detected.
  4. Monitor the users' accounts/actions for unusual activity.
  5. You can intercept the password, as it is typed, with JS and one-time encode some how. This will filter out the causal scripters but not the determined ones. Note that I do not recommend this, just including it for completeness.
  6. Put the password entry in a Flash dialog. Pure Greasemonkey has a hard time interacting with Flash. Again, I don't think this is cost-effective, but include it for completeness.
  7. Do NOT require any more tedious steps for legit users (one-time passwords, third channel authentication, etc.). This will only annoy the ever-loving heck out of your victims until they find a better alternative or workarounds (which they will).
Community
  • 1
  • 1
Brock Adams
  • 90,639
  • 22
  • 233
  • 295