Ask HN: How are people storing user-scale secrets? | Hacker News Reader

Ask HN: How are people storing user-scale secrets?

5 pointsawinter-py10 comments

Like when you capture an oauth key, or some other 'password-like thing' that you need to store per-user and need to retrieve in plaintext so you can access an external service. Are you just putting this in a DB? AES-ing it?

My goal is to not leak oauth access when my DB inevitably gets stolen.

View on HN

Auth0 has some good articles on this https://auth0.com/blog/refresh-tokens-what-are-they-and-when... https://auth0.com/docs/best-practices/token-best-practices https://auth0.com/docs/security/data-security/token-storage

hmm these all seem to recommend browser local storage

First ask yourself if you need to store it at all. Can the client store it as a cookie that you forward only when necessary?

Good question -- not in my case, but I think yes in a lot of other token auth cases. In my case I'm storing, per-user, a secret that I need to send to a third party from time to time. The client isn't in the loop for these; they're async.

You can encrypt it in the database, but my preference is to just reset the tokens if and when the DB is stolen. If they've managed to steal it, solid chance they'll be able to decrypt it from the running db process or sniff through other infrastructure.

how will I know when the DB is stolen?

Really depends on your DB setup, ie if it's on a managed service or not. There's plenty of work done into intrusion detection if you're managing it.

Like others said, try to make it's so you do not have to store anything. Otherwise, AWS has Secrets Manager for example but thatll probably be expensive for user scale in which case you can encrypt and store in DB.

yeah, KMS tools feel like they're for storing tens of things, not thousands of things

at least from a pricing perspective

In a notebook that I keep in a fireproof safe.

Reply on news.ycombinator.com