21

In the Atlantic article "Hacked!" it says:

My wife’s password was judged as “strong” when she first chose it for use with Gmail. But it was a combination of two short English words followed by numbers, so if it didn’t leak from some other site, it might just have been guessed in a brute-force attack. For reasons too complex to explain here, even some systems, like Gmail’s, that don’t allow intruders to make millions of random guesses at a password can still be vulnerable to brute-force attacks.

What vulnerability is the author referring to?

  • 10
    I think most likely the password was either guessed through social engineering, or stolen using keyloggers or other malware. You can't brute force without getting locked out unless either there's a bug in the lockout functionality, or you manage to steal Google's database of usernames and hashed passwords, both of which would be big news. – tlng05 Jun 12 '15 at 4:49
  • 8
    "so if it didn’t leak from some other site" is the key part here. It's very likely she re-used her password elsewhere and it got compromised. – Polynomial Jun 12 '15 at 9:17
  • The article mentions social engineering the paragraph prior to this one. – lloyd Jun 12 '15 at 10:52
32

For starters, that article misuses terminology.

Whatever vulnerability they may be referring to it seems pretty blatant that it is not "brute force" as that would contradict the premise of that very sentence. As another answer suggested it's possible that some form of social engineering was employed, but in this case any rounds of "guessing" left would not be brute force at all but would be cleverly leveraging known data points.

Additionally, it misidentifies the most likely security failure.

Altogether more likely in the case described in the article is a compromised database on another site. The article specifically allows for this when it says "if it didn’t leak from some other site", implying that his wife does not use unique passwords per site. If you don't use unique passwords1 then all bets are off and you cannot blame Google if you Gmail account is compromised2 that all your stuff is only as safe as the weakest site you use—a least-common-denominator approach that is bound to get you int trouble as for any given set of sites it is almost guaranteed that one of them has mishandled user data!

1. In addition to using unique passwords, enabling two-factor authentication would also mitigate against this attack vector.

2. Note again the terminology issue here. A compromised account (as in my usage) is different than a hacked account (as in the article's usage). In the most likely scenario the Gmail account was not hacked—no security measure at Google failed—the attacker was merely able to login with the password they hacked from somewhere else.

  • 6
    Oblig: XKCD: Password Reuse Password Entropy is rarely relevant. The real modern danger is password resuse. – WernerCD Jun 12 '15 at 14:01
4

Above that paragraph it says:

It’s possible, too, that my wife’s password was simply “guessed,” though in a different way from what laymen might assume. Guessing less often involves social engineering—trying your birthday or your hometown or your relatives’ names—than “brute-force attacks,”

Which is most likely what he was referring to.

In other words, although by most quantitative standards it's a strong password, it is actually made up of two easily guessed words and a number. An attacker might only need to try a few dozen combinations of home town, DOB, pets names, etc. to guess the password.

  • That excerpt is saying that guessing based on home town, etc. is less common than blind brute-forcing – Max Nanasy Jun 12 '15 at 22:29
2

It's true that attacks other than brute force might be mislabelled brute force, or that the author is talking about brute-forcing against a hashed password hypothetically stolen from Google (you'd very much hope they'd disclose if that happened and force password changes).

However, taking the claim at face value, is it true that:

For reasons too complex to explain here, even some systems, like Gmail’s, that don’t allow intruders to make millions of random guesses at a password can still be vulnerable to brute-force attacks.

The answer is a weak yes, they can be, but it's not an especially fruitful line of attack. It's to do with how "don’t allow intruders to make millions of random guesses" is actually implemented.

Google will (I assume) block you if you make too many failed login attempts from a single IP address. But will it lock an account if too many failed login attempts are made on it? ATMs do that, they eat your card if you get the PIN wrong three times. But in order to even make the attempt you have to have the card itself, so the only people who can do this are you or someone who took your card[*].

If Google were to lock your account after three failed login attempts from anywhere in the world, then there would be a trivial (albeit not typically devastating) DoS attack someone could make against Google accounts: just deliberately make a lot of failed login attempts. Anyone who knows your account name can do this, there's no physical token as a second factor. Thousands or millions of people need to go through the rigamarole and inconvenience of unlocking their account using a phone number or backup email address, or perhaps they lose their accounts entirely due to having no up-to-date second factor registered. This hasn't happened, so it can't be all that easy to get Google to lock someone's account.

I don't know what Google actually does about locking accounts that appear to be under attack, but it's certainly plausible that a system like GMail might tolerate quite a lot of nonsense before locking the account.

So, get yourself a botnet of a few million IP addresses, and you can make a relatively slow brute-force attack if you really want to. The more accounts you have to simultaneously work on, the less attempts you make on each account and the less likely each account is to get locked. Just don't make too many attempts per day from each IP address.

As to whether it's plausible that really happened to the author's wife, I doubt it. It's not a great use of a world-class botnet. But for a fairly weak password, two common English words followed by (let's say) a three-digit number, it's certainly possible that a massively distributed brute-force attack could find it, if someone chose to apply one. But this password is not in the "top thousand most common" that an attacker would run first against each account, before even starting on "two English words and three digits". It's far from the lowest-hanging fruit. So in that sense systems like this can still be vulnerable to a live brute force, but it's not a thing that really happens AFAIK. At any rate, I think it's worth the author sounding a note of caution that relying on a password of this form not to be brute-forced would be complacent, but FUD together with "this margin is too small to contain the proof" isn't ideal ;-)

