1.6 Security and password control

Home > Class 1: Basics > 1.6 Security and password control

Introduction

Before we move on, some very basic security tips are in order. Right now you’re a pimply-faced hobbyist in your basement, but you might be working for a large organization next year, and be responsible for a security breach. Even sloppy hobbyists or contractors for a local hardware store website are targets for hackers (I have been hacked myself once, and, I am ashamed to say, it was because my password was “admin”. Learn from my mistakes, friends).

These tips are just a start: There is no guarantee that you won’t be hacked, but good security hygiene may make hackers move on to an easier target. You already know that you should ignore emails from your bank requesting that you click on a link, and other common scams. The following tips are things I have seen seasoned developers and teams do again and again, though, and which should be stopped.

Sharing passwords by email is a dead giveaway that you’re a beginner. In Ars Technica’s Sloppy security hygiene made Sony Pictures ripe for hacking, it is shown how in 2014, “Sony CEO Michael Lynton repeatedly receiving plaintext passwords in unencrypted e-mails for his and his family’s e-mail, banking, travel, and shopping accounts. The unencrypted e-mails were frequently sent by executive assistant David Diamond.” Unsurprisingly, Sony was hacked, and those very messages were made public by the hackers.

You clients will send you emails with such instructions as “password is ilovedogs123”. It is your responsibility to stop these bad practices in their tracks. We’ll see how to use encrypted emails later on, but that’s for geeks. If you must share passwords with non-technical people, do it in person if possible, explain the risks of bad passwords to them, and create your own accounts, with good security practices, where possible.

One account == one person

Whenever possible, each person who interacts with a system should have their own account. The first time you log into a system with someone else’s password, figure out how to make your own account and give yourself the same privileges. This will ensure that when your colleague or client’s account gets hacked because they answered questions like “what’s the street you grew up on?”, and “who was your first love?”, logs will show you are not to blame.

Securing your computer

Full-disk encryption is available on any laptop, is turned off by default, and makes your computer about 5% slower. It’s worth it, though. Without full disk encryption, even if you protect your computer with a strong password, a thief can still plug your hard disk into another computer and read all its contents, including your private ssh key.

If you have Mac OS X, you can go to System preferences > Security and privacy > FileVault, and turn on FileVault. You will be given a long recovery key (if you trust Apple, you can store a copy of your recovery key there), and be warned that if you forget your password and your recovery key, your data is lost forever. This is exactly what you want. This is one password you do not want to forget, though.

Avoiding passwords where you can

Public-private ssh key pairs, which we saw in a previous lesson, are preferable to passwords in all cases. Some sites offer “Log in with Google”, or “Log in with GitHub”. This is preferable to reusing passwords, but it might be even better to have different accounts entirely.

Keep in mind also that anyone with access to your email account can simply “request a new password” or use the “forgot my password” option to have a login link to any website sent to your email address. If you don’t want to bother remembering complicated passwords to dozens of sites, you can make a habit of requesting a new one to be sent your email.

Whether or not you use this technique, it is vital to keep access to your email account very secure (you might want to use two-step authentication if you are on Gmail—see below).

Managing solid, unique passwords

When asked to create a password, all of us tend to cringe. It’s hard for us to come up with good, unique passwords.

Websites are periodically hacked, and, unbelievably, some store passwords with weak or even non-existing encryption. In 2013, Ars Technica reported in How an epic blunder by Adobe could strengthen hand of password crackers that Adobe had stored users’ passwords with inadequate encryption. These types of hacks can make you vulnerable if you reuse the same password on several services. But these hacks also provide an insight on the passwords people tend to choose. In 2008, for instance, What’s My Pass published The Top 500 Worst Passwords of All Time. Imagine for one minute how easy it would be for a beginner hacker to take the list of Abode’s hacked accounts, on one of links on Hacker News, find not the 500 most common but perhaps the 5000 most common, and try them all on your account or servers. This can be automated.

With an SSH key pair, this is not a problem. But most people need to manage dozens of strong, unique passwords. This poses two challenges:

