The assumption he implicitly makes is that Google is not going to do anything malicious with his password, and has a secure enough network. If you take this assumption to be true, then his practice of emailing himself private information (over SSL, you can't access gmail without it), is reasonable.
Now if you want to take issue with his assumption, then go right ahead, but this is not an instance of Jeff Atwood misunderstanding how [eg]mail works.
The only reason for this would be that gmail -> gmail email doesn't leave their servers. However, I think it's irresponsible to suggest emailing oneself private information without explaining the caveat, because others might, say, do the same thing from their work email to their gmail account, and consequently send private data in the clear through random mail servers.
The GMail smtp service supports STARTTLS for incoming mail. It could very well be encrypted every single hop, from sending client to origin SMTP relay, from SMTP relay to GMail, and then from GMail to receiving IMAPS client.
The situation is a lot better than it was a handful of years ago. It's not quite the "don't ever do this!" it once was.
I am sure you can send email to GMail accounts with unencrypted SMTP. Just look at the incoming "Received" headers. If they do not contain a "cipher=" section, the connection was not encrypted.
I think what you mean is that GMail requires you to use https for their web interface.
I think what you mean is that GMail requires you to use https for their web interface.
gmail requires STARTTLS (or ssmtp) when an authenticated user submits outbound mail to them via SMTP (http://support.google.com/mail/bin/answer.py?hl=en&answe...), which is what he may have been mis-remembering. But, yes, it is incorrect that all mail sent to gmail.com addresses is TLS encrypted.
I feel kinda dirty sticking up for Jeff here - but that means if you _know_ your outbound mail always uses TLS when available, then maybe the security-in-transit concerns are eliminated. (I don't even know where I'd start trying to find out if all my possible ways of sending myself mail can be conclusively determined to be using TLS though.)
That would be a perfect counter argument, except the point mentioned in the article specifically related to getting passwords sent to you from other services.
$ telnet smtp.gmail.com 587
Trying 173.194.67.108...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP ea6sm27303065wib.5
HELO zwp
250 mx.google.com at your service
AUTH PLAIN [elided]
530 5.7.0 Must issue a STARTTLS command first. ea6sm27303065wib.5
$ telnet smtp.gmail.com 587
Trying 173.194.67.109...
Connected to gmail-smtp-msa.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP ff2sm43397967wib.9
HELO zwp
250 mx.google.com at your service
MAIL FROM:<test@example.com>
530 5.7.0 Must issue a STARTTLS command first. ff2sm43397967wib.9
Please try your test again on port 25, which is the port that server-to-server e-mail would use, as the post above yours said that it is possible to send e-mail to @gmail.com without using STARTTLS. This is, in fact, not only possible but required. Otherwise, @gmail.com would be inaccessible to any e-mail address using an MTA that does not support or is not configured for TLS.
"The assumption he implicitly makes is that Google is not going to do anything malicious with his password … "
Not necessarily "malicious" - I wonder if I could set up some adwords targeting keywords out of the popular passwords from the various lists of exposed passwords (Gawker, Sony, RockYou, etc), and attempt to social engineer people to give me "just" their passwords on my landing pages... I wonder if I had an unusual password, perhaps "incandescent-frog", in my email archive - could an advertiser "detect" that from me clicking an ad?
>The assumption he implicitly makes is that Google is not going to do anything malicious with his password, and has a secure enough network. If you take this assumption to be true, then his practice of emailing himself private information (over SSL, you can't access gmail without it), is reasonable.
No it's not. First, it's does have to be Google to do something malicious with your mail. An exploit, e.g XSS, could be found for Gmail any day --there were several in the past.
Second, was does "has a secure enough network" means? Does he only ever log on to Gmail from one network? The assumption of "secure enough network" and the words "hacker-proof" do no go together well.
It's a serious problem that this is currently the topvoted comment. It means that people are upvoting it because they agree with the sentiment, while not realizing that neither their nor slavak's opinion of Atwood's writing should be interesting to anyone. They shouldn't be interesting, because the opinion is on the one hand unsupported and is on the other hand based on the fundamental attribution error [1].
I say unsupported, because if anyone actually read the supposed supporting links, there would at least be a discussion concerning the first link in these comments. At least, I don't see how the contents of that post disqualifies Atwood. I don't think upvoters are actually reviewing the evidence to see if they agree with this reason for disliking Atwood.
Concerning the second link: if you write off Atwood based on occasional mistakes, you are committing the fundamental attribution error [1]: thinking that someone, and therefore all his writing, must be worthless, simply because he sometimes writes nonsense. Never forget that smart and interesting people also make mistakes.
Atwood takes the time to air and explain his ideas about programming. He's not a great writer or a deep thinker [2], but that doesn't matter: he is one of us thinking about what it means to be one of us. I find all of his thoughts interesting, if only to see how someone can come to a different conclusion based on the same premises. They are interesting even if I disagree and even if he is wrong, because it shines a light on how colleagues may think about things. For instance, the second link clearly warns me that I can never take for granted that someone understands what NP-completeness means and have to verify it. That makes even that post worthwhile.
You make a good point here but the fact remains that Jeff Atwood is a pseudo-expert, not a serious authority. His opinion shouldn't be trusted. About anything. Ever.
Each time I see some piece of writing from him, on a topic about which I am reasonably knowledgeable, I find some error. As a consequence, I tend to distrust anything from him on any topic about which I am not as familiar with.
Appeal to authority can be a perfectly valid inductive method when used as a statistical syllogism. It is only a fallacy in the realm of formal logic, where the truth or falsehood of a statement is independent of its source.
This is a common but quite annoying misconception. The following is a perfectly valid deduction:
1. Authority A is correct on matters in subject X p percect of the time.
2. A claims Y regarding a matter in subject X.
--> Therefore, Y is correct with probability p.
Jeff has never had any respect as a security professional, so it's lucky he's not one. At best, he raises a lot of awareness. At worst, his advice is misleading. He generally prints retractions when he finds he was wrong (and asks why he made the mistake), and that is often more informative than the original post.
He's popular because he's high volume, reasonable quality. In the days when his blog was at it's prime, there was a reasonable article to read every day.
Emailing yourself password-protected MS Office files isn't much secure either (unless something has changed in 2010 version). I've routinely cracked passwords for my users using freely available tools when they couldn't remember the password to unprotect an Excel workbook.
There is a known flaw that Office uses (used? I believe it's unfixed) the same RC4 stream for multiple versions of a document, which could be bad news if you used the same password for them and an attacker has old revisions, but even so, that may be hard to leverage if the doc in question is just a list of passwords. [nm, it's been fixed for a while. thanks, nhebb.]
There was two RC4 keystream reuse flaws in the Office binary formats. One involved salt reuse on save (an implementation bug) and was fixed in Office 2007. But there is still another one that can't be fixed without changing the file format. The original Office 2007 file formats used AES-ECB, but later switched to CBC in SP2.
In fairness, if you're e-mailing yourself, chances are it's not going out over the public internet at any point. In Gmail, it's likely not even going anywhere except straight into Google's database.
Absolutely. I use 1password, and it's hard to beat - encrypted, well organized (certainly better than searching Gmail for e-mails from myself!), and it syncs the encrypted store to Dropbox so I can have it on multiple computers.
That adds nothing but poorly contrived speculation.
Further, the general notion that email is predominately insecure is often wrong-
-TLS is used for most transports now.
-Email seldom transits through intermediaries (in the less connected world most had layers of smarthosts that were intermediate steps. Now almost all email is sent from origin organization directly to the destination organization, only diverging for highly secure intermediary like Erado).
I still wouldn't ever imagine emailing yourself passwords (email yourself an encrypted spreadsheet sure...to refute another comment, encryption in Office 2007+ is more than adequate) and the like, but just needed to address the hysterics about email.
gmail has been revamped so that China, with a fuck-ton of resources and desire, cannot get into it. they hired the NSA to help them. maybe it's no longer secure from the NSA, but it is from everyone else.
My objection was principally to the notion that the NSA is just some 3rd party security consultancy one calls up. Whether there was or was not a partnership that can or cannot be confirmed or denied, who knows, but lacking verifiable evidence, I'm just as likely to believe the NSA's advice was along the lines of "use a firewall and an IDS".
>My objection was principally to the notion that the NSA is just some 3rd party security consultancy one calls up.
When one is Google, it is. Not to mention that NSA very much cares for the trillions of information Google has to offer them and their continuing compliance.
In late 2009, China tried to get into Gmail. According to the forensics done at the time, they managed to compromise 2 accounts. And even then they only managed to read subject lines but not email contents for those accounts.
Google detected them, locked them out, identified over 20 other companies that had been compromised and notified all of them. Furthermore getting compromised was a wake-up call - they immediately took a lot of steps to improve their own security.
Note that this time Google's infrastructure was not targeted. Just end users and still Google tracked it down and notified people.
No system is perfect. I guarantee that Google knows this. But Gmail has a far better claim than any other email system I know of to claim to being able to beat Chinese hackers. (That said, I'm sure that China has not given up.)
But, these are just the incidents we know about. Plus, if the email isn't encrypted, many Google employees potentially have access, which throws the door very wide open.
Also, wasn't Google tracking everyone's movement everywhere, on Android? This is not a company I trust.
Have you thought of the operational costs of both encrypting email and still being able to support efficient searching of said email?
It really makes more sense to store unencrypted, and then secure access. The difficulty that motivated and well-prepared attackers have had in getting access demonstrates that they have done a very good job of securing access.
gmail was broken into by someone representing the chinese government. google fully admitted to this. this admittance did not seem to hurt their rep. they would probably admit to it if it had happened again.
google soon thereafter asked the nsa to help them out with security.
In bank street. You have dumped the money in bank street. yes.
The huge difference between Internet and the street- and by street i actually mean the safe of the bank, is the ease to steal from the Internet undetected.
Good luck stealing from the bank undetected. You see, they'd have to sneak in and still for example, 0.1cts from random accounts.
Easy electronically. Impossible physically.
The Internet is not nearly as well protected as the physical world AND it doesn't leave traces.
It's like making an analogy to everything + cars. It just doesn't make any sense. Sorry.
If you are using an e-mail client, you will be connecting to the gmail server using STARTTLS, so your e-mails will not be transferred over the public internet in plain text.
If you use the web client, everything is over HTTPS, and, like the gp stated, probably goes nowhere beyond the database, although merely a supposition.
If you're using a client your mail is probably delivered to a local smtp server, might bounce around for a while, and is then delivered to gmail server. You don't know that the last step uses ssl/tsl. Even if it does, what about the 3 other servers it touched? Was it logged somewhere? Did the anti-spam store it? Was it even removed from the spool at all?
My point is, email was not designed to be "secure" (i.e., secret), and is not though that way. Therefore ppl do not work very hard to secure email, and one little band-aid doesn't magically make the whole system "secure".
Your mail could turn up in a log file 5 years from now.
The packets are routed over the public Internet, but if you're using HTTPS, they'll look like encrypted garbage to anyone who doesn't have Google's SSL private key.
It's nowhere near as rare as you think. There are sub-CA certs issued to private companies all the time, allowing them to MITM any default browser config.
I have a feeling he was referring to e-mailing yourself with g-mail's web interface (which you connection to is, typically, SSL Encrypted). However, as the data is still stored unencrypted on google's servers so... yeah, still sucks.
Since email generally traverses the internet unencrypted, the consensus is that it's already insecure. There's little to be gained by encrypting it after the fact.
Besides that, what key would they encrypt it with? Something from your password? What do they do with email you get while not logged in? How do you build a search index? I'm actually building something similar, and even after a lot of effort, there's tons of corner cases that simply cannot be protected, so it seems a reasonable guess that gmail does nothing special to encrypt your data.
[edit to add that once you include oauth in the picture, I think the encryption story starts getting really fuzzy.]
Even if the data is stored encrypted, Google can always decrypt it on an as needed basis (since they serve ads based on the content of the email messages.)
It doesn't really matter. Any method of server-side encryption for email (and many other) systems as we currently understand them has inherent flaws.
The simple fact is that key material is accessible in RAM, and even if it weren't, the data still must be decrypted at some point, and once the server is compromised, you can likely capture that decrypted data.
That's not to say you shouldn't do it -- it helps prevent accidents like unwiped drives getting out, and might be a reasonably effective obfuscation against some attacks, but it just isn't secure in the same way that real end-to-end encryption can be.
One thing nobody is commenting on here is that the easiest way to avoid your passwords being stolen is actually just to ensure that nobody other than yourself knows that that they are passwords. Develop an estoteric system (don't use the word 'password' anywhere, don't store passwords with the full name of what they access, don't repeatedly access the same encrypted document [telling anyone looking for your secrets 'Decrypt this!']) and you are likely to put off all but someone ridiculously determined to target you.
Even better - don't put it online and don't even save it digitally if you can avoid it (is anyone that steals your wallet or burgles your house going to really bother trying to figure out what a hand-scribbled series of characters might mean?).
Jeff regularly "drops the ball" on most things. He blogs about what he is learning about, and not what he has mastered.
Remember him getting his knickers in a twist over AES ECB? Or more recently conflating secure hashes with hashes for other purposes? Or back-peddling on, well, everything?!
I love his writing and read every blog entry. But I shudder if we hold him up as an expert in recommending how to secure passwords and such!
The 'recently closed tabs' feature in recent browsers also makes closing your session more difficult. A few years ago it was considered good practice to close your window after checking your account. Now it is just a click in the browser to fully restore that window. Remember to 'Sign Out' all the time, 2 factor doesn't help in this case.
Atwood's solution is flawed because law enforcement only need to give correctly formed documents to Google to get all your passwords over a bunch of services.
Imagine someone using Hushmail in the same way. It should be a lot more secure. Hushmail uses strong encryption, but has in the past served specially crafted Java applications to the customer because they were cooperating with law enforcement.
Admittedly, if you have law enforcement after you then you need to start being a lot more careful with everything.
I hope you remember that Gmail scans your email for their stats and adverts and that your email storage is in NO WAY private. Go read the TOS, or the various websites explaining the TOS if it's easier.
More than that, many Google employees, for stats or project purposes may read them. More than that, you'd think gmail has never been broken into? Public info != reality.
Emailing yourself sensitive data unencrypted is simply dumb.
I have to agree with this. I hadn't read Jeff's post yet since, really, I haven't regularly read his stuff in probably two or three years, but I just did.
The only mention of emailing things to yourself is wholly contained in the following paragraph:
> The upside is that once you enable this, your email becomes extremely secure, to the point that you can (and I regularly do) email yourself highly sensitive data like passwords and logins to other sites you visit so you can easily retrieve them later.
To me, that's really dangerous advice. It relies on the assumption that you're only emailing things from your own gmail account, to your own gmail account. This means that the only transfer happens between you and Google over a secure HTTPS connection. Your data is transferred securely, stored on Google's servers, and securely transferred back to you when you request it.
At no point is this specific assumption pointed out, nor are the problems with it discussed.
First, although I can't think of a particular reason why gmail-to-gmail emails would be routed outside of Google's servers, that doesn't mean it doesn't happen. If someone could point a blog post discussing it, I would appreciate it.
Second, All bets are off if you use a separate provider. One example might be work email. If you're signed in to a work account already, you might be more inclined to just use that to toss an email at yourself for later. I've certainly done that before, even though I could sign into gmail from work. People could make the mistake of thinking he's saying "send an email to yourself from anywhere" which isn't correct. Incidentally, activating two-factor auth makes it more likely that someone would do work-to-home emailing since there's now an extra barrier to just logging into gmail.
Finally, this seems to rely on the assumption that you're only using the web client to access gmail. If you're using POP3 or IMAP to access your account, you could still be at risk, since I think (though admittedly I'm unsure since I only use the web interface) that these protocols aren't encrypted by default.
> At no point is this specific assumption pointed out, nor are the problems with it discussed.
To "email yourself" implies using the same service.
> If you're using POP3 or IMAP to access your account, you could still be at risk, since I think (though admittedly I'm unsure since I only use the web interface) that these protocols aren't encrypted by default.
Good to know. I did specify that I never used it, so my understanding could be flawed.
> To "email yourself" implies using the same service.
To you, but not necessarily to everyone. People do have multiple accounts (gmail, personal domain, work, even Facebook gives you an email address you can send things to), and it's really easy to conflate "email yourself" with "send an email to your account", or even to abstract "sending an email to yourself is secure" to "email is secure".
My point was simply that if you make an argument about something as important as security, it's vital that you spell out the limitations to your advice. "Email yourself" is ambiguous enough that it needs a proper disclaimer.
Admittedly, the audience for Coding Horror is mostly people who know this stuff already, but it's certainly not limited to those people exclusively. I started reading his blog midway through college, and it's amazing to me, looking back now, just how naive I was about a lot of things back then.
I think it's required nowadays, or at least used by default, but less than a couple years ago HTTPS was a setting you had to manually enable and before that wasn't offered at all. Also HTTPS is only secure if you trust the cert companies, which I don't after the multiple fake certs issued last year (with at least one *.google.com presumably issued to Iran). The best way to secure your sensitive emails has been the same since the 90s: PGP encryption. (The tradeoffs have also been known.)
This gives me an idea. A secure web notebook where you can record things that only you can get out. They will be encrypted on the server basically, and your password will be used to decrypt them. Also you will use SSL to post. Is there any vault like this that's freely accessible?
The problem with such a service is that there's no practical way to figure out whether they're reading your data on the sly. (Even if your data is technically being encrypted on the client side, there's nothing to stop them from slipping in some extra JS one day to start sending your encryption key to their server.)
Great idea in theory, however, I'd like to know how you search your emails on your smartphone while traveling when all of your mails are GPG-encrypted on the server.
Or do you carry your GPG key around on your smartphone?
This solution, while technically pure, does not work. Those of us that live in the Real World send our regards.
Gmail indexes messages, which makes it incredibly fast to find a note that I sent to myself. I also use it to remind myself about something important to eventually remember, but I can't work on it right now.
Now if you want to take issue with his assumption, then go right ahead, but this is not an instance of Jeff Atwood misunderstanding how [eg]mail works.