
Google's 'Advanced Protection' Locks Down Accounts Like Never Before - sohkamyung
https://www.wired.com/story/google-advanced-protection-locks-down-accounts
======
cavisne
“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.

~~~
heatish
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.

[https://www.secureworks.com/research/threat-
group-4127-targe...](https://www.secureworks.com/research/threat-
group-4127-targets-hillary-clinton-presidential-campaign)

[https://arstechnica.com/information-
technology/2016/10/russi...](https://arstechnica.com/information-
technology/2016/10/russia-linked-phishing-campaign-behind-the-dnc-breach-also-
hit-podesta-powell/)

~~~
acdha
Just to add to this,
[https://en.wikipedia.org/wiki/Fancy_Bear](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.

------
moduspwnens14
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.

~~~
fixermark
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.

------
pm24601
My suggestion for "normal" users.

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.

~~~
DenisM
The less often you use this account, the more likely you are to lose the keys.

~~~
pm24601
I write them down. A note with a mysterious sequence of letters is not
generally a theft target.

------
WindowsFon4life
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...

~~~
amckenna
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.

------
codemac
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.

~~~
dgacmu
You're correct:

> For secure access, you will need to use the Gmail app or Inbox by Gmail.

~~~
codemac
The end is nigh.

------
linopolus
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.

~~~
giarc
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.

~~~
munin
> 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.

~~~
dpark
> _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.

~~~
munin
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!

~~~
dpark
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.

~~~
munin
> 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!

~~~
dpark
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.)

~~~
haldean
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/](https://signal.org/blog/private-contact-discovery/)

~~~
dpark
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.

------
acobster
> _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?

~~~
parent5446
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.

------
camiller
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?

~~~
dredmorbius
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).

~~~
camiller
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.

~~~
dredmorbius
Thanks for that, and good question.

------
nopal
How do the Google iOS apps handle authentication, since NFC security keys
aren’t supported by Apple?

~~~
zghst
NFC keys are now a possible reality since iOS 11 API opened up the hardware to
developers.

Here's an example: [https://github.com/hansemannn/iOS11-NFC-
Example](https://github.com/hansemannn/iOS11-NFC-Example)

~~~
georgiedown
For the record, it's only possible to READ tags using iOS 11.

------
a-dub
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.

------
wakkaflokka
I'm going to take the plunge into using security keys.

What are the recommended bluetooth and USB-based keys I should be buying?

~~~
dgacmu
Why to use security keys:
[http://fc16.ifca.ai/preproceedings/25_Lang.pdf](http://fc16.ifca.ai/preproceedings/25_Lang.pdf)
(updated from my earlier link to the yubico article _about_ that paper:
[https://www.yubico.com/2016/02/use-of-fido-u2f-security-
keys...](https://www.yubico.com/2016/02/use-of-fido-u2f-security-keys-focus-
of-2-year-google-study/) )

Review of security keys by Adam Langley:

[https://www.imperialviolet.org/2017/08/13/securitykeys.html](https://www.imperialviolet.org/2017/08/13/securitykeys.html)

and testing security keys:

[https://www.imperialviolet.org/2017/10/08/securitykeytest.ht...](https://www.imperialviolet.org/2017/10/08/securitykeytest.html)

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.)

~~~
tonyztan
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.

[https://www.yubico.com/support/security-
advisories/ysa-2017-...](https://www.yubico.com/support/security-
advisories/ysa-2017-01/)

~~~
arnarbi
FIDO U2F does not use RSA anyways.

------
m1n1
(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.

------
Crontab
So how would someone back up their email using this system?

------
singularity2001
Anyone else read the title as "Google Locks Down Accounts", as in: Google
closes accounts without any chance of remedy?

~~~
adzicg
That would be ‘Locks out’ instead of ‘locks down’

------
0xbear
Wouldn’t users who sign up for this also de facto flag their accounts for NSA
operatives embedded within Google?

------
mtgx
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.

~~~
gruez
is that even an issue to begin with? afaik you need a phone to enable 2fa, but
you can remove it after adding another token.

~~~
tonyztan
Exactly. Google has always (at least since 2012) provided the option to remove
any and all phone numbers from your account after enabling 2FA.

------
pksadiq
> And if you forget your password, or lose your hardware login keys, you'll
> have to jump through more hoops than ever to regain access ...

'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.

~~~
tonyztan
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.

~~~
dpark
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.

~~~
CodeWriter23
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.

~~~
dpark
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.

~~~
camiller
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.

~~~
dpark
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.

------
fortythirteen
Locks down your Gmail from everyone except the companies that pay Google for
the information gleaned from AI reading your emails.

~~~
edraferi
Which is the well-understood cost of getting an otherwise free, highly
performant, unusually secure service for free.

~~~
tonyztan
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.

~~~
dragonwriter
> I'd pay $5-10 per month for Google's services without me being the product.

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.

~~~
tonyztan
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.

------
jamiesonbecker
"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.

[https://theintercept.com/2017/03/08/wikileaks-files-show-
the...](https://theintercept.com/2017/03/08/wikileaks-files-show-the-cia-
repurposing-foreign-hacking-code-to-save-time-not-to-frame-russia/)

~~~
nateberkopec
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.

~~~
peoplewindow
It'd be kind of weird if they were state backed given that they run websites
with their own name and use cheap Anonymous slogans:

[http://www.bbc.co.uk/newsbeat/article/37374053/what-we-
know-...](http://www.bbc.co.uk/newsbeat/article/37374053/what-we-know-about-
fancy-bears-hack-team)

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.

