Creating Unique Email Addresses for Every Account

For about a year now, I have been creating unique email addresses for every account I have. I wanted to do this in order to reduce the risk of credential stuffing when one of the services I use is inevitably compromised, but I also needed something that was trivial to use and create unique addresses.

  1. Create a ProtonMail account and signed up for the Visionary level account, which is roughly $360 US/year. You could achieve the same thing with the Professional level account which is roughly $84 US/year.
  2. Register a new domain that only gets use for account signups. The main criteria for this should be something that is easy to remember and cheap, but otherwise any arbitrary domain name is fine.
  3. Connect the domain name to ProtonMail using the instructions here, and create a master account with that domain.
  4. Enable the catch-all feature for the domain using the instructions here, and select the master account for the catch-all recipient.

    The catch-all feature means that any email that is sent to an address that does not exist will be delivered to the catch-all address.

So now you can make up anyaddress@customdomain to use for accounts. I typically just use the name of the service. So if I’m signing up for a Spotify account, for example, I’m going to use spotify@customdomain. For Netflix, I’m going to use netflix@customdomain. And so on.

Emails sent to those addresses will be delivered to your master account where you can receive them.

Occasionally, you may need to reply to one of these emails. In that case, create an address for the particular address you need to reply to, make your reply, and once whatever issue you need to resolve is resolved, delete that address (to free up the address for future use).

For example, if I needed to reply to an email sent to netflix@customdomain, I would create an account in my customdomain called netflix. Then I’d make my reply and wait for any follow-up, etc. Once my support or billing issue was resolved, I’d archive those email messages and then delete the netflix address.

Now With HSTS

Occasionally I use services like SSL Labs to ensure everything is set up and working correctly on this server. One of the things that SSL Labs and others were dinging me for was lack of HTTP Strict Transport Security.

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should interact with it using only secure HTTPS connections, and never via the insecure HTTP protocol.

This turned out to be fairly trivial to implement. I’m using Apache, so I just had to update the Virtual Host file to add a single header:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Initially I tested with a shorter period of time just to ensure there weren’t any HTTP-only issues that I had to deal with. After being satisfied that they weren’t, I set the expiration time to one non-leap year in seconds.

Google Is Tracking Your (and My) Purchases

Interesting. Google is harvesting information from Gmail about any purchases you make and then compiling them into a Purchases page.

Checking out my Purchases page, it looks like Google has a fairly accurate record of all my Amazon, Steam and (not surprising) Google Play purchases.

Honestly, I’m not sure why Google does things like this. It adds very little value to end users, Google claims they’re not using this information to target ads, and I imagine most people are going to find this creepy AF.

Stop Asking Security Questions

I typically see one or both of these pieces of advice regarding the ubiquitous “security questions”:

1. Users should go to absurd lengths to hide personal details about themselves online to make it impossible for hackers to guess the answers to security questions.

A company might ask you to use your favorite movie as a security question? Better not let anybody know about your affinity for Italian horror films.

2. Users should never answer security questions truthfully. Treat them for what they (sort of) are, secondary passwords and use arbitrary answers to them.

Like so much of infosec, these pieces of advice treat the user as the problem rather than the convoluted security mechanisms they are forced to endure. The best advice is, simply,

3. Stop asking users security questions.

Security questions add additional difficulty to accessing accounts without adding any additional security. At best, they force users to create and track multiple pseudo-passwords. At worst (which I suspect happens routinely), they trick users into tying easily discoverable personal information to their accounts, which makes targeted hacking attempts much more likely to succeed.

Just stop using them.