Can you keep a secret?

Breaching Simple Security

I did tell you it wasn't secure, right? 馃
Complexity, an illusion of security
In encryption, complexity can give us a false sense of security. In the previous example, I mentioned the possibility of patterns emerging from the technique, but I鈥檓 sure when you looked at the encrypted text, those patterns were not at all obvious, so perhaps you didn鈥檛 feel like there was anything to be concerned about.
The effort required to crack those patterns looks like the realm of savant mathematicians and quantum computing geniuses. And didn鈥檛 you read somewhere that your clever 8-digit Pa$$W0Rd would take like 1000 years to crack??
I feel it鈥檚 important to help give an accurate sense of how flimsy security can be that perhaps at first glance looked secure.
Oftentimes we hear about the massive computing resources needed to churn through billions of possible password combinations and that makes us feel secure, however we mustn鈥檛 forget the enormous role that the 鈥渉uman element鈥 contributes towards reducing security.

With the previous demo, if a user鈥檚 Password was shorter than their Secret, we repeated the password鈥檚 characters until we had enough to pair with the characters in their Secret.
For long secrets, the password could be repeated many times, creating patterns which when paired with the predictability of human behavior, opens up an enormous vulnerability.

Let鈥檚 switch hats for a moment, and start to think like a hacker

In cybersecurity,
we know that it鈥檚 very important
not to divulge your password.
What may be unclear
is that with Simple Security,
it鈥檚 just as important
to not divulge the Secret itself.
Even a small part of it.

For each character:
+ Password
= Encrypted
Remember how we generated the encrypted text?
First we converted the Secret and the Password into arrays of numbers based on each character鈥檚 Index in .
Next, we added each pair of numbers together, creating an array of Summed numbers.
Finally, we converted the Summed numbers back into characters to produce the final, encrypted Ciphertext.
What if, instead of guessing the Password, we tried to guess the Secret?

For each character:
- Secret
= Password
Let鈥檚 think about how that鈥檇 work
The opposite of an addition is a subtraction, so let鈥檚 see what happens if we were to reverse the above calculations, starting with the encrypted text because as a hacker that鈥檚 all that鈥檚 available to us in this doc.
Let鈥檚 take the encrypted Ciphertext and break it up into characters.
Next, let鈥檚 guess the Secret, break it up into characters
Convert both into numbers, and subtract the Secret from the Encrypted Text.
We鈥檇 end up with the user鈥檚 Password!
Step By Step Guide
Let鈥檚 run through that in a bit more detail, and see how we go.

Step #1. Let鈥檚 make an educated guess...
Encrypted Text. GdQ[>(3Q!p/??5NZN>0\edi>\+ap8@],=~ju}-/cs
Guessed Secret. Username
(we'll focus on the orange text with the same number of chars as the word "Username" which we expect is the start of the user's Secret text)
Use these to walk through the steps 馃憞
Step 1
Let鈥檚 look at one of the secrets from , saved as 鈥Netflix Logins鈥.
If we put ourselves into our target鈥檚 shoes, let鈥檚 think what kind of info they鈥檇 store in an entry they鈥檝e titled 鈥Netflix Logins鈥. An educated guess would be that their secret could start with the word Username.
It鈥檚 just a guess, but considering we know they鈥檝e stored account login information, it鈥檚 at least a good place to start. If this didn鈥檛 work out, we could try Email or Netflix or Account and we鈥檇 probably get lucky pretty quickly.
1 of 1

Well that鈥檚 not ideal...
As you can see, even though the final ciphertext looked like total gibberish, using the password as the encryption key is a surefire way to get your information compromised.
I have a few ideas about how we can strengthen the security, so our next demo will run through those.
Want to print your doc?
This is not the way.
Try clicking the 鈰 next to your doc name or using a keyboard shortcut (
) instead.