Challenge #1: finding a password. The only way to reliably think of passwords that no one else is using, is to use a random generated password. LastPass provides a tool to generate random passwords which can be useful. If you are now sold on the command line, you can type openssl rand -base64 32 to generate a strong random password like u9kgLTf+xsPyAi0iym1TPwjbBvB6YHFNYCfGntNCPAI=.
Challenge #2: storing your passwords. Do not keep a text file with your passwords on your computer! There are tools to manage passwords, for example KeePass and LastPass.

If you are more of a command line geek, you can use Password Store, like me. There are great instructions on the project page, but it requires that you have a GPG key, which is described in more detail below.

If you are thinking, isn’t all of this overkill?, then consider one more hack, this one occurred in April 2015: TV5 Monde, a widely-respected international television network, had all their services hacked for several hours. The French Prime Minister even intervened.

What do you think their YouTube password was? Are you sitting down? According the Ars Technica (I love that site!), in the article Hacked French TV network admits “blunder” that exposed YouTube password, it was lemotdepassedeyoutube (this means theyoutubepassword). Not only that, someone printed it on a piece of paper, taped it to the wall, and broadcast it on TV. You can see a screenshot here:

OK, a lot of things went wrong here. As a technical person in an organization or working for yourself, your job is to prevent them. Starting now:

No more non-random passwords: always use a password generator.
No more printing out passwords: use a password management program.
Educate your staff with the sad stories of Adobe, Sony, and TV5 Monde.

In another great Ars Technica article, Anonymous speaks: the inside story of the HBGary hack, published in 2011, we learn that the the top guys at HBGary had very weak passwords and were using sloppy technology, which led to breach.

HBGary is an internet security company! If you stay in the field of computers, your career will probably take off; now is the time to think about these things, before it’s too late.

Security questions are passwords: don’t give real answers.

Many sites ask you to fill in security questions like “What was the name of your first love?”, and so on. The idea is that if you forget your password, you can answer these questions to recover it. The problem with that is that I can figure out the answers to all these security questions just by following you on social media. The name of your first love is a password, just like any other password. (My first love was EAFGswUVpzQI3zt6d0VetDMQgk0). Like any other password, store these in your password storage application.

In 2014, several celebrities’ Apple accounts were hacked in what Ars Technica describes in the article Apple confirms celebrities’ accounts breached in “highly targeted” attack.

Answers to celebrities’ security questions can be found on their Wikipedia page, so it’s not surprising that they were hacked. You yourself might be celebrity programmer one day with your Wikipedia page, so don’t use real answers to these questions!

Two-step authentication

So you have dozens of accounts on several sites, all with hyper-secure passwords. Still, anyone with access to your Gmail account can get password reset links to any of these sites. If your Gmail password is internet, you will still wind up looking like a fool. Even if your Gmail password is strong, I still recommend using two-step authentication. When this is enabled, Google (or any other system which uses it), will require your password plus another means of identification, especially if unusual behaviour is detected.

Google’s two-step authentication involves sending a numeric code to your telephone number, either as a recorded message or a text message. It takes a few minutes to set up here and is highly recommended.

Securing your SSH key

Recall in a previous lesson, we set up an SSH public private key pair to communicate between your laptop and a remote computer.

Now that you have set up full-disk encryption (see above; if you haven’t done it yet do it now), it is a bit more complex for someone to steal your private ssh key. It’s still plausible, though, for a hacker to gain access to it.

The solution is to provide a password for your SSH key itself.

core@core-01 ~ $ ssh-keygen -p

This command will prompt you for a password for your SSH key. Make sure you store it somewhere safe; if you lose it your SSH key will be worthless.

Next, you’ll want to register the passphrase to make sure you don’t need to enter it every time you use your key. Enter the following commands to do so:

core@core-01 ~ $ eval $(ssh-agent)
Agent pid 2072
core@core-01 ~ $ ssh-add
core@core-01 ~ $ Enter passphrase for /home/core/.ssh/id_rsa:
Identity added: /home/core/.ssh/id_rsa (/home/core/.ssh/id_rsa)

Now, your SSH key password will be requested only when needed, not every time you use it.

GPG keys: like SSH keys but for email

