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”.
💡 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,
when you’re ready let’s play...
“What the heck are we talking about?!”
Your Lifelines —
Phone a Friend
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 SaltisNotBlank(), 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
Importantly, to Decrypt, we use the cached Salt, and do not regenerate a new salt until the next round of Encryption.
NEED ᴡᴀᴛᴇʀ ?
💡 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.