1

I'm designing a web API, which will use credentials from another system to authenticate. The API will require HTTPS, however I still want to avoid sending a basically plaintext password over the wire using HTTP Basic Authentication.

I'm aware of the Secure Remote Password protocol, but TLS-SRP (as SRP authentication over TLS will effectively be) seems overkill for the level of sensitivity of data the API will provide (mostly sensitive business-level IT info; not something we want to shout to the world but not financial or personally-identifying).

I'm thinking that a scheme where the client SHA256-hashes their password, then transmits username and hash over HTTPS to the API server, which can then bcrypt it before comparing to a stored hash, should be more than enough to securely transmit and store user credentials. What vectors could this be vulnerable to (other than a keylogger on the client device)?

KeithS
  • 6,678
  • 1
  • 22
  • 38
  • ... So you want to double encrypt a password?(SHA-256, bcrypt) On top of that how are you going to enforce the SHA encryption? – Robert Mennell Apr 29 '16 at 20:52
  • I want what the user taps in on the device to not be what is sent over the wire (or trivially derivable as with Base64 encoding), and I want what's sent over the wire to not be what's stored on the server for verification. SRP and hashed hashes both accomplish this. SRP additionally guards against MITM compromise of the TLS channel (someone who can bypass TLS and see the hash could then authenticate with this API; the hash would still provide some protection against password reuse across systems), but if someone's willing to go that far to get the information involved, they can have it. – KeithS Apr 29 '16 at 21:00
  • Unless I'm misunderstanding how you're going to use the hash, this is nothing more than an absurdly long password they have to store. Are you going to decrypt the hash they send you and the bcrypt the payload? – Robert Mennell Apr 29 '16 at 21:32
  • Not sure if they are duplicates, but here are a bunch of questions on the topic of client side hashing: http://security.stackexchange.com/questions/23006/client-side-password-hashing http://security.stackexchange.com/questions/31920/client-side-hashing-to-decrease-value-of-password-guessing-heuristics http://security.stackexchange.com/questions/100957/hashing-user-passwords-via-javascript-client-side-versus-server-side-hashing There are more if you search for "client side hashing". – Anders Apr 30 '16 at 17:55

1 Answers1

4

So I'm going to call your hash a payload.

Your idea sounds like:

Send me a payload so I can confirm the bcrypt value of it.

Which exactly the same as a password:

Send me a payload so I can confirm the bcrypt value of it.

This is nothing more than security theater and you're trying to get people to generate an absurdly long password they then need to store and reuse every time because they may not be able to regenerate the exact same way.

You've also already said that if someone completely owns the user in a MITM attack it's kind of worthless because now they have to generate a new hash, for this service and any other service that uses that hash(just like a password).

Really what you're asking as user to do is generate a unique, HUGE, impossible to remember password for your service that they have to store anyways, now in a digital only format because it's impossible to type, or write down.

This is a BAD idea. This also ignores the limitation of bcrypt only using the first 72 characters of a string.

Robert Mennell
  • 6,968
  • 1
  • 13
  • 38