Better than sending passwords directly through your instant messaging client!
Security is a compromise between convenience and safety. Sending passwords over instant-messaging applications (Slack, Skype, Teams, etc) is endemic, particularly in smaller companies, where security tooling tends to rank lower.
Using multiple separate channels to send data improves security - for example, sending an encrypted email with the decryption key sent through SMS. In recent years this has started to become more common.
- Allow at-most-once access to the data I want to share:
- Data is erased immediately as it is accessed.
- Limit the time the data is accessible for:
- Data is inaccessible after 5m.
- Don't trust the server
- Server has no knowledge of encryption keys- all data is encrypted and decrypted in the end-user's browser using a libsodium
- Key is never sent to the server by using a URL fragment.
- Send the data through multiple routes:
- Only encrypted data is stored on the server at a random URL
- URL and password are send to the target user through an instant-messaging client
- Fast end-user experience
- Perform encryption, generate the URL and copy it with
Shift + Return
or one button tap - Paste the URL automatically fetches, decrypts and displays the data
- Everything works from one URL
- Perform encryption, generate the URL and copy it with
- The user visits the website (passcache.net), and types in the password they want to share with another user.
- The brower auto-generates an Id and symmetric encryption Key directly in the browser on the user's computer. The encryption Key never leaves the user's compuater.
- The user-provided data is encrypted using the encryption Key and sent to the website's server under the generated Id.
- A URL is constructed locally in the browser using the Id and appended with the Key as a fragment. For example https://passcache.net?97e82ccc#912e, the Id is
97e82ccc
and the Key is912e
. - The user sends the full URL through their instant-messaging application.
- The receiver pastes the URL into their address bar.
- The browser sends everythig before the fragment to the server, which looks up the encrypted data using the Id, deletes it from memory, and sends it back to the browser. The fragment portion of the URL, which is the Key necessary for decryption, is not sent to the back-end server.
- The browser decrypts the encrypted data using the Key from the fragment and shows it to the user.
=== SENDER ===
┌─────────────┐
│passcache.net│
│ │
│ │
│ ▲ ▲ │
│ │ │ │
┌───────────────────┐ └──┼────┼─────┘
│ Browser │ │ │
│ │ │ │
│ ┌───────────────┐ │ │ │
│ │Id (Generated)├─┼──────┘ │
│ └───────────────┘ │ │
│ │ ┌──────┴──┐
┌────────┐ │ ┌───────────────┐ │ │Encrypted│
│Password├──────┤►│Key (Generated)├─┼───►│Password │
└────────┘ │ └───────────────┘ │ └─────────┘
│ │
└───────────────────┘
https://passcache.net/get?Id(generated)#Key(generated)
=== RECEIVER ===
┌───────────────┐
│ passcache.net │
│ │
│ ┌───────┐ │
│ │ │ │ ┌─────────────────────┐
└────┼───────┼──┘ │ Browser │
│ │ │ │
│ │ │ ┌──────────────┐ │
│ └─────────────┼─ │Id (From URL)│ │
│ │ └──────────────┘ │
▼ │ │
┌─────────┐ │ ┌──────────────┐ │ ┌────────┐
│Encrypted├───────────────┼─►│Key (From URL)├───┼──►│Password│
│Password │ │ └──────────────┘ │ └────────┘
└─────────┘ │ │
└─────────────────────┘
- First version written in July 2013 in C#, and pre-dates Firefox send by a few years.
- Original codebase is at https://github.com/vsliouniaev/pass-cache.
- Thanks to @eoincampbell for suggesting the URL fragment trick.