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 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 HM…
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.
Delegating security-sensitive operation to a dedicated service (e.g. an authentication service) is security 101. It's just an application of the principle of least privilege.
Giving it a fancy name makes it look like it's a new idea.
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 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 HM…
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.
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 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 HM…
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 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 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 HM…
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.
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 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 HM…
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…
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.
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…
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.
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 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 HM…
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.