Create New Secret

Limitations & Usage

OTS is much better than sending secrets directly via insecure means, but it is by no means perfect or invulnerable. The following are the known security limitations of the service:

• Since encryption is not performed in the browser, it is possible that man-in-the-middle attacks via proxies could be undertaken. TLS mitigates this to an extent, but not perfectly
• Because insecure means of communication are insecure, it is possible that a secret transmitted via OTS could be intercepted by unauthorized persons. The system provides an indication that this has happened (the intended recipient isn't able to retrieve the secret), but does not actually prevent it from happening
• The OTS backend is written in Python and runs as an AWS Lambda function. It is therefore possible that secrets might linger in memory on AWS servers
• It is up to the users of OTS to take suitable precautions to avoid issues related to these limitations

• If the recipient isn't able to retrieve the secret, rotate the secret before trying again (i.e. assume that the secret has been intercepted by a third party)
• Avoid sending secrets that cannot be rotated. Because it is theoretically possible that an unauthorized party could intercept the OTS link and use it before the intended recipient, secrets that cannot be rotated should not be sent via OTS
• If a secret that cannot be rotated must be sent:
  1. Create an encryption key for the secret
  2. Transmit the key via OTS to the recipient
  3. Verify that the recipient was able to retrieve the key
  4. Encrypt the secret using the key
  5. Send the encrypted secret via OTS
• Avoid sending context with secrets - e.g. send _just_ the password, rather than saying "here is the password for thus-and-such" along with the password