dmargolis at google
May 20, 2012, 11:11 AM
Post #29 of 36
(177 views)
Permalink
|
|
Re: Google Accounts Security Vulnerability
[In reply to]
|
|
Right. I think you're entirely correct to call this out as a distinct
feature from checking the user's raw credentials. The point of this
function is, as Mike said, to try to protect against bulk use of stolen
credentials--the starting assumption is thus that the attacker already has
valid credentials.
That said, you're making a few inferences that are unfair. As Mike said,
we're not deemphasizing or otherwise discouraging use of two-step
verification--far from it. Not reusing passwords and using two-step
verification are the two things we most strongly recommend to protect your
account.
Your claim that this discourages the use of these *other* safety mechanisms
is essentially a claim about what's known as "risk
compensation<http://en.wikipedia.org/wiki/Risk_compensation>."
The most common example of this theory is the claim that antilock brakes
and seat belts cause car drivers to drive faster and less safely,
counterbalancing any safety gains through riskier behavior. (Though the
evidence for these examples is itself controversial.)
I think there are a couple of problems with the claim as applied to our
login quiz. First, I don't think, among the general population, there are
that many people who have any real awareness of the login quiz's existence
or what the parameters of the safety it applies really are. Without that
awareness, it's hard to imagine user behavior would really change. Second,
unlike the canonical examples of risk compensation, in our case the
adversary is intelligent and responds to economic incentives. Car accidents
don't go find some other population to target if the *per accident* injury
rates go down due to seat belt use, but account hijackers do go find
another population if the *per attempt* success rate goes down--a declining
marginal profit disincentivizes attacks even if any given attack is still *
possible* (see again the paper Mike linked to, "Where Do All The Attacks
Go?").
Anyway, you're right, this feature is indeed weak against individual
attacks, as Mike said earlier. Our threat model is, essentially, bulk
attacks. The thing you have to remember is that hijacking accounts in
bulk--without foreknowledge of a particularly valuable attack--is a bit
like prospecting for oil. You can dig a bunch of holes in a bunch of
places, and one of them might be really valuable, but the average yield is
still going to be very low. If we can make the average cost of drilling a
hole higher than the average yield, you're not going to bother doing this.
It's certainly true that if you know a given account is valuable, you can
target that account, and the cost of bypass might be lower than the yield.
But for the vast majority of users, bulk attacks pose the biggest risk, and
those are what this feature is really designed to mitigate.
As said many times before, two-step verification is especially recommended
for accounts that might be subject to targeted attacks.
Finally, regarding your not giving us the account name, I certainly
understand, and that's fine. But I hope you understand that we ask for this
not out of laziness but because, as I said before, we have known and *by
design* ways in which the behavior you observed can occur. It sounds very
much like you hit one of these paths. The reason I asked for the account
name was simply to verify that you didn't encounter some other
not-by-design path that results in the same behavior. If, as Dan said, you
can get this to recur on a sock puppet account, by all means feel free to
send me the details and I'll double-check to make sure this is intended
behavior.
Dan
From: Michael J. Gray <mgray [at] emitcode>
> Date: Sat, May 19, 2012 at 12:04 PM
> Subject: Re: [Full-disclosure] Google Accounts Security Vulnerability
> To: "Thor (Hammer of God)" <thor [at] hammerofgod>, Dan Kaminsky <
> dan [at] doxpara>
> Cc: full-disclosure [at] lists
>
>
> I was not stating that it was a vulnerability in the sense of someone can
> compromise your account with only your phone number. I was saying its not
> doing its job in terms of what most people expect it to do.****
>
> It provides a false sense of security. Its a security mechanism, it
> prevents people from logging onto accounts when they come from a location
> that is unrecognized as associated with the account and it can be
> circumvented with little effort on an individual basis. Distributed attacks
> would have trouble with it, but could adapt to it. If distributed attacks
> are the only component of their threat model, then its fine. Regardless,
> its interesting and thats why its here. ****
>
> ** **
>
> On why I dont want to provide my email address to Google:****
>
> Its a different email address which I dont want associated with this
> email address for various reasons. That is why I am not going to provide it.
> ****
>
> Your assumption that its a simple piece of information and requires no
> effort to give out is correct, but the impact of the association is
> unwanted.****
>
> The fact that Google can create a test account and reproduce the issue (as
> I have now done several times) tells me that they want the account
> information for some other purpose or that theyre just being lazy.****
>
> ** **
>
> And as for your last comment related to my initial point, its not my
> initial point. My initial point was that theres a problem and that Google
> should fix it or verify that this is the intended behavior.****
>
> I would expect an organization to be able to rig up some tests and sort it
> out in a week or so. If Google is doing that, then great.****
>
> ** **
>
> *From:* Thor (Hammer of God) [mailto:thor [at] hammerofgod]
> *Sent:* Saturday, May 19, 2012 10:29 AM
> *To:* Dan Kaminsky; Michael Gray
> *Cc:* full-disclosure [at] lists; Mike Hearn
> *Subject:* RE: [Full-disclosure] Google Accounts Security Vulnerability***
> *
>
> ** **
>
> I tried, and it didnt work (couldnt repro).****
>
> ** **
>
> None of this matters if you have username and password, you can check
> mail via POP3 or IMAP. Last time I checked, that was by design. If
> anyone is saying this is some sort of vulnerability because someone
> happens across your username and password then they are in the wrong
> business.****
>
> ** **
>
> Michael for you to make these claims, get Google involved, and post
> their replies here but refuse to give them your username (which will be on
> every email you send out) so they can troubleshoot is really a waste of
> time.****
>
> ** **
>
> Your initial point of even the big companies with teams of security
> experts have security vulnerabilities seems to shrink a bit when they
> illustrate concern with the issue yet you refuse to provide the simplest of
> information. I not sure what other expectations one would have of an
> organization. ****
>
> ** **
>
> *[.image: Description: Description: Description: Description: Description:
> Description: Description: Description: Description: TimSig]***
>
> * *
>
> *Timothy Thor Mullen*
>
> *www.hammerofgod.com*
>
> *Thors Microsoft Security Bible<http://www.amazon.com/Thors-Microsoft-Security-Bible-Collection/dp/1597495727>
> *
>
> ** **
>
> ** **
>
> *From:* full-disclosure-bounces [at] lists
> [mailto:full-disclosure-bounces [at] lists] *On Behalf Of *Dan
> Kaminsky
> *Sent:* Friday, May 18, 2012 1:03 PM
> *To:* Michael Gray
> *Cc:* full-disclosure [at] lists
> *Subject:* Re: [Full-disclosure] Google Accounts Security Vulnerability***
> *
>
> ** **
>
> Surely you can create a sock puppet for debugging purposes.****
>
> On Thu, May 17, 2012 at 11:43 AM, Michael Gray <mgray [at] emitcode> wrote:
> ****
>
> I'm not interested in providing that information. You can reproduce it
> without knowing my user name.****
>
> On May 17, 2012 8:45 AM, "Mike Hearn" <hearn [at] google> wrote:****
>
> If you provide the name of the account you're logging in to, we can go
> take a look what's happening.
>
> On Thu, May 17, 2012 at 5:29 PM, Michael Gray <mgray [at] emitcode> wrote:
> > Regardless of how you say it works, I can bypass it every time it would
> > seem. Again, by using the method in my original post. It's likely you
> have a
> > bug if this isn't the functionality you're after.
> >
> > I appreciate the statistics but they mean little to me.
> >
> > Thank you for taking the time to respond. I hope my suggestions and
> findings
> > will assist you in correcting these issues
> >
> > On May 17, 2012 5:51 AM, "Mike Hearn" <hearn [at] google> wrote:
> >>
> >> I understand your concerns, however they are not valid. You can be
> >> assured of the following:
> >>
> >> 1) We do not see this system as a replacement for passwords. If we
> >> block a login the user is notified and asked if it was them, if it
> >> wasn't we ask them to pick a new password. In very high confidence
> >> cases we will immediately force the user to choose a new password,
> >> because passwords are still the first line of defense.
> >>
> >> 2) We do not see this system as a replacement for 2-factor
> >> authentication. However the reality is that the vast majority of our
> >> users do not use 2-factor authentication and this is unlikely to
> >> change any time soon. 2SV imposes a significant extra burden on the
> >> user such that despite heavy promotion many users refuse to sign up,
> >> and of those that do, many choose to unenroll shortly afterwards.
> >> Therefore we also provide this always-on best effort system as well.
> >>
> >> 3) In fact it is very effective at stopping the large, botnet driven
> >> types of attacks we see on a daily basis and so saying it doesn't add
> >> any security is wrong. Since going live the system has successfully
> >> defended tens of millions of users who have a compromised password. A
> >> single unrepresentative data point based on one account isn't enough
> >> for you to judge the utility of the system, whereas we can clearly see
> >> the stopped campaigns (and drop in number of attempts).
> >>
> >> That said, if you have friends and relatives who use Google and you'd
> >> like to to make them more secure, by all means encourage them to set
> >> up two-factor authentication.
>
>
>
> --
>
> Mike Hearn | Senior Software Engineer | hearn [at] google | Account
> security team****
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/****
>
> ** **
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
|
image001.png
