[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] Google Accounts Security Vulnerability
- To: <full-disclosure@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Full-disclosure] Google Accounts Security Vulnerability
- From: "Michael J. Gray" <mgray@xxxxxxxxxxxx>
- Date: Wed, 16 May 2012 17:12:43 -0700
The point of my article is to specifically show that Google has a system in
place which gives the perception of a particular type of security; that is if
their password happens to be compromised, that the attack will be limited
unless the attacker has very specific knowledge about the user and their
account. This being circumvented renders the system useless, especially if it's
able to be bypassed on an individual basis as I had described in my article.
Google's idea seems to be that users shouldn't have to keep track of many
passwords. But, how does this risk assessment system really help? The way I see
it, Google requires you to simply provide other information in addition to a
password, which could be seen as passwords themselves. If an account requires
two passwords, this just increases the burden on the user. The best solution
would be to use two factor authentication. You would want to combine something
you know with something you have instead of something you know with something
many people probably know. If someone has my password, they probably have my
phone number and other information or can manually stop their attack and find
the information or compile a list of challenge questions and their appropriate
responses.
As far as it being a solution to naïve attacks, sure it probably works fine.
However, it's not a difficult task for any serious attacker with a botnet doing
the automation.
And for your comment about analyzing it as if it were a replacement... well, it
kind of is what Google has done with it. It prompts you for a second password
which is based on a variable context. It adds no security but gives the user
peace of mind and helps them believe there is added security when there really
isn't. That alone could be more harmful than the attackers having to do a
simple upgrade.
A more reasonable way to prevent botnet driven attackers with lots of valid
credentials would be to use two factor authentication.
-----Original Message-----
From: Mike Hearn [mailto:hearn@xxxxxxxxxx]
Sent: Wednesday, May 16, 2012 1:38 PM
To: full-disclosure@xxxxxxxxxxxxxxxxx
Cc: mgray@xxxxxxxxxxxx
Subject: Re: Google Accounts Security Vulnerability
Hi there full-disclosure,
I wanted to respond to the recent post covering the Google real time
anti-hijacking system and explain a bit more about what this system is and how
it works. For background I am the tech lead of the relevant team, and Daniel
Margolis works on it with me.
Firstly, I'd like to note that despite what Michael may have observed with his
account, performing a programmatic login does not whitelist for web access.
Most of the time if you would be challenged via the web then logging in via POP
or IMAP would also be denied, and result in a notification email about the
blocked login. See here for what this looks like:
http://blog.plaxo.com/2012/05/google-account-%E2%80%9Csuspicious-activity%E2%80%9D-next-steps/
There are a small number of edge cases that can cause this rule to break.
Unfortunately although Daniel asked for it, Michael has not provided the name
of the account in question so we cannot check which one it was. To understand
why this is not a problem it's important to understand the design parameters of
this security system.
The real-time antihijack system was created to solve a specific problem,
namely, spammers/scammers turning up at our front door with large numbers of
valid passwords. I gave a public talk at the RIPE64 conference last month which
provides some background:
https://ripe64.ripe.net/archives/video/25/
https://ripe64.ripe.net/presentations/48-AbuseAtScale.pdf (slides)
Executive summary: it is no longer unexpected for individual attackers to own
on the order of a million valid passwords. These passwords are taken from
compromised websites and the hashes reversed using GPUs. We have in the past
seen known attackers correctly authenticate to over
30 accounts per second and this problem is structural - it's isn't going to go
away any time soon.
For this reason we now perform a risk analysis of every login and if we suspect
it may not be the real owner of the account, redirect it to identity
verification. This is what Michael saw.
The primary design principle of the system is to move all our users into the
post-password age as gently as possible. The threat model covers attacks that
operate at scale and who do not care about the specific accounts they work
with. We provide things like 2-step verification, which authenticates you via a
device or phone, for handling the stronger threat model of a highly motivated
adversary against a specific highly motivated defender.
One outcome of this threat model is that if we can protect 95% of accounts from
an attacker, that's good enough because it renders their attack uneconomic and
they go away. See this paper from Microsoft
Research:
http://research.microsoft.com/pubs/149885/wheredoalltheattacksgo.pdf
For this reason the system will usually fail open if there is a problem of some
kind. An example of what can cause the type of behavior Michael saw: if there
the risk analysis subsystem misses its deadline the login processing servers
will proceed without it.
Timeouts are rare but can occasionally happen. There are other cases involving
specific types of account history and IP address combinations that could cause
what Michael observed. Or there could be a bug :-)
It's best to view the risk analysis / id verification system as more like a
spam filter than a hard-guarantee security system. It relies heavily on
security through obscurity and exploiting weaknesses of very specific
opponents, against which it has proven very effective.
Analyzing it as if it were a complete replacement for password security will
lead only to disappointment.
thanks
/mike
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/