GPG keys allow you to encrypt messages between two people. Think of GPG keys like SSH keys but for email. It’s also used for other stuff (for example the Password Store application), but mainly email.

If the people at Sony had made better use of GPG, they might not have been hacked so badly.

CoreOS comes with GPG already installed. Let’s generate a GPG key.

core@core-01 ~ $ gpg --gen-key

The above will ask a bunch of questions; the defaults are OK. Enter your real name and email address. When you’re done, you will be asked for a passphrase:

┌─────────────────────────────────────────────────────┐
│ Enter passphrase                                    │
│                                                     │
│                                                     │
│ Passphrase ________________________________________ │
│                                                     │
│       <OK>                             <Cancel>     │
└─────────────────────────────────────────────────────┘

If you are using the command-line Password Store to store your passwords, keep in mind that it uses GPG, so store your GPG password elsewhere; if you forget it, your GPG key is useless.

It takes several minutes and computing power to generate a robust GPG key. You also need to generate entropy (chaos), or else the system will refuse to generate a key pair. The best way I found to generate chaos was to open another terminal window, log onto CoreOS, and type: cat /dev/urandom. I’m not sure what that does but it looks impressive and takes a lot of system resources. Close that window when the key generation is complete.

OK, now you have a GPG key pair, but anyone can generate a GPG key pair for your email address.

There are two important things to do with you key. The first is to share it. To do that you need to figure out your key’s identity. Type the following:

core@core-01 ~ $ gpg --list-keys
/home/core/.gnupg/pubring.gpg
-----------------------------
pub   2048R/C96EAC08 2015-05-04
uid       [ultimate] Albert Albala <albert@example.com>
sub   2048R/A2ECA4C7 2015-05-04

In the above case, the key’s identity is C96EAC08. You can now publish your public key for the world to see (which is a good thing):

gpg --send-key C96EAC08
gpg: sending key C96EAC08 to hkp server keys.gnupg.net

OK, so your key is now public. The problem is that anyone can claim to be you, and upload a key with your email address and name.

The second important thing, therefore, is to establish your key as your own. The easiest way to do that is to share your fingerprint through a means other than unencrypted email (on the phone, on your business card, on your https-encrypted website, in person). To get your fingerprint, type the following, using your own key’s ID.

gpg --fingerprint C96EAC08

There is an interesting concept known as the web of trust which ranks the validity of keys based on how many trusted people trust them. For example, you can tell GPG that you trust a particular person to be whom they claim to be. If that person, in turn, trusts someone else, it is more likely that that person will be trustworthy. Although I love this concept, we will use GPG keys the easy way, by confirming their fingerprints.

So, here is a typical scenario where two developers using GPG keys can communicate. Let’s say two developers are communicating via chat:

Developer 1: I have a password to send you.

Developer 2: Great, my GPG fingerprint is 38DB BAC3 6BB2 184A 87DF 112A 540C 816E C96B CC08, what’s yours?

Developer 1: Sorry to be a stickler, but this communication can be intercepted; someone might have intercepted your fingerprint and substituted a fake one instead. I’d like to confirm this over the phone.

Developer 2: OK, I’ll call you now.

At this point the correspondents will exchange their GPG fingerprints over the phone, then developer 1 can send developer 2 an GPG-encrypted message by email, chat, or any other mechanism.

Once two people know and trust each other’s GPG key fingerprint, it is no longer necessary to trust the means of communication: the message is encrypted in such a way as to guarantee it comes from whom it says it; and it is guaranteed to only be decryptable by the recipient.

Sending a GPG-encrypted message

To send or to receive a GPG-encrypted message, you need to download your correspondent’s key. To search keys claiming to belong to your correspondent, type:

gpg --search-keys correspondent@example.com

Download the keys that claim to match, then use gpg --list-keys and gpg --fingerprint to make sure the key fingerprint matches. Don’t forget, get someone’s fingerprint in person or on the phone, not by email (email can be intercepted).

Your correspondent also needs your public key. Once each person has the other’s key, it is possible to encrypt messages and send them by email:

Your message can then not be intercepted en route (it is gibberish).
Your message cannot be sent to another recipient (they can’t open it).
Your message cannot be exchanged for another encrypted message from someone else (you’ll be notified of its sender when you decrypt).

