Can you keep a secret?
Share
Explore
Can you keep a secret?

icon picker
Strong Security

This solution significantly improves on security strength.

Seeds, Salts and Hashes

The main weakness in
Simple Security
⁠
is that if a user’s password is shorter than the text they’re encrypting, then we need to repeat their password to get enough characters to encode their text. This unfortunately creates patterns which an attacker could exploit.
But what if we could get the user to enter a password that was really, really long - perhaps even as long as the text they were trying to encrypt?
That’s the basis of this next demo, with one key difference. Instead of asking our users to remember ridiculously long passwords, we’ll instead use their password to generate a really, really long string of characters and use that as our Encryption Key.
Here’s our second demo but just be prepared... from a user experience perspective, it’ll look identical to the demo on
Simple Security
⁠
. If you’re particularly perceptive, you may notice a slightly longer delay after entering your password before the Encrypt button becomes clickable, but otherwise the only changes are “under the hood”.
⁠
New Secret
⁠
⁠
⁠
💡 If this block is empty, and says No Items Available,
please click the + New Secret button, alongside. 👉
⁠
⁠
No items available
⁠

⁠

So What’s Different?

Believe it or not, actually quite a bit has changed in this second demo.
Before we dive into that, I think we have time for a quick game of...

⁠
Colourful Trivia Night Party Presentation.gif
⁠
⁠
Contestant Number One ( that’s you,
Anonymous
⁠
),
when you’re ready let’s play...

“What the heck are we talking about?!”

⁠
⁠
⁠
⁠
Let's Play!
⁠
⁠
⁠
⁠
⁠
⁠
⁠
⁠

Your Lifelines —
50/50
⁠
—
Phone a Friend
⁠
—
Reset
⁠


⁠
⁠
⁠
⁠

Here’s what’s changed

💡 For some definitions, click the Gray Buttons alongside 👉
The Salt Seed column regularly generates a Salt 17 characters long. To prevent the doc slowing down unnecessarily, we only run this if a row is unencrypted and the Password field isNotBlank().
When the user clicks Encrypt, we copy the value from Salt Seed to its permanent location, another column called Salt.
A new column Password (Hashed, Salted) looks out for this event and when Salt isNotBlank(), it’ll perform the following operation:
Concatenate() the user’s Password with the Salt
SHA512() the result

💡 Here’s an example of the output of SHA512()
Think of it as if the user created a 128 character-long password
538872331507039598ddb1d934dd9d2e4c77e765df449db1a7b616a1727e02c40633f8801105b59a46db00e312656ca46a450ed66f36a0540e485119d4826d1d
Our column Password (conv to numbers) needs to read this value and split the string into individual characters, it then converts them into numbers using
Character Mapping
⁠
. The rest of the process is identical to
Simple Security
⁠
.
Importantly, to Decrypt, we use the cached Salt, and do not regenerate a new salt until the next round of Encryption.


⁠
💡 Click the gray buttons for definitions.

⁠

Let’s see this in action!

So we’ve run through the technical “how to”, but I thought it could be fun to see how this all comes together in a real-life app.
I’ve designed a company wiki to showcase how encryption could be integrated into a real application. In this demo, a team of users can contribute to a shared knowledge repository. Coda is just amazing for this purpose!
The cool trick in this implementation is that encryption is used to provide an additional layer of access control. Users can choose to make certain items confidential, sharing them with only a subset of other users. To enforce this, items are encrypted and require a password to access.
⁠
WikiVault
This team knowledgebase supports both shared and private content.
⁠


Gallery
Share
 
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.