Design a Read-Once Password Sharing Service

Design a service for sharing a password with another person, where the shared password can be read only once. The sender submits the password and receives a link to pass to the recipient. The first time the link is used to view the password, the service shows it; after that, the link no longer reveals anything. ```hint The read is a write Viewing the secret must also destroy it. Consider what happens when two requests for the same link arrive at the same moment, and when the response to the one successful read never reaches the recipient. ``` ```hint Who opens links Think about everything that might open the link before the intended recipient does, and whether merely opening it should count as the one read. ``` ### Clarifying Questions - Must the service itself be unable to read the password, or is encryption at rest on the server enough? - Should an unread password expire, and who chooses how long it lives? - Does the sender need an account, and should they be able to see whether the password was read, or revoke the link? - Should the recipient also need a passphrase, in addition to the link? - If the read succeeds on the server but the response is lost, is it acceptable that the password is gone, or must the recipient be able to retry? - What traffic should the design plan for, and how large can a shared secret be? ### What a Strong Answer Covers - Functional and non-functional requirements, with confidentiality and the read-once guarantee ranked above throughput - An atomic consume-on-read that holds under concurrent requests, retries and replica reads - Where the plaintext and the decryption key live, and what an operator, a log line or a backup can reveal - Expiry and deletion of unread secrets, including copies in replicas and backups - Protection against link prefetching, link guessing, passphrase guessing and abuse of the create endpoint - APIs, the data model, and the behavior when a storage node fails over ### Follow-up Questions - How would the sender learn that the password was read without the service keeping anything that could reveal it? - What changes if a secret may be viewed up to a fixed number of times, or only by named recipients? - With asynchronous replication, how do you make sure a failover never brings back a password that was already read? - How would you extend the design to share files of several megabytes?