How would you design an API server to store user sercrets?

user104510

10/21/23, 8:30 AM

This is not for a production application, but just my exploration to help me understand cryptography.

At the simplest level, I want to design a key-value store for user secrets.

This is exposed over an HTTPS API with usual create-read-update-delete operations supported: send a post request with a body of a sercret, the server encrypts and stores that secret, then returns back an id for that secret; send a get to the id and get back the decrypted secret; etc.

This service receives requests from other microserivces in the network on behalf of the user.

How should the service protect a user's secrets, and protect against unauthorized access to this API?

I know that in some way the service needs to authenticate and authorize the request from both the upstream service and the user.

What's a good way to pair these? One idea I have is something like...

Generate a key
Encrypt the secret using the key
Store the encrypted secret
Encrypt the key using...? something from the server + user - a shared secret maybe?
Store the encrypted key
Return to the user an id (token)

And to retrieve the secret:

user/other service requests id from server
server + user shared secret decrypts key
key decrypts secret
send secret to user

1 + 0

protocol-design

Score:0

Crypto

JAAAY

10/21/23, 10:15 AM

Your application is the simplest form of an encrypted pastebin for example, for something like this you can take a look here. Also, there isn't a golden rule on how to design such an application. It really depends on the specifications you set. For example, the ideal from a security perspective is to encrypt the secrets client side and the server then just becomes a simple database. It can indeed be replaced by a db service and not an http api but you can build an http api on top of the db service as well. On the other hand, you may want to make your api accessible to low/end low powered devices, then you have to choose an appropriate cipher for this if you want to support client side encryption. If for some reason you want to restrict yourself to server side encryption there are a lot of methods that you can use but things get a bit more complicated here (let me know if you want to update my answer). Also you may be interested to add password authentication in order for example only registered or invited users to be able to store secrets, for this you can use an SRP protocol. Again, these are only a few ideas and resources to get you started.

+ 2

JAAAY

10/22/23, 11:40 AM

@MaheshSundaram For server side encryption, it depends on what security levels you want to achieve. For example, in the simplest case to achieve security you have to consider the server as a trusted third party. Both scenarios you mention don't make a difference from the security wise perspective.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How would you design an API server to store user sercrets?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.