Protecting Yourself Against Insecure Websites

There's a big problem with the internet right now: there are a large number of websites storing passwords insecurely. It seems there are lots of bad developers out there who don't know how to store passwords properly. That's fine, it's not really their fault, everyone had to learn at some point, and some people just haven't come across the information yet. Perhaps "bad" isn't the right word, "inexperienced" would be a better description. The life of a programmer is one of constant learning after all (if you're a decent programmer, the worst code you've ever seen is likely to be code you wrote a few years earlier).

But nowadays, there isn't room for inexperience when it comes to basic security. Many websites out there are storing passwords incorrectly, plain and simple. Big sites are not immune to such issues, there's the recent stories of both LinkedIn and, all of whom weren't storing their passwords properly, putting their users at risk. But do users even know they're at risk?

In the UK last Summer, there were a lot of tweets posted around about how Tesco, a supermarket chain, were not storing passwords properly. Does the average online grocery shopper really understand why it's bad that their password was emailed to them in plaintext? I highly doubt it.

As people who do understand why it's bad, what can we do? Sure, we could stop using such services in protest, but that's not always feasible. Having to use some websites is just a necessary evil, whether it's because we don't have a choice or simply out of convenience. But there is something you can do to protect yourself against sites storing your passwords incorrectly.

What's the impact to you if your password is leaked?

Let's say your password to a service is stolen, either through a site incorrectly storing passwords, or for some other reason. What's the impact to you?

  1. Someone will have access to that service's account, including all information you've stored with that service (email, address, security questions, etc).
  2. If you use the same password in other places, those accounts are all compromised and you've given them access to everything stored with those services too.

Basically, there's now an access point to other parts of your online presence, all of which can snowball into even more access and information to an attacker. Thankfully, there are some simple things you can do to mitigate such a scenario.

Protecting against sites that don't securely store your password.

It all comes down to personal account and password management. How do you manage your account information and passwords to mitigate the impact should you have an account with a company that couldn't care less about storing passwords properly? Here are some simple rules to follow,

  1. Never use the same password on more than one site. Ever.
  2. Always use the most complex password you can that fits with the site's password requirements.
  3. Never put information on your account that the company doesn't absolutely need. (Use fake information if it's "required" but they don't really need it. An online store doesn't need to know my date of birth, mother's maiden name, etc.)
  4. Regularly purge expired/irrelevant information from your accounts.
  5. (Optional) Use a different email address for every service you sign up for.

That's it. That's all there is to it. Let's look at these in more detail,

1. Never use the same password on more than one site.

"But I can't remember thousands of passwords!!!" you might cry. Well, that's kind of the point, you're not meant to remember them. You need to use a password manager. A password manager stores a list of all your usernames and passwords, that's protected by just one master password. So you only need to remember the one password.

"But what if someone gets the master password!!!" you might cry. Then someone would still need access to your password archive. The password archive is a strongly encrypted file that you keep on your computer, or on a keyring, etc. that's opened by the password manager. As long as you don't post it up online for the world to see, you should be good. Basically, an attacker would need two things; something you have (the password archive) , and something you know (the master password). In multi-factor authentication these things are referred to as a knowledge factor, and a possession factor.

There are some online services you can also use, such as LastPass. Other people swear by it, however I'm a little more paranoid. I don't use a service like LastPass simply because I will never trust a 3rd party with my passwords, even if they claim it's encrypted before being sent to their servers. This is just a personal preference, I encourage you to try LastPass out, research it's security, and make up your own mind.

I personally use KeePass. Using KeePass means no one else ever has access to my password file except me. I store it in a Git repository on my home server so I can always jump back to an older version and recover an older password if I need to (or if the file gets corrupted, etc). I'm basically abusing Git as a quick recovery solution. Obviously, I'm also backing up the file to several other places (encrypted of course). The point is, the file is never stored on a system that's not under my control without many extra levels of encryption on it. When it is encrypted, I'm the one doing the encryption, and I know exactly where the file is going and what the encryption keys are.

"What if I lose my password archive?" you might cry. That's what backups are for. Always always always backup important files. There's no excuse not to. If you lose your password archive and didn't have any backups, I have no sympathy for you I'm afraid. (Don't forget that sensitive backups should also be encrypted, and remember to always restore your backups regularly to make sure that they're actually working).

2. Always use the most complex password you can.

