Pages
Strong Security
This solution significantly improves on security strength.
Seeds, Salts and Hashes
The main weakness in 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 . 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...
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
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:
💡 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 . The rest of the process is identical to .
Importantly, to Decrypt, we use the cached Salt, and do not regenerate a new salt until the next round of Encryption.
ᴡʜᴀᴛ’s 
Hashing ?
Hashing
ᴅᴇғɪɴᴇ Salting ғᴏʀ ᴍᴇ?
Salting
ᴅᴏ Seeds NEED ᴡᴀᴛᴇʀ ?
Seeds
ᴡʜᴀᴛ ɪs SHA512 ?
SHA512
💡 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.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.