lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 May 2012 22:38:21 +0200
From: Mike Hearn <>
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:

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:  (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

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.


Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