Can you keep a secret?

Explore

Security Info

Just a few musings about security, and some advice to keep in mind...

My background

Prior to jumping on board with SupSync, I was a web developer for a good few years (*ahem, decades).

After having a few sites compromised over the years, security became something I really deep dived, spent a ton of time researching, and formed a genuine interest in. That time has made me really appreciate how difficult it is to build a system that is 100% secure against someone with enough time, experience, and motivation. I mean there are attacks which exploit the atomic properties of the silicone used in your computer/phone’s memory chips to gain root access to your operating system.

⁠

How the heck do you built a system safe enough for those guys to not breach?!

What I’m trying to say is that if you’d like to use anything in this doc for protecting genuinely sensitive information, please review it with a security expert before deployment.

⁠

An open window

First, a metaphor... Someone once explained web security as a big house with 100 windows and doors. If you install the best quality locks and security gates, and each night lock and secure only 99 of them, but leave one open, all the effort put into your security is worthless. That’s been a really valuable metaphor to me, and is a smart way to look at security - a reminder to be both holistic in your approach and mindful of the small details.

⁠

A burglar just needs one open window

⁠

Don’t forget the user interface

The

Strong Security⁠

and

WikiVault⁠

implementations both use the SHA512 hashing formula as part of their encryption process. This is the same hashing function which the US Government uses for Classified Information and that banks use to protect your financial information. It’s very easy to focus on that feature, which makes the system sound impenetrable.

It’s important, however, to remember that somewhere in your doc the user needs to insert their password as part of the decryption process, so if you don’t have a good UI that clears that field out as soon as possible, it’ll just sit there visible for anyone to see.

It’s important to be mindful of how your doc will be used by users, not just the underlying security features you’ve implemented.

Complexity doesn’t equate to security

With all of the solutions in this doc, there are many moving parts. Tons of tables, tons of formulas. Complexity can give you a false sense of security, and it’s important to be aware that the more moving parts there are, the larger the possibility becomes of a gap opening unnoticed.

Sometimes the complexity of a solution can distract a builder from remembering to close up “the other windows and doors”.

⁠

Premature Use

With web technologies, there are a ton of established best practices when it comes to security, and specifically encryption. If you follow those, you can rest assured you’ll be pretty safe. Because of that wisdom, I’ve felt safe tasking my team with web security implementations even in relatively high risk scenarios.

Those best practices don’t exist yet when it comes to encryption in Coda, so although you’re more than welcome to use anything you learn in this doc, I really recommend against using this for storing actual sensitive information securely. And please, if you’re using this for client work, be honest and upfront about just how new this solution is. At least until enough eyes have reviewed it for any “open windows”.

Finally, a standard disclaimer... use at your own discretion. You’ve been warned. Don’t come for me, or my lovely family at

Supersynchronous⁠

. This doc is provided as is without any warranty.

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.