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)?

Improve this question
4
  • ... 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, 2016 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, 2016 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, 2016 at 21:32
  • Not sure if they are duplicates, but here are a bunch of questions on the topic of client side hashing: security.stackexchange.com/questions/23006/… security.stackexchange.com/questions/31920/… security.stackexchange.com/questions/100957/… There are more if you search for "client side hashing".
    – Anders
    Apr 30, 2016 at 17:55

1 Answer 1

Reset to default
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.

Improve this answer
1
  • Right.. answering when tied doesn't work
    – Robert Mennell
    Apr 30, 2016 at 17:55

You must log in to answer this question.

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