Security in Computing (Part 1)

In the 16th century, Mary, Queen of Scots, was plotting against Queen Elizabeth. She was planning to assassinate the queen. Mary communicated with her lackeys through a basic cipher – she simply replaced the letters of the alphabet with new symbols. Using this cipher, Mary communicated her treasonous wishes. Queen Elizabeth’s spymaster, Francis Walsingham, suspected Mary’s treacherous intentions and intercepted some of her messages. To decipher the messages, Francis had to use a technique known as frequency analysis. Basically, alphabetic languages tend to have a certain distribution of letters. For example, here is the frequency table for all of the letters in this paragraph:

This kind of distribution is consistent across the English language.

Using this technique, Francis noticed that one of Mary’s symbols occurred far more often than the others, so he figured that symbol must be representing “e”. Using frequency analysis, Francis was able to decipher Mary’s messages and prove her murderous plans. Mary was sentenced to death because she used a crappy cipher. Luckily, in the 21st century, we have more complex ciphers and forms of encryption. Unfortunately, these security measures aren’t used as often as they should be, and even when they are used, there’s a decent chance they’re not being used properly.


The basic mainstay of web security is the password. I know… you all hate passwords. They’re annoying, unwieldy, and often have bizarre requirements that make them damn near impossible to remember. They’re also completely necessary.

In today’s day and age, there are so many different softwares that require passwords that it’s virtually impossible to remember a unique password for all of them. Naturally, humans default to using the same password for everything. Picture your favorite password and all of the services you log into with that password… it’s a little bit scary. If any one of those services handles your password improperly, it could be compromised, giving anyone and everyone access to all of your accounts. One look at Plain Text Offenders will give you an idea how common it is for companies to completely ignore industry best-practices and put your passwords at risk.