Let’s say your password is “lemotdepasseyoutube” and you want to send it via GPG to your recipient:

echo 'Hi, the password is lemotdepasseyoutube' | gpg -a --encrypt -r correspondent@example.com

You will be warned that the fingerprint is not trusted:

gpg: 02BFF027: There is no assurance this key belongs to the named user

pub  2048R/02BFF027 2014-10-04 John Doe <correspondent@example.com>
 Primary key fingerprint: 1C58 E195 087B C561 2AEA  35BB 0C0F 72CF 410A 4C4A
      Subkey fingerprint: C8D1 E651 1995 003E 5D11  F3CC A420 47F3 02BF F027

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

If you are certain that the fingerprint matches, type y. The result will be something like:

Send that to your correspondent by whatever means you choose.

Receiving a GPG-encrypted message

If you get a message that looks like the above, start by putting it in a plain text file called, for example, message.txt, accessible in your CoreOS VM, then type:

core@core-01 ~ $ gpg --decrypt ~/share/message.txt

You may need to unlock your key using the passphrase you set for it; then you will see something like:

gpg: encrypted with 2048-bit RSA key, ID 02BFF027, created 2014-10-04
      "John Doe <sender@example.com>"
Hi, the password is lemotdepasseyoutube

You can delete message.txt when you are done.

This has been a very simple introduction to using GPG on the command line. If you want to implement it across your organization, wait until a security breach actually occurs (otherwise no one will be interested), then you can use the email application Thunderbird which provides GUI key management, and can encrypt all messages automatically through the Enigmail extension. This might take one person about one week to research and implement in a small organization.

Consider using a VPN

A virtual private network (VPN) makes traffic between your computer and a (presumably) trusted exit point encrypted. The traffic between that exit point and the requested resource flows through the regular internet. This has many uses:

If you are in a country which bans certain content, you can use a VPN in another country to access that content.
If certain websites are inaccessible in your location due to licensing restrictions, you can use a VPN with an exit point in the location where your desired content is available.
If you don’t want your internet habits to be logged by your internet service provider, going through a VPN encrypts everything (VPN providers normally don’t log anything).
If you are using an untrusted WiFi network, all your traffic can be intercepted by anyone with a laptop. Using a VPN makes that traffic less meaningful because it’s encrypted.

Many organizations offer VPN access to their staff (often accessible by two-step authentication). If you are a real geek you can set up your own VPN, but a commercial VPN service can be a good choice for most people. In 2012, LifeHacker published an interesting article, Why You Should Start Using a VPN, with some suggested providers.

Backups

You will need two types of backups:

Local backups to an external disk. Mac OS’s built-in Time Machine has worked for me. Make sure you format your external disk as encrypted, with a strong password; store your password somewhere safe but not on your own computer (duh!).
Remote backups. Several companies offer this service, among them Backblaze. If you do you use these services, make sure that all your data is encrypted at the source; you should also a strong password to make sure even the backup company can’t decrypt your data. Store that password somewhere safe.

Drills

Determine how many months of work you can afford to lose, then, in your schedule (it could be every few months), take 30 minutes to simulate a complete loss of data. Locate backups (local and remote) of sample data, and make sure you can actually restore it. I myself lost close to three months of data because my online backup provider, Mozy, was no longer backing up my data. I oulined on my blog post Restoring Mozy backups has been very arduous how I almost lost everything because of a glitch with Mozy. It turned out they were helpful and my data was restored. However much I would like to blame Mozy, it was my own fault because I had neglected periodic drills.

Air gap

Anything connected to your computer can be hacked, including your external backup. I recommend unplugging all external drives when not in use. You might also want to carry around an encrypted USB key which contains your private keys, and a backup of your encrypted password database.

Not having these devices directly plugged into your computer, which itself if on the internet, is known as an air gap. The more air between devices, the better.

You should also disconnect your computer from the internet when you are not using it.

Use well-known open-source software and keep it up-to-date

Remember HBGary, the security company which was hacked? It turns out that in addition to the boss using a sloppy six-character password, their own website was built on a crappy custom Content Management System (CMSs are software like Drupal or Wordpress–we’ll get into Drupal later on in this course) that had two main flaws:

