Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Parent Full thread

I am ambivalent about using HSMs to protect password databases, because if you're going to do that, you might as well simply introduce a minimalized authentication server (ie: something with an <AUTHENTICATE(user, password) bool> interface). It'll have approximately the same attack surface, it actually helps your architecture in other ways, and it precludes attackers from getting hashes in the first place (at least, the same way an HSM does with the HMAC key).

A Go, Rust, or (minimal, non-framework) Java authentication server speaking HTTPS to solely that AuthN interface and sharing no database with anything else is extremely unlikely to be part of any realistic "kill chain"; it'll be among the last things on your network compromised.

Meanwhile: you get to stick with technology you fully understand and can manage (simple HTTP application servers and a decent password hash) and monitor.

HSMs have a lot of uses elsewhere in secure architectures, but the password storage use case is overblown.

We discuss exactly this architecture in the talk we gave back in 2014. See here for the part where we discuss it: https://youtu.be/lrGbK6fE7bI?t=16m31s

Basically we 100% agree with you that an authentication service should do this job. The HSM is extra credit. Although it does help in cases where the auth service's DB is leaked through some other means (e.g. backups).

I will say that I'd depart with you on the return value of that service. It shouldn't be a bool. It's better to return a token that downstream services can use to independently verify that the authentication service verified the user. Its better for your infrastructure if you aren't passing around direct user IDs but rather a cryptographically signed, short lived token that is only valid for the life of a specific request.

We recently developed/deployed a simple “crypto as a service” API for other apps/services to use for easy encrypting, integrity protecting, etc. It was originally developed with an HSM and eventually decided to redo it without. There were lots of unanswered questions with the HSM in terms of having the operational experience to know how they would scale across data centers, how well replication would work, how well failovers would work, etc. We had much stronger confidence in a plain old golang service, MySQL, and leveraging Vault as a master key issuer. We basically key wrap/integrity protect everything in the DB and present a simple Grpc interface. An HSM would have been nice, but a small/simple service isolated from other systems largely gets us what we want, and with the confidence to scale it as we would any other application.

I agree with you, but I'm apples/applesing that service with an HSM and deliberately keeping the interface minimal, just for the sake of argument. The subtext is my worry that normal developers on HN don't really understand why HSMs are operationally secure --- minimal attack surface, not magic hardware.

FWIW I was concerned folks would get caught up on the password storage use case since so many are familiar with that problem. The crux of the idea of crypto-anchoring is to segment crypto operations in to dedicated microservices and use those minimal microservices to do per record encryption, decryption, or signing. HSMs are a natural extension to those microservices if you have budget.

HSM have other security properties that you cannot replicate with software. They are tamper resistant in a way a regular server is never going to be, and they have been engineered to prevent sidechannel attacks. The latter is something very hard to prevent with a regular server.

I agree that for the majority of usecases, a HSM is not necessary, but they do bring security to the table that a simple auth server cannot, at least not without significant engineering effort.

Don't disagree; I think what I actually tried to argue for was doing both: segregate data access to a new, minimal, service that also requires a key in an HSM to operate.

Given a servlet-only Java AuthN server with no interface other than "Authenticate", what is the likely attack that the AuthN server falls to but the HSM doesn't? From what I can tell, both the HSM and the Java servlet app have really just one major weak point, and it's shared: the management interface.

I may be reinventing something that is already done here, but it occurs to me you could also put canary accounts in your data (say one every 100 entries) and use it as a tripwire to alert ops the moment one is passed to the auth service.

I've gone with this approach for a niche social networking site I'm building. The biggest benefit an HSM provides is vendor wrapped keys, which does simplify key management and allows you to lean more on your vendor to support key material confidentially. In my case I didn't feel the added cost and complexity was worth it.

This isn't only about HSMs or dedicated services. To anyone reading this thread: the key thing to understand here is: How do crypto-anchors help against attacks that allows `select *` from a database? A: Per-record encryption mediated by a dedicated microservice.

But there's really nothing "cryptographic" about an isolated authentication service. To drive the point home, and don't do this, but if you (1) used dedicated hardware to run it, (2) IP filtered the box down to just HTTPS, and (3) ran the service using Go, Rust, or Java Servlets, you probably wouldn't even need to use a good password hash.

I'm only talking about the AuthN problem, by the way. I'm not making a general argument against circuit breaker architectures.

Folks need to worry about being able to protect more than just passwords. Engineers should be doing a good job of protecting SSNs, phone numbers, home addresses, etc. Crypto-anchoring can help for the general case of protecting sensitive information, not just passwords. `select *` shouldn't give anything in your infrastructure bulk access to sensitive information. The 'cryptographic' thing here is per-record encryption.

I think tokenizing services are a very good idea in general. I just think there are easier and more effective ways to handle the AuthN problem.

But if you have your authentication server, that server becomes a target. And unless you're using an HSM under the hood, you're still exposed to hashes being stolen.

I think the idea of the author is to protect the operation with hardware.

A dedicated AuthN server presenting only a trivial interface built on a minimal-runtime memory-safe language with no shared database is an extremely hard target. Not that either outcome is likely, but a reasonable person can argue that you are more likely to make a mistake implementing HSM-augmented password hashing on a general-purpose app server than you are to screw up a dedicated Java AuthN server.

"Hardware" isn't magic. The magic power of an HSM isn't the hardware; it's the minimalized attack surface of the software.

Reply on news.ycombinator.com