Welcome to befogs.

Return to the homepage

Title: Don't email me that.

TL:DR; In fear that this post may be a good deal to digest, I wanted to write a quick summary. If there is one lesson at this link, it's that you should never, ever email me (or anyone else) the user name and password to any service if you need to share it. In fact, don't email me anything that you would really hate to ever see in the hands of a hacker or criminal. Email, and most forms of instant messaging, are extremely insecure. If you need to email me something private, visit my Keybase.io profile, encrypt it there against my public key, and then email me the encrypted text which only I can decipher using my laptop's private key.

At 9magnets, we’re fortunate to work with dozens of amazing clients on a variety of fantastic ideas. Every day, we’re building extremely technical pieces of work that can often have significant security concerns, so while we don’t specialize in the development of security software specifically, we do have some experience working with sensitive data.

But undoubtedly, when working to protect private data, we often run into a significant problem which I’m sure you’ve had issue with as well. At some point in the project, be it for Apple IDs or Google credentials to upload a binary to the app stores or when integrating push notifications with Parse, it’s essential for us to exchange website credentials with the client.

And this sounds like a fairly simple step in the process. Just send over the credentials to us, and we can upload your app, add a cool new feature, help with support email, etc. But there’s a HUGE problem here, one of which I know I am personally guilty, and of which clients and friends often do to me without prompting, and that’s to send user name and password credentials over email.

I’m not going to tiptoe around this issue. This is a horrible idea, don’t ever do it. Yes, I know you’ve done it. I’ve done it before in the past. But let’s not try to defend it, it’s one of the biggest mistakes you can make if you’re in charge of any sort of sensitive account. DO NOT EMAIL ACCOUNT CREDENTIALS. Don’t instant message them, tweet them, IRC them, or any sort of other insecure message them. Just don’t do it. You’re about to, I know it, but let’s just stop and discuss why this is a bad idea.

We think of email as this personal message system, because it stands for electronic-mail. And for the most part our mail is private. It’s a serious crime to commit mail tampering, and fairly difficult. There’s only a single copy of any piece of mail, and physically tampering with it can be tough to do and often fairly obvious.

But in comparison, email is completely insecure. Your email account is guarded by a password, but as we’ve discussed on this blog, passwords in general tend to be very insecure in most situations. This is probably the password you share with a handful of services, maybe something like your Adobe account for Photoshop, your Snapchat, or Yahoo! account. If you’re an avid follower of my many links, you caught a pattern in the last sentence, in that, each of these services points to the same website that offers a list of different web services that have had user account databases compromised, and these leaks have lead to millions of user/password combinations that are readily available for potential hackers and criminals to try off of the bat, before even ever going ahead with other brute force methods. And these are only a handful of services that have been knowingly compromised, so now imagine how many services have been unknowingly compromised by a hacker or rouge employee. If you share your email password with another service, it’s probably been compromised, meaning that all of your email could be in possession of a criminal hacker.

But maybe you use a unique password for your email, that’s extremely complex and many characters long. You’re safe, right? No. Because emails are typically transfered between server and your computer/phone via an SSL certificate, but they’re often stored unencrypted on a server. This means that if your email host is insecure, or if they were targeted with an attack like Heartbleed, your email could be compromised in that way as well.

Even then, let’s say that we use a unique password and have an infallible email host that has never been the victim of a server compromise, and who was not effected by Heartbleed. Fantastic, we’re safe. That is, unless our cellphone or computer is stolen, because we probably use IMAP as a method of interchange, and our device may contain local copies of thousands of our emails, all containing these bad emails with our business Facebook account login, our bank account password, our tax information, and possibly worse. Think about everything you’ve ever sent from your personal email account. You know, the stuff you would NEVER want to ever have available out in the public, and then think about the last couple paragraphs and how every message in that account is vulnerable from a variety of different attack vectors. If that doesn’t scare the hell out of you, then you’ve probably been practicing pretty safe Internet security for the last few years and you’re a knowledgeable web researcher.

But what if you’re not a security researcher, who dedicates your life to contributing to Tor or Tails Linux? How do you improve your email security, especially when sending sensitive data like your corporate Applebee’s Perks™ account?

For my own clients, I recommend the following strategy to ensure that we’re able to ensure that your private account credentials are only available to you and I:

(Side note: PGP encryption has been reported to be secure enough for Edward Snowden. If this security tactic is strong enough for someone actively working to evade major world government bodies, it’s probably strong enough for our Facebook passwords or email credentials.)

What is Keybase.io? In short, it’s a startup dedicated to helping make strong encryption accessible to the masses. It holds a directory of PGP public keys that are audited against proofs that I’ve placed on my personal Twitter account, GitHub account, and even this website. So long as you trust that I’m really the person who controls those accounts, you can rest easy knowing that I’m the only person capable of decrypting messages signed using my public key on Keybase.io. But why are these keys so great?

Keybase.io works fantastically because it signs your message against my personal public key, which I have created on my laptop in a way in which messages encrypted against this key are only decryptable against the private key residing on my laptop (and as of today, also rests on Keybase.io servers for ease of use). Even if Keybase was compromised and my public key was leaked to a hacker, they’d have to brute force through the password on my public key, which is a 50 character random character password including numbers, letters, and symbols. Yeah, I just gave hackers a bit of an advantage on cracking that, but I’m still confident with the math to say that we’ll be OK for the foreseeable future with this. When I say foreseeable future here, I mean a million years so long as the hacker is just guessing at my password.

There are some potential pitfalls here. For example, if Keybase.io is compromised and malicious code is being run, data could be compromised so long as my work client or friend is using the web interface instead of the command-line interface, as some sort of key-logger could be installed. I anticipate most people to will be using the Keybase.io web interface when communicating with me, but I’m comfortable in telling them to use this system because it helps constrict the number of potential attack avenues down to a single system put together by a couple guys who have a strong background and who are open sourcing as much as they can. And if I can teach/convince someone to use the command-line interface over the web, it’s an extraordinary safety gain and the likelihood for compromise during exchange is incredibly minimal.

Again, this is only the strategy that I would encourage and use when exchanging personal and sensitive data with people who are entrusting me to keep this data from prying eyes. If Keybase.io is above your understanding, or if you don’t feel as if you can get everyone in your organization to follow these strategies, that’s alright! But start somewhere, and work toward improving your team’s capability to ensure privacy on the web. At minimum, provide a basic and simple salt on top of passwords in a way that is changed regularly and only known amongst people in charge of controlling credentials. Make sure that passwords are technically strong, and change them somewhat regularly (at least once a year). At least, discourage that your friends or customers send you passwords over digital means, and help them not open themselves up to hacking vulnerabilities.

(As a note, phone communications aren’t necessarily safer, but they do require a bit more equipment than a digital attack. My general rule is to generally assume that phone communications are only potentially compromised by large government bodies or people with Android phones. For the most part, I feel as if my conversations probably aren’t interesting enough for the NSA or similar bodies, so I don’t care much if they’re listening in most situations. This does depend upon your situation, so keep this in mind!)

As a note, this entire post is probably the most tinfoil thing I’ve posted here, and probably sounds like overkill for most. I understand and appreciate that, but know that my aim in what I’ve written above is to treat private information as absolutely sacred. I understand that this level of security is excessive and unnecessary for many potential applications, and I’m OK with that. But if you’re looking to transmit data that is sensitive and if it’s leak could potentially lead to significant problem or danger to disclosed parties, I encourage that you use the methods listed above or stronger. Remember there’s no going back once data has been leaked!