I've written before about how websites restrict your password choice in the name of security. Again, there's nothing we can do as users to stop this, since no one ever listens. So we're just going to have to work within the confines of what we're given.

Now that you're using a solution like KeePass, it doesn't matter what your passwords are, since you don't need to remember them. Some sites will have stupid rules, like "Don't use a % sign", but that won't matter any more. Most password managers come with a password generator tool as part of them. Simply enter the same rules that the website allows, and have the manager generate a password for you.

You can even just generate your own passwords on a command line too, just make sure that you use a good source of randomness/entropy,
cat /dev/urandom | tr -cd "[:graph:]" | head -c ${1:-100}; echo 

But the key is to always use as many different characters as the site will allow, and make the password as long as the site will allow. You will then always have the most secure password (assuming you generate a completely random one from the characters you're allowed to use). While the password might still be weak due to the insane password rules, it will at least be the best you can get.

3. Never put information on your account that the site doesn't absolutely need.

This is a big one. So many websites ask for information, which they quite simply don't need. For example, let's say I want to view a forum post on a gaming website. The site is forcing me to register an account first, where it wants my address, phone number and date of birth. There's no way in hell they need that information, so there's no way in hell I'm going to give them accurate information.

Lots of website require you to enter your birthday, and then will ask you to verify that information if you ever need to recover your account. Just think about how many people out there know your date of birth. There's no need for these websites to have that information, they're really just asking you to provide a piece of information that you can remember in order to verify your account at some point in the future. So put in random information and store it in KeePass, just like a password. I'll say it again,

Never provide information that a site doesn't absolutely need.

Some information is indeed required, for example, if you're ordering a book online, it's pretty reasonable that you need to provide your real address. But by the same token, it's completely unreasonable for that site to request your date of birth or mother's maiden name.

Security questions are a perfect example. So many accounts get broken into via the security questions route. People don't seem to think twice about providing all sorts of information to websites that really don't need that information. When a website asks "What was your mother's maiden name?", you should be thinking "None of your god damn business!". You're under no obligation to provide real information to websites in their security questions (Note that official government websites may be a different matter, since providing false information on those is usually a crime).

The problem with security questions is that the answers are password equivalent, yet they're usually stored in plaintext, and shown to you in plaintext whenever you go to edit them. If a site implements security questions, it's pretty much always the weakest authentication link. Every single time. So what can you do to help? Simple,

Never answer a security question honestly.

First of all, if you do answer it honestly, there's instantly quite a few people in the world who will know, or who can guess the answer. Second of all, if someone gets access to your account, they now probably have enough information to get into some other account based on your security question answers. A shopping website simply does not need to know the town I grew up in, or the name of my first pet.

Your answers to these questions should use the same process of generating random passwords as you do for your actual passwords. Store the answers in KeePass and you're all good. You might have to use non-special characters since some sites won't let you in security question answers.

4. Regularly purge expired/irrelevant information from your accounts.

What does this mean? Well, if you order something from a company, they'll likely keep your address and credit card on file so that they can fulfill your order. But once you've got your item, the site doesn't need to keep this information. Many sites will keep this information indefinitely. On a shopping website you purchased something from years ago, your account gets broken into and now someone has your address. They can use this information to get into other accounts, more recent ones that contain more useful information, etc.

Once the order has been completed, the information you provided has "expired" and is no longer relevant to the website. You should regularly remove this information from your online accounts. There are some sites I trust with this info, as they have a proven record of protecting my data, like Amazon for example. But others, not so much. As soon as I get my item, my address and credit card info are deleted. If I need to order from them again, then I'll just enter the information again.

You may find that companies don't provide an easy way to remove this information. In those cases, a letter or an email to them will usually get the job done.

5. Use a different email address for every account you sign up for.

The protection this gives is questionable, but I find this useful for reasons other than security, so I think it's at least worth mentioning.

You might be wondering how you could possible have so many email addresses, well, since I own my own domain, I can have anything@mydomain, so I simple create a new alias that routes to my real email address every time I sign up for something. For laziness sake, I have a catch-all email which I check very infrequently just in case I forget to set up an alias.

Not everyone has their own domain however, or you might be with a webhost which limits the number of email aliases you can have. If you use Gmail however, you can create special email addresses on-the-fly by using a + character. Basically, take your normal email address before the @, and you can add +<anything> to it and it will all route to your normal email address.

For example, if my gmail address was, then and, etc. would all route to my main inbox.

What does this provide in terms of security? Well, there are a few benefits to using this method,

  1. If a website leaks your email address to spammers, you can very easily add a filter to mark those emails as SPAM.
  2. If you receive an email claiming to be from a certain website, but which wasn't sent to your special alias, you can be sure it's a phishing attempt.
  3. If an online account is broken into, and your email grabbed, it will be useless for logging into any other website since you will be using a different email.

Point 3 warrants further thought. I claim that if one account is broken into, it won't provide the email/username for another online account. But if you use my method above of, etc. and the info is leaked, it's pretty obvious that your linkedin username would probably be, etc. So how can you get around this?

Something I've started doing is randomizing my username as well as my password (for websites where my username isn't tied to a profile URL... for example, having a random username for my Twitter account would be a bad idea. A random email on the other hand isn't much of an issue. I just store my random email (eg. in my KeePass archive, and I'm all good. If I need to verify that an email actually came from a specific site, I can just cross check it in KeePass. Although an easier method is to setup a rule to tag or move the mail to a specific folder, then if one doesn't get routed, you know it was an phishing mail.

Some may call this overkill, but I like being able to instantly see if an email came from the right place, and it's interesting to see which companies very obviously sell my email to marketers, since all the SPAM arrives to their unique alias.

How is all of this stuff going to actually help me?

Let's revisit the initial issue. A site you use gets hacked and your account information and password gets out (since the password was stored insecurely, the raw password is leaked), only now you've used the methods talked about above. What's the impact to you?

  1. Someone will have access to that service's account, including the limited information you've stored with that service.

That's it. You don't use the same password information anywhere else, and the information stored with your account is either random, or useless by itself. You can rest easy knowing the information the attacker has gained is essentially useless, since there's not massive amounts of information about you on the site, and the password isn't used for anything else. Also, since you used an unique email address, any SPAM or phishing emails can easily be avoided by just deleting the email alias, or routing it to the SPAM folder, and the attacker won't have a clue what your username/email is for other online accounts to even attempt to brute force a way in.

Obviously, the information you've stored on the compromised account has been leaked. But the only way to prevent that is for the site in question to have decent security. There's nothing you can do as a mere user to prevent such things.

So now you're as protected as you can be in your online life, even if you're dealing with a site that was built by inexperienced developers.

This is how I do it anyway. If you think I'm doing something wrong, or have a better way to protect yourself, let me know in the comments. After all, there's always something new to learn!

Afterthought: How did we get into this mess?

Is it really that every developer out there is bad? Well, no, of course not! Everyone is inexperienced in something. Some developers simply might not realise that they are storing password insecurely. If you think you're doing things right way, then you're not going to be searching for the right way to do things. Back in my early days of web development, I too was one of the bad developers who stored passwords in plaintext, purely because I didn't know any better.

The blame doesn't always lie with inexperienced developers however, it could well be that management don't want to spend time/money on something they see no benefit from, all too often, a developer's cries can go unheard. Unfortunately, that's business, we don't live in some fantasy land, this is the real world. Unless the company's hand is forced due to a data breach that's made public, they're not going to invest time and money in upgrading their security, since they'd rather spend the money on something that will make them more money. After all, most people don't change the locks on their house to the latest edition unless they have a break-in first.

Unfortunately, there's not much to do in cases like this. I started writing emails to sites that were obviously storing passwords incorrectly a few years ago, but nothing much ever happened. I'd get the occasional response saying "Thanks, we'll look into it." and then nothing ever happened, or on the other end of the scale I'd get threatened with a lawsuit for "hacking" their system (of which I obviously did nothing of the sort). I tried naming and shaming, but that didn't work either, since unless you get a lot of traction and your complaint goes viral, it's not going to make a difference. Not to mention that even if you do get a lot of traction, most end users don't really know why it's bad that passwords are stored in plaintext, and simply don't care.

I don't see an easy way out. Developers need to be taught about web security from the start, companies need to take security more seriously, and users need to understand that they're being put at risk and how to protect themselves. I guess in the end, we're all a little bit to blame.
Picture of Rich Adams.

Hi! I'm Rich. By day I work on cloud security at Indeed. By night I wear a cape and fight crime1. I'm on Twitter as @r_adams, and also used to write things on the PagerDuty blog.

1 probably not true

Additional Reading

Other articles/posts on similar subject matter (some of these may be more recent than this one),


A list of all the links that appear in this note,