User passwords were weakly-encrypted, and weren’t using salt. When a CMS encrypts passwords without salt, every single instance of, say “lemotdepasseyoutube”, is encrypted exactly the same way. It doesn’t take a genius to figure out the most widely-used password in the system, then cross-check it with the list of 500 most widely-used passwords I mentioned above.
It had an SQL injection weakness. The site had a page http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27; the CMS inserted 27 into a database request like SELECT * FROM pages WHERE id='27'. The problem was that the parameters were not sanitized, meaning that all the hackers needed to was to substitute 27 for something like 1'; SELECT * FROM 'users, and the poorly-coded CMS would run the query as SELECT * FROM pages WHERE id='1'; SELECT * FROM 'users'. This is how the renowned security firm HBGary was hacked.

Next time you hear a company saying they were hacked by “extremely sophisticated hackers”, most of the time the victim was sloppy. Any custom code you are managing was probably written by some intern with no clue as to proper security practices, and is now hiking across Asia.

I suggest using open-source software, not custom code. Open-source software is prone to security breaches as well, of course, but most widespread CMSs have a security team who fix reported issues. For example, in 2014, a highly critical flaw was found in the source code of Drupal, allowing anyone to access any Drupal site as an administrator (talk about critical!). Even the mainstream press got interested: The Register published Drupalgeddon megaflaw raises questions over CMS bods’ crisis mgmt.

Open source software gives you a fighting chance, however. In the case of Drupal, for example, a security bulletin is issued every Wednesday; it is your responsibility to act on it, usually by upgrading your systems.

I’ll come back to the HBGary story, because it is a case study on what not do do, on so many levels. In addition to using crappy software and bad passwords, no one seemed to have heard of GPG keys. Once Anonymous hacked into HBGary servers, they still needed to get some information from Jussi Jaakonaho, Chief Security Specialist at Nokia. This time, no fancy hacking techniques were needed: Anonymous simply used a hacked email address to write to the Chief Security Specialist at Nokia. Their full exchange can be found on the Ars Technica article, but here is part of it. “Greg”, of course, is not Greg at all, but some hacker.

From: Greg
To: Jussi
Subject: need to ssh into rootkit
im in europe and need to ssh into the server. can you drop open up
firewall and allow ssh through port 59022 or something vague?
and is our root password still 88j4bb3rw0cky88 or did we change to
88Scr3am3r88 ?
thanks
-------------------------------------

From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
hi, do you have public ip? or should i just drop fw?
and it is w0cky - tho no remote root access allowed
-------------------------------------

From: Greg
To: Jussi
Subject: Re: need to ssh into rootkit
no i dont have the public ip with me at the moment because im ready
for a small meeting and im in a rush.
if anything just reset my password to changeme123 and give me public
ip and ill ssh in and reset my pw.
-------------------------------------

From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
ok,
it should now accept from anywhere to 47152 as ssh. i am doing
testing so that it works for sure.
your password is changeme123

i am online so just shoot me if you need something.

in europe, but not in finland? :-)

_jussi

It goes on. But you’ll agree this is a sad state of affairs. Starting right now, if you are ever tempted to use a dumb password like “changeme123” for any purpose under any circumstances, even a crisis, re-read this section.

If you have seen the movie Catch me if you can. It tells the true story of how, before the widespread use of computers, Frank Abagnale used social engineering to rob banks and pretend to be airline pilot, among other things.

Contingency plan

Even if you do all of the above, there is never any guarantee of not being hacked. That’s why you need a contingency plan: a written plan of what to do if you are hacked. Consider a worst-case scenario, with critical staff on vacation before a long week-end, for example. Write down a step-by-step scenario of everything that should be done, in which order, what to communicate to clients and stakeholders, in case you have an uncontained security breach like the one that hit TV5 Monde.

Before moving on:

Your laptop has full-disk encryption
Your SSH key is password protected
You have a password-management software
You have a GPG key
You have a contingency plan in case of a breach
You have a plan in place of what to do in case of worst-case scenario security breach or loss of data.