Furthermore, Google doesn't actually let you log in from an arbitrary IP address any more: neither my hypothetical botnet nor the lads from Lagos described in the article, should be able to log in even if they have the password. Believe me, I've been bitten by this in the past trying to legitimately access Google's various APIs using my own account from virtual servers scattered about the place, never mind what would happen if I tried to use other people's accounts. So even given the risk of password guessing, Google does its best to have a further level of security.


[*] Or someone who cloned your card, if you live in one of those third-world type places that don't have Chip and Pin yet. But if you've cloned someone's credit card in those places, there's way more entertaining things you can do with it than mischievously get it blocked.

  • 1
    Blocking brute force attempts by IP address isn't accurate enough either. So captchas are used as well. An attacker and a legitimate user might come from the same /64 network. Blocking the entire /64 is going to block the legitimate user, but allowing other IP addresses in the /64 to keep going would allow the attacker to just use a new IP address for every request. Even if the entire /64 was blocked, it is not unlikely for an attacker to have access to an entire /48. Using IPv4 would be even worse because with CGN the server has even less information to tell user and attacker apart. – kasperd Jun 14 '15 at 13:35
  • If you only try once or twice, then wait a while, then try again. If you know the other person logs in inbetween these tries, it will reset the false tries. Using this method, brute force is not possible simply because of the limited tries per day or week, but if you know the owner, know the format of his password, then it could work. When succesful, the owner gets an email about a login from a new location, and this mail is sent to the recovery email address as well. – SPRBRN Jun 25 '15 at 8:59
  • 1
    @SPRBRN: right, the hack in question occurred in early 2011, so there's probably some conflation in my answer between how Google works now, and how the way it worked then might have applied to that hack, and what "some systems, like GMail's" do :-) They only recently started making a fuss about logins from unknown devices (including emailing the recovery address -- if the victim in question had one or more such emails then they'd have been less unsure what was going on). – Steve Jessop Jun 25 '15 at 9:24
  • Dont try brute forcing against google or any other production sites. It may be considered as Hacking and may be illegal by law where you are. If you are tracked down as doing this can cause you a lot of burn via the legal procedures. – pal4life Jun 21 '16 at 19:36
-1

With or without bruteforcing, When you logIn in the account in 5x tentatives with false password, the account Will blocked by WAF (Web Application Firewall) Google Security.

So if you change your IP or not, is the owner account only can re-activate it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.