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.
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.