6

It seems to me that if an attacker can intercept my login request (sent with HTTP POST), then he can replay it later, no matter whether I try obfuscate it or not.

What am I missing?

Improve this question
4
  • 2
    if you have the server generate a nonce, send to the client, who concats the password and hashes the combo, sending it back to the server for verification, you can't replay the password hash later. but you should really use https and some kind of tool made for keys, like bcrypt or scrypt
    – dandavis
    Jun 26, 2016 at 8:44
  • 2
    I don't think it's clear what you're asking. You ask what are you missing but I don't know what or who you listened to or read. Who suggested sending a password encrypted or as SHA1?
    – bdsl
    Jun 26, 2016 at 11:54
  • 3
    This is not answering the question, but my advice to you is that you should not send the passwords over http, I can't think of any reason you would really want or need to do this, especially now that lets encrypt exists, so if you need a free ssl certificate, check out letsencrypt.org
    – chrisweb
    Jun 26, 2016 at 19:15
  • So, (and please pardon me for being dumb) how should I ensure that given user is who he claims to be and give him access to his data without sending user name & passwrd to my server? I hope that you can help me to learn.
    – Mawg
    Jun 27, 2016 at 7:35

3 Answers 3

Reset to default
9

I'm assuming that you are talking about additional hashing. So it would look like this:

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

I think you are aware of this, but just to make it explicit: the transfer needs to happen via SSL to defend against eavesdroppers, hashing client-side would be no help against them at all.

Hashing or obfuscating a password client-side can be a good mitigation against password reuse:

Even if an attacker accesses the password in plaintext either in transfer or at the server, it would still be hashed, so an attacker cannot try the same credentials at other websites without first cracking the hash.

It seems to me that if an attacker can intercept my login request, then he can replay it later, no matter whether I try obfuscate it or not.

Yes. Hashing client-side doesn't add any security to your application, the only advantage is that it mitigates bad user behavior, which may affect other applications the user is also using.

Note that it doesn't even protect your application from password reuse, as an attacker that gained that users credentials from another application would just hash it and try that.

It also does not add any complexity to the process of cracking your stored hashes. An attacker would not try a list of hashes as input, but a normal wordlist, which they would first pass through sha1.

Improve this answer
8
  • Client-side hashing should be helpful if salted by a one-use token (say, CSRF), shouldn't it?
    – John Dvorak
    Jun 26, 2016 at 12:40
  • @JanDvorak If you do that, how do you check the password on the server side?
    – zwol
    Jun 26, 2016 at 12:42
  • @zwol by hashing it with the same token that the server sent to the client? ... Oh, right, the server doesn't have the password.
    – John Dvorak
    Jun 26, 2016 at 12:43
  • Does it provide any security if I hash the password unsalted on client (obtaining a copy of what's in the database), then salted on both sides, and send the double-hashed password to the server?
    – John Dvorak
    Jun 26, 2016 at 12:44
  • 2
    You could also mitigate replay attacks by including the current date/time in the request and having the server reject if the timestamp is more than a few moments off. Since the request is encrypted, it cannot be tampered with, thus the entire request becomes time-bound.
    – Brandon
    Jun 26, 2016 at 13:47
2

As tim wrote, it could help mitigating the effects of password reuse for users in a few cases, but if what you're thinking of is hashing it client side instead of on the server side, this would be a major design flaw.

https://en.wikipedia.org/wiki/Pass_the_hash

This problem plagues the NTLM authentication, where it's actually even worse than in the common Web application/service scenario, since hashes are often cached on systems other than the server handling your authentication.

Improve this answer
-1

Your sha1 password simply becomes the plain password for an eyedropper.

What I do is the following:

On the database, each password is encrypted with bcrypt and a salt. The salt is "public".

When the user log in, the following happens: -> client send username -> server reply with "salt" -> client generate a random nonce -> client send "bcrypt(nonce+bcrypt(salt+password)+time)+ +time+nonce" -> server check that the nonce hasn't be used in the last 5 minutes, then does the password check. It is done by comparing input sent from client with "bcrypt(nonce+dbvalue+time)". -> for non existing user, an honey salt is sent.

It's quite hard to hack, but requires Javascript client side for browsers.

Even if one is eyedropping, the bcrypt hash is hashed everytime with new nonce and time.

This answer is effectively easy to get wrong, so I made a diagram: Registration, id and auth

Also, see here why I add this extra layer even with SSL: https://blogs.msdn.microsoft.com/vbertocci/2005/04/25/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked/

Improve this answer
10
  • 1
    But this means that you are essentially storing your passwords in plaintext, right? I'm assuming dbvalue is bcrypt(salt+password), as otherwise your comparison wouldn't work. And this means that if I get access to the dbvalue, I can just send you bcrypt(nonce+dbvalue+time)+time+nonce and log in, without having cracked the users password.
    – tim
    Jun 26, 2016 at 19:36
  • @tim If you get access to the database, you can indeed break in. But you won't be able to reuse my password on other websites. That's the only reason it's encrypted in DB.
    – programaths
    Jun 26, 2016 at 20:05
  • 1
    Well, generally, passwords are hashed before storing them in the database in case the database is breached (SQL injection, old backup, etc). Protecting against password reuse is a good idea, but as it doesn't actually affect the security of your application, I would rank it as secondary (and if I would want to defend against it, I would use the approach outlined by the OP).
    – tim
    Jun 26, 2016 at 20:10
  • 1
    The OP didn't specify if there is additional hashing server-side, but it would certainly be possible. With your mechanism, additional hashing doesn't seem possible, which means that you exchanged storing hashed passwords (which is considered best-practice) for (possibly, don't roll your own, etc) some limited confidentiality (which is a solved problem via SSL).
    – tim
    Jun 26, 2016 at 20:24
  • 2
    This is bad! As @tim says, it leaves you open to DB leaks. There is decades of password storage best practices that you selectively chose to recommend the OP to ignore for seemingly no reason
    – Neil Smithline
    Jun 26, 2016 at 22:03

You must log in to answer this question.

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