I have a Yubico FIDO U2F. It works with tons of sites and services but I usually opt to using 2FA one-time codes since it's quicker (I can pull up the Authy client on my desktop or phone). My key doesn't always work in every computer I have. It works out of the box in Linux but Windows needs to download drivers and the time that takes is more than just doing a one-time code. It is helpful to have, I only need either my keychain or my phone to get into my most important sites and services.
"Google says it supports any keys approved by the FIDO Alliance, a group that manages identity and authentication protocols." -- from the article.
This includes USB and Bluetooth LE devices. I'm still getting up to speed on technology, but prefer very near-field chips with a range of < 10cm (4 in), and if possible, < 1cm. Making unintentional / accidental detections, or snooping, as difficult as possible would be a bonus.
(It's possible that interactive timing might be a mechanism: a nanosecond-scale time resolution works out to about 10 cm.)
One of my operating assumptions is that extant systems really aren't suficient. That's going to require some changes and establishment of novel standards. And that means that organisations having sufficient heft to promote and establish such standards need to be involved. As much as I don't trust the current Four Horsemen of the Apocalypse: Google, Amazon, Facebook, and Apple (and the various horse-pages: Microsoft, Oracle, IBM, etc.), they're almost certainly going to be involved. The US government, EU, and possibly interests in China, also.
And if you're thinking "but China?!!", remember that they've got their interests in secrets too, and might see a need for a secure and trusted system.
I've been using a (cheap $6) U2F token for a couple years now, but only on desktop, didn't want to spend the money on a NFC one. I'm thinking the feitian ePass one for $16.99 that has both NFC and USB would be good, at least until all computers switch to USB-c only.
Of course if you also want RSA key management on top of it your going to spend more money....
Are there any websites where it doesn't work? Looks like in the comments on Amazon this doesn't work for LastPass. I was looking at getting it instead of a Yubikey. I got their bluetooth/nfc key that Google recommends, but I don't have a bluetooth card on my desktop.
tl;dr: Yubikeys are $$ but really solid for USB and NFC; the Feitian is probably the best option for Bluetooth but YMMV there. Those are what I personally use.
(Note that Yubico recently announced a problem with their RSA key generation, which they're fixing, but that bug does not affect the security of the device when used as a FIDO authenticator as it is for Google/Github/Dropbox/Vanguard/etc.)
According to Yubico, the RSA vulnerability only affects the YubiKey 4 and "all YubiKey 4 products shipped by Yubico after June 6, 2017 (version 4.3.5 or higher) use" a new implementation that is secure from this.
To piggyback, I recently bought a couple NFC devices, Feitian ePass FIDO and a Fidesmo Yubikey NEO. I have searched around for information on developing and transferring apps to these devices, but thus far have been unsuccessful. Seems most of the resources are several years old, gpshell appears abandoned and won't compile properly on Ubuntu 16. Any pointers appreciated! I'd love to have PGP support on the Feitian.
Without saying whether it is a good trade, we can at least surely say that it is NOT "well-understood" by users, since the vast majority are not aware of making this trade at all.
I've always wondered why they don't offer the option for personal (gmail.com) users to pay for the service and opt out of monetization. I'd pay $5-10 per month for Google's services without me being the product.
At that price you could just get a Google Suite email. Of course at a quick glance it just says no advertisements, I'm not sure that they wont be monetizing your data some other way.
That's a good point. But currently there is no option to use my gmail.com address with G Suite, which I'd like to keep because of old accounts. I host my domain name email addresses with ProtonMail.
Cost, yes. Well understood? Not by the vast majority of the few billion Google users, who think it's perfectly normal for Google's service to just magically appear on the Internet without them having to fork over any cash.
Unusually secure? Wasn't Gmail among the first in pushing super insecure SMS password resets, which are still resulting in high profile account hijackings every single day?
That pledge ... seems to possibly be getting rolled back:
...However, court documents suggest that this could be temporary. A month after Google's announcement, the company quietly agreed (PDF) to settle a class-action lawsuit alleging that the targeted-advertising scanning was illegal wiretapping. That deal, in which a federal judge gave "preliminarily approval" (PDF) to on Thursday, binds Google for just three years....
Google claim, with some credibility, not to offer up personal information via email. Instead, ads are placed, but user identification is not provided. (The extent to which this information can be de-anonymised is something I'd like to see.)
But the data remain, on Google's servers, encrypted to keys Google itself has, and susceptible to exfiltration by various account attacks.
The problems of the Podesta attack mentioned in the article are several. Google are addressing part, but not all, of that attack.
1. Podesta was sent a phishing message that was not detected and blocked entirely.
2. His multi-member email management team failed to appropriately respond to that message. This isn't a case of Podesta alone falling for this, he had help.
3. His password was obtained.
4. The password, and it alone, was sufficient to access Podesta's account.
5. Unusual access patterns were not detected and blocked by Google. (Google are actually fairly good at doing this -- to the extent I've been repeatedly locked out of accounts.)
6. Given account access, substantially all of Podesta's email was successfully copied to the attacker's systems.
7. That email was immediately readable to the attackers, as it was not encrypted to keys Podesta alone controlled (and independent of his already-compromised password).
That's seven points of failure, any one of which could have prevented the attack.
> 7. That email was immediately readable to the attackers, as it was not encrypted to keys Podesta alone controlled (and independent of his already-compromised password).
So it’s a flaw that you can access your email when you’re authenticated successfully?
There should be a second-stage, preferably device-only, decryption phase.
That is, the entire concept of "identity" is confounded out of a cluster of often only loosely-related concepts. Among them:
1. Who are you?
2. Should I trust you?
3. Did you do X?
4. Is X as you left it?
5. Can you (and ideally you alone) read X?
6. Should I allow you to do X?
7. Do I owe you / you owe me X?
8. Must I pay you (or seek permission) to use/do X?
9. Are you the same X as some other X' (in another place, time, system, ...)?
Accessing the email store (authentication) is not the same as being able to read email (decryption), or being able to say you sent a specific message and that it hasn't been changed (integrity).
Electronic / digital data formats violate many of the trust bases that have formed around material or personal data transfers. Paper, stamps, seals, institutional trust (that, say, the post office isn't opening, reading, and/or censoring mails), etc. It's an entirely different set of physics, if you will.
The rules have changed. Google are playing by the old rules. They are losing, and so are we.
And when your second key is compromised, will it be Google’s fault that they didn’t make you have a third key? Maybe you need a key for Authn and another for Authz and another for decrypting headers and another for decrypting bodies and another if you want to send.
I've considered a no-auth version. My general feeling is that it puts excessive reliance on integrity of the decryption key, but otherwise, yes, that is an option.
Flipped around, if website notifications were encrypted and posts were signed, there'd be little need for website authentication.
Search and history might require initial access to a message but otherwise creaate encrypted indices. Or could be handled fully client-side.
We will have to agree to disagree. I see no value to Gmail users to making them use a secondary key for their mail. If you’re this concerned with security, you won’t be using Gmail because you still have to trust them with all your plaintext at some point.
Not sure what you’re referring to with the website notifications and posts.
Search and history can only be handled client side if you are going to download your entire mailbox, something almost no one does anymore. Initially indexing is theoretically feasible but makes it essentially impossible to ever reindex to fix bugs or improve performance.
There's the option of reducing that exposure to a minimum limited extent. To the extent that this is auditable, verifiable, and based on well-established procedures, it may be an acceptable risk.
This includes encrypting unencrypted messages, after arrival, to the user's own key(s).
Keep in mind that data security consists of numerous elements:
* Access.
* Encryption-in-flight.
* Encryption-at-rest.
* Encryption-to-client.
* Rates of transfer or exfiltration. This has numerous elements, one of which I refer to as the Pennyworth limit. Bruce Wayne has a butler who is privy to Wayne's innermost secrets. But he is not also privy to the secrets of all of Gotham. And even at maximum data transmission rate, can only reveal a few hundred words a minute of information, on the order of a megabyte or so per day (in textual form). Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.
* An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally. Since reading information client-side requires transmission of that data in any regard, the information is already client-side. There are now microSD devices with capacity approaching or exceeding 1 TB and above. Storage itself is not a limitation.
Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.
I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.
> There's the option of reducing that exposure to a minimum limited extent. To the extent that this is auditable, verifiable, and based on well-established procedures, it may be an acceptable risk.
How would it ever be auditable or verifiable? You're talking about secret source code running in private data centers on inaccessible hardware. If you need auditability or verifiability, you cannot rely on GMail or any similar service.
> Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.
I'm not dismissive of that concern but I fail to see its relevance to the question of whether Google should add another key to everyone's account. You don't solve this problem by encrypting your mail unless you stop sending your mail through Google. In fact you don't even solve it that way because such a huge chunk of mail you send/receive will flow through Google anyway. You cannot solve the trust problem by adding another unverifiable layer of encryption. If you don't trust Google now, that shouldn't change if they tell you that they started encrypting with your public key at rest.
> An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally....Storage itself is not a limitation.
I disagree. I'm using ~10 GB of storage for Gmail. I don't want that space used for mail on my phone. Or my laptop for that matter, which has only ~36GB free at this point. I can't stick an SD card in my phone and if I could I wouldn't because it's slow.
> Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.
It really can't. If the index is encrypted, then it can't be updated with new entries. So the best you can do is generate an inverted index per email and send that to the client to combine into a real index. But at that point, don't even bother because the client can probably index each email locally more cheaply than it can stream it from the server.
Given that most people are now using web clients, pushing indexing responsibility onto the client isn't remotely feasible. Imagine you log in from a new browser and GMail tries to push GBs into your localstorage and then your browser churns for hours trying to build the index.
> I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.
I think that's overstating it, mostly because adding a second key does not eliminate the social engineering weakness (maybe it's reduced). But also because I don't think leaked emails constitute the end of democracy.
And the same government that wants to tap everything and subpoena email accounts with little cause is going to enforce that Google makes it difficult/impossible to do those things?
One question I have that the article didn't answer, can you set up multiple physical keys? Can I create a backup and store it in a bank safety deposit box? I believe the current Fido process let's you do so, but does the new advanced version?
Yes. You can have many keys associated, just as with normal Fido. I have five -- I keep one in each laptop, one on my keychain, and two securely stored. (For more information, if you look at the program page, it also specifically mentions keys, plural - https://landing.google.com/advancedprotection/ )
From earlier discussion, if I recall correctly, you'd have the option of creating a set of one-time passwords as well.
Details remain somewhat vague as to having multiple credentials, or managed accounts (though the corporate service -- Google Domains or whatever it's called, should allow an administrator some options).
I know the current 2-factor auth allows backup one time passwords, but it specifically says in the article that the advanced protection does not allow the one time passwords. I was just curious if the advanced protection also limited the number of hardware tokens you could have.
It may be harder to "recover your password", if you lost your second factor key, but the fact that it still is possible means Google employees (or a fraction of them) have a way into your account. I prefer services where this isn’t possible, even though that means the account is lost if I forget my password.
That doesn't mean an employee has access to your account. If you lose your USB dongle, you'll need to prove your ownership of your account, but that doesn't mean G employees will go in and look at your emails.
> that doesn't mean G employees will go in and look at your emails
There are two forms of this assurance.
The first is running into some guy at a party, or on an internet message board, who either works at Google or "knows a guy" who does, who then spends thirty or forty minutes semi-drunkenly rambling at you about how the security at Google is "military grade" and everything is "locked down" and they have some guy who used to run the Mossad in charge of internal security and he's the best guy ever and nothing or no one ever breaks in and that shit's a fortress. Trust the semi drunken ramblings of this guy you just met, your secrets are safe with the big G.
The second form of this assurance is only giving the third party indistinguishable encrypted blobs of data. They can look at them all they want, it doesn't mean anything to them. You don't need to trust anyone, let alone some guy you found on the Internet and transitively a few hundred anonymous computer programmer and IT janitors spread across the world.
Go figure, some people are more persuaded by the second argument. Even if you're reading this and you work at G and you know that the ex-Mossad security guys are digitally looking over your shoulder and you shake your fist at this screen muttering "you don't know how much we have it locked down here, clueless Hacker News commentator" you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security.
Email is a really dumb thing to put this to because 99.999% of the emails you receive will be sent by less paranoid people and 99.99% of the emails you send will be to less paranoid people.
Just get a pretty locked down Gmail account and use pen and paper or OTPs or GPG for things that actually need to be secure.
Exactly. Concrete example: The only two sources of Clinton emails being made public were
1) Emails disclosed as part of a legal discovery process that compelled Clinton to hand over the emails herself.
2) Copies of her emails acquired from a correspondent with a much-less-secure configuration of their Gmail account than Clinton's configuration of her private server.
Email is, by its nature, a distributed infosec problem.
For the average person in 2017, the threat of a breach of their email account is not that the contents of emails they sent or received will be published and used for nefarious purposes. Some celebrities, government officials and business people need to worry about that, but they're a tiny subset of the general email-using population.
The threat of a breach of the email account is that it's the key to everything else -- pretty much any other account, with any other service, is instantly accessible the moment you're in someone's email, because the email inbox is where credential-reset requests are sent.
> you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security.
There’s no such thing as zero trust for email unless you’re going to run your own server (even then it’s iffy because of communication with other untrusted servers).
By using a mail service, you have to trust the people running the service. Even if they pinky promise to immediately encrypt every message with your public key a never never never look at it, you cannot know that they aren’t secretly redirecting a copy to the NSA and publishing another copy on the novelty Twitter account @muninmails.
Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.
The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference.
... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email...The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though they advertised that they “can’t” read your email, what they meant was that they would choose not to.
This is also true. I think the particular threat I was replying to was "can employees, on a whim, go into stored e-mail and view it?" You're right that there's another possibility, which is that on a whim the employees will engineer a system such that they can view all the plaintext that flows into and out of your inbox.
There are maybe a few things that could be done to reduce your trust in "Honest Munin's Very Secure E-Mail Hosting and Used Cars", like, I could publish the code to the server and run it in SGX, allowing anyone in the world to use SGX attestation to verify* that the code running in SGX is the code that I publish, and that code could only initiate encrypted network connections with other mail servers. So even if I ran that in good faith and sat outside the SGX container listening to the network traffic, I'd still be getting a face-full of encrypted data.
This is still a "verify*" because maybe something is funky with SGX. You're not really trusting me now though, you're trusting Intel and the SGX TCB. Maybe that's worse? I don't know. I still think that's an improved proposition over trusting the honesty of system administrators to not grep your INBOX on a whim, though.
edit: I guess this also kind of breaks down because the story for TLS in SMTP land is kind of dire, so you could probably actively MITM the communication between the SGX blob and the outside and there's no practical way for anyone to know that this is going on. Maybe someone will fix that someday! Probably not though!
Employees looking on a whim is generally solved by encryption at rest with shared keys. You don’t need a unique key per user. You just need to make it really hard for the employee to get the key. Key per user doesn’t gain much except difficulty indexing for search. (I have no idea if Google encrypts email at rest, by the way.)
As for SGX, it doesn’t really solve for this problem. It would allow Google to verify what software is running, but with a Google-controlled network in between the server in question and the user, I’m fairly certain any assurances SGX could yield are gone. Google could publish their code publicly, allow users to request attestation, but send attestation requests to server A running the public code while serving the user’s email on server B running NSA-modified snooping code. And of course your email isn’t actually sitting on a single machine anyway. It’s probably stored redundantly on 3+ backend machines and served by any of thousands of front end machines. Verifying each of these would be infeasible even if technically possible. (I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here.)
Also attestation is for binaries. I doubt you could actually verify a source match.
> I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here.
There is magic you are missing. I don't want to be the person that glibly says "you should read more about this" and then vanishes, but because I don't have time to write out what the magic is, that's exactly what I'm going to do :(
The magic does allow users to verify that the software they're talking to is what it says. Specifically, it also allows users to set up an encrypted channel with the processor that is running the software that is attested, so you exactly can't do the attack you propose of shuttling attestation to one system and actual data to another.
The technology is pretty cool, you should check it out!
I don't want to glibly dismiss your comment either, but I fail to see how this helps users at all. From what I can tell, you're correct that the SGX connection can be structured such that attestation cannot be spoofed by sending the data request to a different service (assuming you trust Intel), but that doesn't really help end users.
1. Intel does not bill the technology for this purpose, which makes me doubt its fitness. SGX is very specifically billed as being for developers who want to run secure software in an untrusted environment, not for end users who don't trust the developers. These are wildly different scenarios.
2. The "encrypted channel with the processor" implies direct access to individual machines, which is impractical at Google scale.
3. The attestation is for binaries and not source, so attesting that the binaries are unchanged doesn't help users verify that the binaries match the trusted source. (Of course Google also doesn't publish the GMail source anyway.)
Signal actually just wrote up a very detailed post about how they're using SGX to provide verification that the computer you're sending your data to is running a specific algorithm: https://signal.org/blog/private-contact-discovery/
That's pretty cool, and a good write-up, too. Thanks for the link.
Obviously still doesn't help for the GMail case unless Google starts publishing their code, and they pretty much give up on email search, and somehow the whole chain of email cross-provider lands in these enclaves, but it's very interesting.
Unless the secret (password, certificate, hardware token, whatever) isn't absolutely required to access your data "because maths", then employees will have access to your data?
I guess there's a distinction to be made... perhaps if you go through that process you can regain control of your handle but not private data. But that wouldn't be useful since unless you're using a system which warns that your identity has changed (e.g. a new pgp key) then old contacts will continue to contact you, spilling the beans on old conversations?
not every J random googler I would hope but from experience working on x.400 mail some key people will have access.
in the 80's I had root on all the machines for the main UK ADMD and the level beyond root on the two billing systems - the OS was based on ITS A custom version of PR1MOS which is why there was a level beyond root.
Of course these days I would have had to have SC or DV clearance - I trust those googlers who do have access are properly security cleared :-)
Google have somewhere north of 3.3 billion user profiles registered. That was the count when a third-party service tracking such things was last on-line.
Assuming relatively modest rates of 1% of all users needing a password reset per year, the rate of password recoveries approaches one per second. That's about 100k per day.
(Google scale is large.)
I'm a fan of physical-token multi-factor authentication schemes. I don't think Google's process goes far enough. But I also recognise that it would be absolutely madness to deploy something like this with no means for account recovery.
Note that this system does not mention encrypting user data (a step I strongly advocate). In that case, losing a key is very much like losing an SSH key. There's no historical data relying on the old key, so issuing a new key is sufficient for recovery. The critical part is to not issue that new key to the wrong person.
If there are data encrypted against the key, the problem gets far more complicated: you both need the means to reconstruct a key, and to ensure that you do so only to the right person, and under the right circumstances. A key-splitting and key-quorum mechanism might be one way to approach this, possibly with a spare set of workfactor left off the keys.
I'm also looking into the question of whether or not blockchain-type public ledgers might be useful in recording / reporting on keys recovered in such fashion. Initial inquiries suggest that isn't impossible, though I'm not aware of any extant solutions providing that capability.
(On a related note, given mortality statistics, Google also have the issue of dealing with the death of users at a scale of tens of thousands of times daily.)
Google cannot implement what you’re proposing (nor can any email provider). Whatever mail service you choose must be able to send and receive email on your behalf and to do this, they must have access to the email in unencrypted form [1]. Yes, they could encrypt at rest. And yes, they could even encrypt with your public key at rest. This doesn’t eliminate the need to completely trust them [2] but it does completely break critical features like search and a usable mail archive.
[1] Yes, if you use gpg and the party you’re communicating does as well, then you don’t need to trust the email service. Good luck with that.
[2] If you can’t trust them to not look at your email then you can’t trust that they’ll actually encrypt without keeping a copy (or that they’ll actually encrypt at all). Encryption at rest is a great feature, but not for eliminating the need to trust the organization running the email service.
Don't know why this is being downvoted. If humans at Google can help recover the account, then it is potentially susceptible to social engineering. There's no way around that.
Because most people don’t consider ability to recover to be a “flaw”. The idea that Google is fucking up by not permanently locking someone out is absurd. There is no technical way for Google to even implement this. Someone at Google with sufficient access could always go poke the DB directly to change a locked-out user’s password hash and replace whatever hypothetical keys are in play. The most Google could do would be to force a purge/loss of any current user data encrypted at rest. This would of course not prevent a successful attacker from sending or receiving new emails.
I think that is the point, a Googler who is moonlighting for spooks in any country can spy on their behalf. In other words, people are cautiously pointing out it is not “only someone with the key” who can gain access to your emails.
I get that, but an account “reset” is always possible. Even if Google encrypted all of your mail and other content with a key you exclusively control, it would always be possible to simply drop the encrypted data, update all keys/passwords, and regain access to any incoming email. This is a smaller attack surface but still significant.
It’s also not actually possible to be an email provider and have no access to read plaintext and the point of send and receive. It can be encrypted at rest but you have to allow read for transmit which means a Googler working for the “spooks” could simply intercept there instead of at rest.
Well, you should be able to encrypt the subject/body of the email without encrypting the headers, so the mail vendor never sees the content of the email, only the to/from addresses and such. But that encryption has to happen in the browser/application. ie Mailvelope plugin for Chrome and others like it. and I think there is an android mail client that will also do pgp/gpg encryption/decryption.
Sure. You could absolutely have an entirely different protocol that doesn't work with all the existing email clients/services out there. It's certainly been done multiple times. Obviously it's not caught on, though, because compatibility is sort of a big deal.
I agree with your point. I also feel people think this is a panacea. The reality is this will just move the attack vector from phishing or key logging to an HID server feature in RAT software.
Does this mean they've eliminated that vulnerability where no matter what 2FA option you chose, someone could always get into your account by tricking Verizon or some other carrier that they are the owner of the phone number?
I never understood the point of offering additional so-called "stronger" 2FA options when the mandatory fallback was always the SMS code. Why even bother? Services should at least give users the option to disable SMS fallback. But really they need to start thinking about a SMS-less 2FA future. Even NIST has deprecated SMS 2FA.
You no longer get the option to use Google Authenticator until you've already set up 2FA the first time using SMS, at least in the US. You can remove your mobile number _after_ setting up Google Authenticator, but you have to remember to do that step.
It doesn't mean that because that vulnerability never existed. You've always been able to remove SMS 2FA after setting up a second method (backup codes or U2F).
> All non-Google services and apps will be exiled from reaching into your Gmail or Google Drive.
Does this mean I can no longer use Google's OAuth service for logging in to, say, Bitbucket? Or just that they are locking down the information such apps can access?
I just enabled it on my account, and I can still log into GitLab and other OAuth accounts. I presume it just means they can't access Gmail, Drive, or the other listed products.
I'm glad they're doing this--but I'd also like to see a little granularity.
If I'm a big-wig politician, I'd want it as-is, but as a normal techie, I'd like support in the native iOS apps and the ability to connect apps. However, I'd still like the strict (days-long) account recovery / verification process.
I agree with the utility of the granularity. On the implementation side, it adds a lot of complexity.
1) Every granularity feature adds a set of possible state interactions and widens the attack surface.
2) Every granularity feature is an opportunity for a user to accidentally misconfigure their settings and expose themselves to more risk than they believe they are.
What does this mean for IMAPS w/application specific passwords?
It's a really sad statement to say outloud, but if turning this on means my emacs mail client I've been using for ... years doesn't work anymore, I just can't do it.
It says that no non-Google app can currently access your stuff, but they are open to other apps being more secure.
"...limiting full access to your Gmail and Drive to specific apps. For now, these will only be Google apps, but we expect to expand these in the future."
"Kremlin-backed intrusion that hit the Gmail account of Hillary Clinton campaign manager John Podesta"
It's quite obvious to many that it was the Russians, even in the absence of formal proof. Why do we have to keep seeing this assertion, especially when the CIA had a team making malware that emulated or included ostensibly Russian code. No one was trying to frame the Russians; it was just to save time.
When Wikileaks was releasing her emails she called them fake and brushed it under the carpet. But when Trump suddenly wins, they corrupted the election. Fraud!
Ah yes, a hacker organization which does things like create Android malware to disable Ukrainian artillery and attempts to interfere with American elections is probably not a Russian front. Come on.
Dell SecureWorks and the CIA have presented plenty of evidence that this was a Russian-backed group, probably GRU.
EDIT: Also, even if there aren't lines in their malware which say "(c) GRU 2017", Fancy Bear is a group which consistently targets enemies of the Russian government. They don't steal credit card numbers, they commit digital terrorism that furthers Russia's interests. It doesn't really matter if they're 100% state-backed or not, because they clearly and consistently act in the Russian government's interests. An organization which hacks targets that benefit Russia and a Russian gov't hacking organization are the same thing from the perspective of the United States.
Russian - would make a lot of sense. Run by the government? Seems more like the sort of approach I'd expect from a bunch of kids who got bored of spamming/malware and got political. Phishing isn't really an advanced technique by intelligence agency standards.
“Most public of those was the Kremlin-backed intrusion that hit the Gmail account of Hillary Clinton campaign manager John Podesta”
friendly reminder there is no proof for this claim, Podesta either fell for a generic phishing page(Reset your gmail password here!), or from his known passwords (password and runner<some number>) someone could have easily just guessed his password.
It was widely reported that his password was stolen via a phishing attack. If the phishing attack was carried out by someone backed by the Kremlin, then I believe that makes the statement quoted true (I'm not sure about the level proof here as I am sure some of it is non-public).
There's actually quite a lot of evidence that it was a politically motivated spear phishing campaign from FancyBears, which is most likely from Russia. So technically yes there's no definitive, smoking gun proof but "no proof for this claim" seems to be a bit dismissive of some glaring hints. It certainly wasn't just a "generic phishing page" or guessing of a weak password.
They went after quite a few politicians on both sides of the aisle and journalist's, the Podesta camp just happened to be the ones who fell for it.
Just to add to this, https://en.wikipedia.org/wiki/Fancy_Bear has links to multiple security companies which have publicly drawn the link to the Russian government.
The list of targets is also convincing: various NATO organizations but also things like the World Anti Doping Agency at the time the Russian Olympic team was being disqualified from everything. You could argue that, say, China might be interested in hacking the US or France but Eastern Europe and WADA really aren’t of interest to most other major powers.
Keep in mind that the companies which pointed to Russia also have contracts with the executive office of the president - i.e., making up stories to support the administration's narrative is good for business. Let's be honest, this is Washington D.C. we're talking about, and that level of collusion is nothing new. I'm sure the administration offered perks to anyone who could present convincing "evidence" of a Russian connection.
Indeed, no proof, as almost always the case with hacking. Just probabilities. Moreover, intelligence agencies that routinely use misdirection to point the blame at each other. Who knows what happened. Could have been hacked by multiple attackers too given how simple it was.
Regardless, I think the next sentence is the most telling:
Or, as CDT's Hall puts it, "If John Podesta had been able to turn this on sometime last year, the world might be a very different place."
Implying what - that Trump wouldn't have won? The leaked emails were real though. What he's saying is that if the USA had known less about Clinton, they might have picked her to be prez. That doesn't seem very likely given the very long track record Clinton had and the high level of familiarity Americans had with her, but even if true - "this feature is good because it would have kept Americans in the dark" does not seem like a positive message to send.
Great point. Personally, I'm glad all of the emails, leaked and subpoena'd, came to light. Some very damning things were revealed that the public should be aware of.
Eneryone is 100% positive it was The Kremlin and not Podesta’s IT Chief who “misspoke” when telling Podesta the phishing email was legit and to go ahead and click in.
There is proof that his password was password, and there is proof that his IT told him the phishing email was legit.
There is no way that same IT was capable of securing a mail server for HRC.
Caveat. If you post anything subversive or controversial, they will just punt your account.
All a hacker has to do is present some evidence to any of this, and your account is gone...
That may be the case with their free accounts or money earning YouTube accounts, but that is not the case for subscription based GSuite business accounts. The GSuite accounts are set up so that an offending user is a sub-account of the parent GSuite account. They will ask the parent account owner to suspend the user's account and take measures to fix the violations, but they wont unilaterally suspend the parent account.
(OT but related to security and Google) I used the existing link at the bottom of my gmail page to sign out all other sessions. The next day I went to another device and saw that it was still signed in.
i suppose the missing piece would be to tie it to a specific chromebook to avoid issues with pwnage of the endpoint. they say they require chrome, i wonder if it would be possible to steal the session cookies and run a second session on the same host? (maybe they fingerprint the browser or use some other scheme to ensure that they only talk to the authenticated browser process?) i suppose even if that was the case, if the endpoint was pwned the browser could be modified to make requests in the background on behalf of the pwners.
almost kinda surprising they didn't tie it to special chromebooks that they could sell. not only would it actually mitigate a big problem, i could totally see it also being some kind of a "i'm an important person" status symbol that people would brandish in public. if they gave it a distinct look it would be like a newfangled blackberry or zero halliburton for whatever you call this weird decade.
141 comments
[ 3.0 ms ] story [ 215 ms ] threadWhat are the recommended bluetooth and USB-based keys I should be buying?
This includes USB and Bluetooth LE devices. I'm still getting up to speed on technology, but prefer very near-field chips with a range of < 10cm (4 in), and if possible, < 1cm. Making unintentional / accidental detections, or snooping, as difficult as possible would be a bonus.
(It's possible that interactive timing might be a mechanism: a nanosecond-scale time resolution works out to about 10 cm.)
Unfortunately that requires different radio hardware. Look up Ultra Wide Band.
And if you're thinking "but China?!!", remember that they've got their interests in secrets too, and might see a need for a secure and trusted system.
Of course if you also want RSA key management on top of it your going to spend more money....
Not very helpful, I know..
https://lastpass.com/support.php?cmd=showfaq&id=8126
Review of security keys by Adam Langley:
https://www.imperialviolet.org/2017/08/13/securitykeys.html
and testing security keys:
https://www.imperialviolet.org/2017/10/08/securitykeytest.ht...
tl;dr: Yubikeys are $$ but really solid for USB and NFC; the Feitian is probably the best option for Bluetooth but YMMV there. Those are what I personally use.
(Note that Yubico recently announced a problem with their RSA key generation, which they're fixing, but that bug does not affect the security of the device when used as a FIDO authenticator as it is for Google/Github/Dropbox/Vanguard/etc.)
https://www.yubico.com/support/security-advisories/ysa-2017-...
I'm just going to point out that this article is written by Yubico, who undoubtedly wants to sell you a device.
Probably should have linked that directly. I've updated my comment to link to the paper instead of the article. Thanks!
That's actually not much different than paying for a domain and G Suite Basic.
Which is probably what they expect people that concerned will do.
Cost, yes. Well understood? Not by the vast majority of the few billion Google users, who think it's perfectly normal for Google's service to just magically appear on the Internet without them having to fork over any cash.
...However, court documents suggest that this could be temporary. A month after Google's announcement, the company quietly agreed (PDF) to settle a class-action lawsuit alleging that the targeted-advertising scanning was illegal wiretapping. That deal, in which a federal judge gave "preliminarily approval" (PDF) to on Thursday, binds Google for just three years....
https://arstechnica.com/tech-policy/2017/09/google-promised-...
Google claim, with some credibility, not to offer up personal information via email. Instead, ads are placed, but user identification is not provided. (The extent to which this information can be de-anonymised is something I'd like to see.)
But the data remain, on Google's servers, encrypted to keys Google itself has, and susceptible to exfiltration by various account attacks.
The problems of the Podesta attack mentioned in the article are several. Google are addressing part, but not all, of that attack.
1. Podesta was sent a phishing message that was not detected and blocked entirely.
2. His multi-member email management team failed to appropriately respond to that message. This isn't a case of Podesta alone falling for this, he had help.
3. His password was obtained.
4. The password, and it alone, was sufficient to access Podesta's account.
5. Unusual access patterns were not detected and blocked by Google. (Google are actually fairly good at doing this -- to the extent I've been repeatedly locked out of accounts.)
6. Given account access, substantially all of Podesta's email was successfully copied to the attacker's systems.
7. That email was immediately readable to the attackers, as it was not encrypted to keys Podesta alone controlled (and independent of his already-compromised password).
That's seven points of failure, any one of which could have prevented the attack.
So it’s a flaw that you can access your email when you’re authenticated successfully?
There should be a second-stage, preferably device-only, decryption phase.
That is, the entire concept of "identity" is confounded out of a cluster of often only loosely-related concepts. Among them:
1. Who are you?
2. Should I trust you?
3. Did you do X?
4. Is X as you left it?
5. Can you (and ideally you alone) read X?
6. Should I allow you to do X?
7. Do I owe you / you owe me X?
8. Must I pay you (or seek permission) to use/do X?
9. Are you the same X as some other X' (in another place, time, system, ...)?
Accessing the email store (authentication) is not the same as being able to read email (decryption), or being able to say you sent a specific message and that it hasn't been changed (integrity).
Electronic / digital data formats violate many of the trust bases that have formed around material or personal data transfers. Paper, stamps, seals, institutional trust (that, say, the post office isn't opening, reading, and/or censoring mails), etc. It's an entirely different set of physics, if you will.
The rules have changed. Google are playing by the old rules. They are losing, and so are we.
Google does not need the decrypt key.
Separation also reduces phishing risk.
Also Google does need the decrypt key if you care about things like search or history.
Flipped around, if website notifications were encrypted and posts were signed, there'd be little need for website authentication.
Search and history might require initial access to a message but otherwise creaate encrypted indices. Or could be handled fully client-side.
Not sure what you’re referring to with the website notifications and posts.
Search and history can only be handled client side if you are going to download your entire mailbox, something almost no one does anymore. Initially indexing is theoretically feasible but makes it essentially impossible to ever reindex to fix bugs or improve performance.
This includes encrypting unencrypted messages, after arrival, to the user's own key(s).
Keep in mind that data security consists of numerous elements:
* Access.
* Encryption-in-flight.
* Encryption-at-rest.
* Encryption-to-client.
* Rates of transfer or exfiltration. This has numerous elements, one of which I refer to as the Pennyworth limit. Bruce Wayne has a butler who is privy to Wayne's innermost secrets. But he is not also privy to the secrets of all of Gotham. And even at maximum data transmission rate, can only reveal a few hundred words a minute of information, on the order of a megabyte or so per day (in textual form). Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.
* An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally. Since reading information client-side requires transmission of that data in any regard, the information is already client-side. There are now microSD devices with capacity approaching or exceeding 1 TB and above. Storage itself is not a limitation.
Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.
I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.
How would it ever be auditable or verifiable? You're talking about secret source code running in private data centers on inaccessible hardware. If you need auditability or verifiability, you cannot rely on GMail or any similar service.
> Our electronic devices and systems have far more information, in far more detail, on far more people, available at far higher rates, and for the most part, can be tapped with absolutely no awareness by the subject of the information revealed.
I'm not dismissive of that concern but I fail to see its relevance to the question of whether Google should add another key to everyone's account. You don't solve this problem by encrypting your mail unless you stop sending your mail through Google. In fact you don't even solve it that way because such a huge chunk of mail you send/receive will flow through Google anyway. You cannot solve the trust problem by adding another unverifiable layer of encryption. If you don't trust Google now, that shouldn't change if they tell you that they started encrypting with your public key at rest.
> An "entire mailbox" is only a few hundreds of MB or GB, and arrives incrementally....Storage itself is not a limitation.
I disagree. I'm using ~10 GB of storage for Gmail. I don't want that space used for mail on my phone. Or my laptop for that matter, which has only ~36GB free at this point. I can't stick an SD card in my phone and if I could I wouldn't because it's slow.
> Unencrypted email can be indexed, the indexes encrypted, and transmitted to the client device.
It really can't. If the index is encrypted, then it can't be updated with new entries. So the best you can do is generate an inverted index per email and send that to the client to combine into a real index. But at that point, don't even bother because the client can probably index each email locally more cheaply than it can stream it from the server.
Given that most people are now using web clients, pushing indexing responsibility onto the client isn't remotely feasible. Imagine you log in from a new browser and GMail tries to push GBs into your localstorage and then your browser churns for hours trying to build the index.
> I'm not saying that the technical considerations here are simple, but the costs of failing to address them, quite literally the future of liberal democracy, are too high to not do so.
I think that's overstating it, mostly because adding a second key does not eliminate the social engineering weakness (maybe it's reduced). But also because I don't think leaked emails constitute the end of democracy.
Google are already under at least one privacy-related consent decree.
https://techliberation.com/2011/03/30/the-ftc’s-google-buzz-...
https://www.ftc.gov/enforcement/cases-proceedings/102-3136/g...
Of course, this doesn't fix the security issues, email are still accessable to Google if they wanted to look.
In addition to the Wired article, there's a Google blog post about it: https://www.blog.google/topics/safety-security/googles-stron...
Details remain somewhat vague as to having multiple credentials, or managed accounts (though the corporate service -- Google Domains or whatever it's called, should allow an administrator some options).
There are two forms of this assurance.
The first is running into some guy at a party, or on an internet message board, who either works at Google or "knows a guy" who does, who then spends thirty or forty minutes semi-drunkenly rambling at you about how the security at Google is "military grade" and everything is "locked down" and they have some guy who used to run the Mossad in charge of internal security and he's the best guy ever and nothing or no one ever breaks in and that shit's a fortress. Trust the semi drunken ramblings of this guy you just met, your secrets are safe with the big G.
The second form of this assurance is only giving the third party indistinguishable encrypted blobs of data. They can look at them all they want, it doesn't mean anything to them. You don't need to trust anyone, let alone some guy you found on the Internet and transitively a few hundred anonymous computer programmer and IT janitors spread across the world.
Go figure, some people are more persuaded by the second argument. Even if you're reading this and you work at G and you know that the ex-Mossad security guys are digitally looking over your shoulder and you shake your fist at this screen muttering "you don't know how much we have it locked down here, clueless Hacker News commentator" you have to realize, somewhere in your heart of hearts, that a zero trust solution is preferable when you are trying to maximize for security.
Just get a pretty locked down Gmail account and use pen and paper or OTPs or GPG for things that actually need to be secure.
1) Emails disclosed as part of a legal discovery process that compelled Clinton to hand over the emails herself.
2) Copies of her emails acquired from a correspondent with a much-less-secure configuration of their Gmail account than Clinton's configuration of her private server.
Email is, by its nature, a distributed infosec problem.
The threat of a breach of the email account is that it's the key to everything else -- pretty much any other account, with any other service, is instantly accessible the moment you're in someone's email, because the email inbox is where credential-reset requests are sent.
There’s no such thing as zero trust for email unless you’re going to run your own server (even then it’s iffy because of communication with other untrusted servers).
By using a mail service, you have to trust the people running the service. Even if they pinky promise to immediately encrypt every message with your public key a never never never look at it, you cannot know that they aren’t secretly redirecting a copy to the NSA and publishing another copy on the novelty Twitter account @muninmails.
https://moxie.org/blog/lavabit-critique/
Unlike the design of most secure servers, which are ciphertext in and ciphertext out, this is the inverse: plaintext in and plaintext out. The server stores your password for authentication, uses that same password for an encryption key, and promises not to look at either the incoming plaintext, the password itself, or the outgoing plaintext.
The ciphertext, key, and password are all stored on the server using a mechanism that is solely within the server’s control and which the client has no ability to verify. There is no way to ever prove or disprove whether any encryption was ever happening at all, and whether it was or not makes little difference.
... The operator can at any time stop averting their eyes, an attacker who compromises the server can log the password a user transmits, and an attacker who can intercept communication to the server can obtain the password as well as the plaintext email...The cryptography was nothing more than a lot of overhead and some shorthand for a promise not to peek. Even though they advertised that they “can’t” read your email, what they meant was that they would choose not to.
There are maybe a few things that could be done to reduce your trust in "Honest Munin's Very Secure E-Mail Hosting and Used Cars", like, I could publish the code to the server and run it in SGX, allowing anyone in the world to use SGX attestation to verify* that the code running in SGX is the code that I publish, and that code could only initiate encrypted network connections with other mail servers. So even if I ran that in good faith and sat outside the SGX container listening to the network traffic, I'd still be getting a face-full of encrypted data.
This is still a "verify*" because maybe something is funky with SGX. You're not really trusting me now though, you're trusting Intel and the SGX TCB. Maybe that's worse? I don't know. I still think that's an improved proposition over trusting the honesty of system administrators to not grep your INBOX on a whim, though.
edit: I guess this also kind of breaks down because the story for TLS in SMTP land is kind of dire, so you could probably actively MITM the communication between the SGX blob and the outside and there's no practical way for anyone to know that this is going on. Maybe someone will fix that someday! Probably not though!
As for SGX, it doesn’t really solve for this problem. It would allow Google to verify what software is running, but with a Google-controlled network in between the server in question and the user, I’m fairly certain any assurances SGX could yield are gone. Google could publish their code publicly, allow users to request attestation, but send attestation requests to server A running the public code while serving the user’s email on server B running NSA-modified snooping code. And of course your email isn’t actually sitting on a single machine anyway. It’s probably stored redundantly on 3+ backend machines and served by any of thousands of front end machines. Verifying each of these would be infeasible even if technically possible. (I’m not very familiar with SGX, though, so maybe there’s some magic I’m missing here.)
Also attestation is for binaries. I doubt you could actually verify a source match.
There is magic you are missing. I don't want to be the person that glibly says "you should read more about this" and then vanishes, but because I don't have time to write out what the magic is, that's exactly what I'm going to do :(
The magic does allow users to verify that the software they're talking to is what it says. Specifically, it also allows users to set up an encrypted channel with the processor that is running the software that is attested, so you exactly can't do the attack you propose of shuttling attestation to one system and actual data to another.
The technology is pretty cool, you should check it out!
1. Intel does not bill the technology for this purpose, which makes me doubt its fitness. SGX is very specifically billed as being for developers who want to run secure software in an untrusted environment, not for end users who don't trust the developers. These are wildly different scenarios.
2. The "encrypted channel with the processor" implies direct access to individual machines, which is impractical at Google scale.
3. The attestation is for binaries and not source, so attesting that the binaries are unchanged doesn't help users verify that the binaries match the trusted source. (Of course Google also doesn't publish the GMail source anyway.)
Obviously still doesn't help for the GMail case unless Google starts publishing their code, and they pretty much give up on email search, and somehow the whole chain of email cross-provider lands in these enclaves, but it's very interesting.
I guess there's a distinction to be made... perhaps if you go through that process you can regain control of your handle but not private data. But that wouldn't be useful since unless you're using a system which warns that your identity has changed (e.g. a new pgp key) then old contacts will continue to contact you, spilling the beans on old conversations?
in the 80's I had root on all the machines for the main UK ADMD and the level beyond root on the two billing systems - the OS was based on ITS A custom version of PR1MOS which is why there was a level beyond root.
Of course these days I would have had to have SC or DV clearance - I trust those googlers who do have access are properly security cleared :-)
Assuming relatively modest rates of 1% of all users needing a password reset per year, the rate of password recoveries approaches one per second. That's about 100k per day.
(Google scale is large.)
I'm a fan of physical-token multi-factor authentication schemes. I don't think Google's process goes far enough. But I also recognise that it would be absolutely madness to deploy something like this with no means for account recovery.
Note that this system does not mention encrypting user data (a step I strongly advocate). In that case, losing a key is very much like losing an SSH key. There's no historical data relying on the old key, so issuing a new key is sufficient for recovery. The critical part is to not issue that new key to the wrong person.
If there are data encrypted against the key, the problem gets far more complicated: you both need the means to reconstruct a key, and to ensure that you do so only to the right person, and under the right circumstances. A key-splitting and key-quorum mechanism might be one way to approach this, possibly with a spare set of workfactor left off the keys.
I'm also looking into the question of whether or not blockchain-type public ledgers might be useful in recording / reporting on keys recovered in such fashion. Initial inquiries suggest that isn't impossible, though I'm not aware of any extant solutions providing that capability.
(On a related note, given mortality statistics, Google also have the issue of dealing with the death of users at a scale of tens of thousands of times daily.)
https://support.google.com/accounts/answer/3036546?hl=en
[1] Yes, if you use gpg and the party you’re communicating does as well, then you don’t need to trust the email service. Good luck with that.
[2] If you can’t trust them to not look at your email then you can’t trust that they’ll actually encrypt without keeping a copy (or that they’ll actually encrypt at all). Encryption at rest is a great feature, but not for eliminating the need to trust the organization running the email service.
'Advanced Protection'?
In any case, if passwords can be reset and if USB keys can be changed, there is always a flaw... No matter what Google say.
It’s also not actually possible to be an email provider and have no access to read plaintext and the point of send and receive. It can be encrypted at rest but you have to allow read for transmit which means a Googler working for the “spooks” could simply intercept there instead of at rest.
I never understood the point of offering additional so-called "stronger" 2FA options when the mandatory fallback was always the SMS code. Why even bother? Services should at least give users the option to disable SMS fallback. But really they need to start thinking about a SMS-less 2FA future. Even NIST has deprecated SMS 2FA.
Does this mean I can no longer use Google's OAuth service for logging in to, say, Bitbucket? Or just that they are locking down the information such apps can access?
Yeah, the world might not have known how much of an absolute creep the guy is.
If I'm a big-wig politician, I'd want it as-is, but as a normal techie, I'd like support in the native iOS apps and the ability to connect apps. However, I'd still like the strict (days-long) account recovery / verification process.
1) Every granularity feature adds a set of possible state interactions and widens the attack surface.
2) Every granularity feature is an opportunity for a user to accidentally misconfigure their settings and expose themselves to more risk than they believe they are.
It's a really sad statement to say outloud, but if turning this on means my emacs mail client I've been using for ... years doesn't work anymore, I just can't do it.
> For secure access, you will need to use the Gmail app or Inbox by Gmail.
"...limiting full access to your Gmail and Drive to specific apps. For now, these will only be Google apps, but we expect to expand these in the future."
https://www.blog.google/topics/safety-security/googles-stron...
https://www.ftsafe.com/products/FIDO/Multi#Compatibility
I don't think it supports things like Safari though.
Here's an example: https://github.com/hansemannn/iOS11-NFC-Example
It's quite obvious to many that it was the Russians, even in the absence of formal proof. Why do we have to keep seeing this assertion, especially when the CIA had a team making malware that emulated or included ostensibly Russian code. No one was trying to frame the Russians; it was just to save time.
https://theintercept.com/2017/03/08/wikileaks-files-show-the...
Dell SecureWorks and the CIA have presented plenty of evidence that this was a Russian-backed group, probably GRU.
EDIT: Also, even if there aren't lines in their malware which say "(c) GRU 2017", Fancy Bear is a group which consistently targets enemies of the Russian government. They don't steal credit card numbers, they commit digital terrorism that furthers Russia's interests. It doesn't really matter if they're 100% state-backed or not, because they clearly and consistently act in the Russian government's interests. An organization which hacks targets that benefit Russia and a Russian gov't hacking organization are the same thing from the perspective of the United States.
http://www.bbc.co.uk/newsbeat/article/37374053/what-we-know-...
Russian - would make a lot of sense. Run by the government? Seems more like the sort of approach I'd expect from a bunch of kids who got bored of spamming/malware and got political. Phishing isn't really an advanced technique by intelligence agency standards.
There is considerably more than zero evidence that it was the Russians, though most of the public evidence is indirect.
friendly reminder there is no proof for this claim, Podesta either fell for a generic phishing page(Reset your gmail password here!), or from his known passwords (password and runner<some number>) someone could have easily just guessed his password.
They went after quite a few politicians on both sides of the aisle and journalist's, the Podesta camp just happened to be the ones who fell for it.
https://www.secureworks.com/research/threat-group-4127-targe...
https://arstechnica.com/information-technology/2016/10/russi...
The list of targets is also convincing: various NATO organizations but also things like the World Anti Doping Agency at the time the Russian Olympic team was being disqualified from everything. You could argue that, say, China might be interested in hacking the US or France but Eastern Europe and WADA really aren’t of interest to most other major powers.
Let's also not forget that the initial Fancy Bear claim was discredited: https://www.voanews.com/a/cyber-firm-rewrites-part-disputed-...
Regardless, I think the next sentence is the most telling:
Or, as CDT's Hall puts it, "If John Podesta had been able to turn this on sometime last year, the world might be a very different place."
Implying what - that Trump wouldn't have won? The leaked emails were real though. What he's saying is that if the USA had known less about Clinton, they might have picked her to be prez. That doesn't seem very likely given the very long track record Clinton had and the high level of familiarity Americans had with her, but even if true - "this feature is good because it would have kept Americans in the dark" does not seem like a positive message to send.
Create a new "Advanced Protection"account.
Use this new account only for: * password recovery * backup account * banking credentials (maybe?)
This backup account can then be used to protect against any password recovery attack against any other site that you rely on.
Your normal day to day email can stay with the regular security.
almost kinda surprising they didn't tie it to special chromebooks that they could sell. not only would it actually mitigate a big problem, i could totally see it also being some kind of a "i'm an important person" status symbol that people would brandish in public. if they gave it a distinct look it would be like a newfangled blackberry or zero halliburton for whatever you call this weird decade.