This week we put live a system that includes secure document delivery that allows end users to access sensitive documents on their own computers or mobile phones.
The current manual process our clients was using involved MS Word documents in encrypted ZIP files, which created too many compatibility issues. We decided there were several problems here. Not all devices can decrypt a ZIP file and render an MS Word document out of the box. Also, the transmission of data through the email system required very strong one-off passwords that were hard for end users to deal with.
There were three key considerations:
The integration with the main records system convinced us that third party services were an unlikely candidate. We thought the implementation overhead within the main records system, which gave us the same security profile as that system, aligned well with the overall goal.
We first looked at third-party services that specifically provide file transfer functionality. The separate billing for such a service would be a overhead, as would integrating it with the main records system. The perception of security might not be as strong and some networks might block this type of service. Finally, we’d have no control over how easy the system was for end users, and third party services often try to foster their own relationship with those users, which was undesirable.
We decided that the system should be a bespoke development that was part of the main records system. This solved any integration requirements and provided a clear message on security by eliminating third parties.
End-to-end encryption was considered, but as no third parties would be involved, encryption in transit over HTTPS would be sufficient and far simpler for users to access. This removed the need for encrypted ZIP files which caused so many problems.
However, HTTPS did not limit access to intended users. Strong passwords would be unreasonable for one-off users, so we decided a one-off link provided by email combined with a simple security question and answer would be strong enough, provided the link only worked for a limited time. An attacker (a) would need to gain access to email or guess a cryptographically strong random number to get the link, (b) would need need to determine the answer to the security question and (c) do this within the right time-frame. Arguably, such an attack would be harder than conventional eavesdropping means that would achieve the same goal.
The system was deployed within three weeks of its conception and has been securely transferring documents since.
Picture by Joakim Honkasalo.
Solomon Hykes is probably most famous for being the founder and former CTO of Docker. Docker revolutionised the way we package, run and distribute server applications, so when Hykes starts a new venture, it's worth checking out.Discover More
I recently set up a Terraform project which I wanted to run on a regular schedule. There are a number of ways to achieve this, but I decided to package the project as a Lambda function and schedule it with…Discover More
I recently configured Single Sign On (SSO) from our Google accounts to AWS. AWS SSO is the recommended way to configure SSO across multiple AWS accounts, yet Google is not a supported identity provider. However, this simply meant that there…Discover More