A couple of days ago I released a new feature that's built on the 10Cv5 API called Locker. The concept is hardly original, but it does solve an immediate problem that I've had when trying to work with sensitive data at the day job where colleagues are involved. Generally the problem goes something like this:
- I need access to a resource or see a config file, so ask the person in charge
- Assuming all the security conditions are met, they grant access and send the resource via an "anonymous" online service that requires a password
- I type in the password and see the resource, which then "disappears" in a cloud of binary zeroes
Why this is the process I will probably wonder for a long time. That said, I am not at all comfortable with the idea of putting the sensitive data on a website that purports to be a secure way to share information. I do not know the people behind the site, nor do I have any guarantee that data is actually secured when at rest and deleted after being accessed. I am at the mercy of the people who created the site.
So, rather than allow colleagues to continue using services like this when there could be better ways, I decided to invest a couple of hours to build my own version of this service, and it's called Locker.
While others may ask the very same questions about the security and trustworthiness of this site, I can rest assured that the thing does what is advertised. This first release of the tool does not yet have the "delete on access" feature nor an expiration date for the URL that is generated, but these will come over the coming days as responsibilities at the day job start letting up. What I like about having this feature built into 10Cv5 is that I will not be the only person to benefit from this. People who will choose to self-host the software will have the option to enable the feature if they think it would be of value.
Once the two remaining key features are implemented, I'll consider the feature "complete" and invest in a memorable URL. While I don't expect this sort of service to be popular by any stretch of the imagination, I hope it can provide some value to people who need such a tool.
How It Works
For the moment, encryption is done on the server rather than in the browser. The content can be text of any reasonable length1 and the password can be of any reasonable length and include multiple different input types, including emoji. Once received, a password is generated using Open SSH ciphers and the content is encoded with 256-bit AES encryption. From there the content is stored in an encrypted area on the storage medium — not in the database — and the initialisation vector for the decryption is written into the database. The password is not stored anywhere on the server, as this would defeat the entire purpose of the feature.
Once the encryption is complete, a URL is returned and people can send that to the intended recipient. At the moment it's a pretty long URL, but I do plan on picking up a convenient domain so that short-links can be generated for this and other parts of the v5 system.
When a person visits the link to view the content, they're greeted with a password entry field. That string is then tested against the encrypted content and, so long as everything is good, the text is decrypted and returned to the browser.
This system does not require authentication at this point, as that would defeat the anonymity element of the feature, and the API endpoints are also available for people to use if they so choose. API documentation is on the way for v5 and should be online in the coming weeks in preparation for the v5 roll out this winter.
ideally under 100MB