It’s unreasonable to expect people to remember all of their passwords. So, what should you do? Personally, I use KeePassX, a wonderful piece of software that manages all of your passwords. I currently have 112 unique passwords for all sorts of things in there. For the most part, they’re at least 24 characters long with all random characters (for example YkAF.~hje\B5O6P2<vo*8[4n might be one of the passwords KeePassX generates).  I can’t remember a single one of them, but that’s fine!

Any time I need to log in to something, I open KeePassX, type in my master password, select the password I want to use, and then use the Auto-Type feature. KeePassX automatically types the username and password into the field, and I’m in. This process isn’t much harder than just typing a password in directly, and it’s infinitely more secure.

You may ask, “why not just save my passwords in a spreadsheet?” The answer is encryption. When I save new passwords into KeePassX and close it, those passwords are completely locked down with 256-bit AES encryption, so it’s practically impossible to get at the passwords without my master password. This is a great feature because it lets me comfortably store my password database in unsecure locations (though it’s still ill-advised). For example, I have my password database syncing with Nextcloud between my devices, so anytime I add or update a password, all of my devices receive the change.

KeePassX is one of many password management options out there. LastPass is another great option I’ve used in the past. Do your research and choose the password manager that’s right for you! I know it’s a huge pain in the ass to change all of your passwords and adjust your habits, but it’s also a pain in the ass dealing with identity theft… so balance your options.

One last thing to mention here is that if a site uses OpenID and gives you the option to log in with your Google or Facebook account, you should probably do that! If you think about it, Google and Facebook probably protect their users’ passwords better than the site you’re accessing. You should be wary of what data the site access from your account though… give sites the bare minimum they need to operate.

If you’re a web developer creating a user account system, please consider using OpenID! Security is extremely hard to get right, so in my opinion, it’s best left to the pros.

I suppose if you still insist on using one password for everything, at least make it tough to guess. Source:


You see that little green lock next to the URL at the top of this page? What that basically means is that any data that is transferred between my site and your device is encrypted. Imagine that this blog post was sent to you in the mail. Anyone who handled the letter could potentially open it up, read it, then send it along to you. Of course, this isn’t a huge deal for a simple blog post (in fact, it’d be nice to have more readers! :-). This gets to be a problem when you want to send data to me. Say I set up an online store and ask for your credit card details; the digits of your credit card have to reach my server somehow.

Using SSL encryption is similar to sending a lock box containing your letter to me. Only you and I have the key to the lockbox, so any nosey postman who wants to see your letter is out of luck. When you first visited my website, we securely exchanged keys, and now all of the data we exchange is kept safe inside a virtual lockbox!

Outside of protecting your data, SSL also ensures that the site you’re accessing is authentic. For instance, imagine Wells Fargo didn’t use SSL. In our letter analogy, Wells would send you a letter asking for your username and password. It looks authentic… hell it’s printed on Well Fargo letterhead. Unfortunately, there’s no way to prove that the return address where you’re sending your data is actually the bank. Luckily, you can be comfortable sending a letter with your bank login information out into the world if it’s placed inside a lockbox that only Wells Fargo has the key to. In simple terms, if a site uses SSL, you know that you’re actually connecting to them and not an imposter.

HTTPS Everywhere is a wonderful browser extension that forces sites to use SSL if they are able to. For web developers, LetsEncrypt has made a huge difference by acting as a free certificate authority. Removing the price tag from SSL is encouraging more and more sites to use encryption. With no cost associated with a certificate, there’s no real reason not to encrypt your site’s traffic!

Great for poor college students like me! Source (as of Feb 27th, 2017):

That’s all for now! My next post will be a little more technical and will focus on server-hardening.

Do you have a favorite password manager or another advantage to using SSL? Let us all know about it in the comments section below!


  • thesixthmoon

    February 28, 2017

    What do you mean when I first visited the website, we securely exchanged keys? I didn’t do that.

    • john

      February 28, 2017

      Great question! You didn’t exchange keys, but your browser did! Any time you visit a website with SSL, a certificate is served to you with the server’s key. This key has been cryptographically signed by a certificate authority (like LetsEncrypt), so you know that it is legitimate. Then, you exchange a new, secret, symmetric key with the server that you use to encrypt all of your traffic during the visit.

      You may ask, “how can we exchange a secret key over the Internet without other people seeing the key?” This question puzzled cryptographers and mathematicians for a long time, but in the 70’s, the Diffie-Hellman key exchange algorithm was created to transmit a secret key over a public channel.

      As a side note, SSL does depend on trusting a certificate authority. If you’re unsure of a site’s legitimacy, you can check its certificate by clicking the green lock next to the URL. On the certificate, you can see which certificate authority actually signed it. Some CA’s are shady, and some servers even self-sign certificates. That’s why any operating system that provides an SSL implementation includes a bunch of presumably trustworthy CA’s that are often audited. You can find which CA’s you trust in your “root certificate store”.

      Technically, a system of web security could be created that used asymmetric public key encryption, but the “web of trust” needed to practically use such a system would get quite unwieldy. Also, using symmetric keys allows for forward secrecy – that is, after the session is over and the keys are destroyed, nobody can go back and decrypt the data. Finally, decrypting data with symmetric algorithms is much faster.

      • thesixthmoon

        March 1, 2017

        Thanks for the good answer.

        So how do you as a website owner know that your CA’s are legitimate?

        The website visitor is of course trusting you with private information, if he’s buying something from you he is trusting that you will not steal his credit card number. So i would trust that you didn’t deliberately set up a bogus CA — why would you bother? You already have the data.

        But how do you know your CA’s are any good?

        Second question — you mean keys are temporary, only good for one session? Maybe I’m confusing this with a different cryptography protocol, but I thought sometimes people had one permanent public key that they published. This is something else, right?

        • john

          March 2, 2017

          As a website owner, you can choose whatever certificate authority you want. You can even act as your own CA if you’d like! The problem comes up when other people don’t trust your CA. My website’s certificate is signed by Let’s Encrypt. Most operating systems trust Let’s Encrypt by default, so most people connecting to my site trust that my site is indeed int main(). If you go to the Wells Fargo website, you can see their SSL certificate is signed by Symantec, another trustworthy company whose signature fingerprint is automatically trusted by your operating system.

          No doubt you’ve tried to navigate to a web page and your browser has presented a page like this:
          Untrusted Certificate

          In this case, the website’s SSL certificate was signed by a CA that the browser does not trust. Different browsers treat CA lists differently. For instance, Chrome only uses your operating system’s trusted CA list. If you’re on a Windows machine, Microsoft has maintained a list of trustworthy CA’s that have gone through a long, bureaucratic process to get on that list. Those CAs are also audited by Microsoft periodically. If you’d like to apply to be a Microsoft trusted CA, you can apply here!

          To answer your second question: yes, once you determine a site is trustworthy based on the certificate they present, the Diffie-Hellman algorithm is used to generate a one-time, symmetric session key. Symmetric key encryption simply means that the same key is used to encrypt and decrypt the data. Symmetric encryption algorithms operate very quickly.

          What you’re thinking of is asymmetric (public key) encryption. In that scheme, data that is encrypted with a public key (named such because it can be published) can only be decrypted by the private/secret key (named such because it must not ever become public). For example, my RSA public key is available on Facebook! When I receive an email from Facebook, it’s encrypted with my public key, so only I can decrypt it with my private key.

          Many encryption systems rely on public key encryption only to generate a shared, temporary session key. This allows for forward secrecy and both encryption and decryption can be done much faster. For instance, Tox is an open-source, audio/video chat system that provides end-to-end encryption. It relies on public key encryption for users to identify themselves, but once the users are streaming video from each other, using the asymmetric encryption method would cause far too much overhead. Instead, the application uses the public/private keys to exchange a one-time, symmetric session key that can encrypt and decrypt video data much faster. Then, after the session is over, the keys are discarded.

  • Garry

    April 22, 2017

    Good post!


Leave a Reply