Let me make sure I undertand: So I’m going to send my password to this device in the clear over ethernet (not even HTTPS), and it will give me back a hash.
Not sure what this is buying me. Couldn’t I setup a server with a REST API that did the same thing. If I did that, how would I be better off?
The live site, as far as I can tell, is just for testing API clients. HTTPS or not, sending your password to a service you don’t control is a good way to lose that password (i.e. the same reason different passwords per-service is recommended). There’s also an ENSCRAMBLE command for secure remote calls . The API client would handle that.
While I wouldn’t use this (too much overhead and not enough benefit for my use cases), I posted it because it’s interesting to see some of the ideas people are coming up with for hardware security having done some work on security hardware.
Probably not much; it might be interesting for an organisation or to run locally, but there are other (more effective, I’d say) local security measures. I’d be more interested in an open-source HSM or TPM, for example.
I think the idea is that even if the password server is compromised you can’t retrieve the key that’s used for the HMAC, so you can’t brute force the password database.
But a threat model that is more concerned with brute force attacks than eavesdroppers on the network is really weird. And bcrypt, etc. already do a pretty good job of preventing brute force, so idkwtf.
I think they’re not concerned about eavesdroppers due to the ENSCRAMBLE.
But I agree, it seems overkill particularly with better methods to
handle this.
Let me make sure I undertand: So I’m going to send my password to this device in the clear over ethernet (not even HTTPS), and it will give me back a hash.
Not sure what this is buying me. Couldn’t I setup a server with a REST API that did the same thing. If I did that, how would I be better off?
The live site, as far as I can tell, is just for testing API clients. HTTPS or not, sending your password to a service you don’t control is a good way to lose that password (i.e. the same reason different passwords per-service is recommended). There’s also an ENSCRAMBLE command for secure remote calls . The API client would handle that.
While I wouldn’t use this (too much overhead and not enough benefit for my use cases), I posted it because it’s interesting to see some of the ideas people are coming up with for hardware security having done some work on security hardware.
I think it’s a cool article, kyle, and I’m glad you posted it. Also, I’m not asking you defend it. :)
I’m just wondering about what the benefits of this really are compared to just bcrypting passwords myself in my own server.
Probably not much; it might be interesting for an organisation or to run locally, but there are other (more effective, I’d say) local security measures. I’d be more interested in an open-source HSM or TPM, for example.
I think the idea is that even if the password server is compromised you can’t retrieve the key that’s used for the HMAC, so you can’t brute force the password database.
But a threat model that is more concerned with brute force attacks than eavesdroppers on the network is really weird. And bcrypt, etc. already do a pretty good job of preventing brute force, so idkwtf.
Edited to add: The device it’s based on seems questionable too.
I think they’re not concerned about eavesdroppers due to the ENSCRAMBLE. But I agree, it seems overkill particularly with better methods to handle this.
That is the weirdest HSM I’ve ever seen.
Also, “ENSCRAMBLE” is not a replacement for TLS.