Google hack lessons - where the geek risks are

I've learned a lot about security risks since my My Google (gmail) account was (harmlessly?) hacked. I'm still learning, but I need to return to some of my recent posts and correct the mistakes I made.

Some impressions today ...

1. Google is not working this problem well. Their ownership authentication strategies smell of stale desperation [1]. Do they have corporate progeria?
2. The risks for non-geeks are different from the risks for geeks. We all know the non-geek risks: trivial passwords, dictionary attacks, phishing, etc.
3. The risks for geeks are password reuse, password capture and careless "secret question" password resets. "Strong" (high entropy) passwords don't help with any of these.
4. Password reuse risk comes from using the same password at multiple sites, one of which has weak security, or goes bankrupt and loses control of its data, or is a honeypot - either by design or by hack.
5. Password capture risk comes from virus/trojan keystroke loggers (esp. at work), browser exploits (esp. at hacked sites), and, potentially, fraudulent apps (desktop, iOS, Android).
6. Password reuse and password capture risks are synergistic.
7. Security (secret) questions have traditionally been considered a security risk created by companies with accelerated dementia (see also), but, in a world in which passwords may be too easily stolen, they might be a good idea, assuming Google keeps a history of security questions and answers. (We don't know if they do. I assume they do.)

For a geek then, risk mitigation involves

1. Do not ever enter your primary Google credentials on an untrusted platform. Never at work, never on an XP machine, never for a web site, never for an untrusted app. This means you need to create a secondary, personal, full Google account and grant it limited access to core Google services. The secondary account is used on untrusted platforms and is disposable.
2. Don't use OAuth and similar technologies. No, they don't store your high end credentials. The problem is the whole point of OAuth is using strong credentials with the OAuth provider, but then you can't use those credentials on untrusted platforms.
3. Don't reuse your high end (Google) credentials. This is a royal pain. Practically, it means you can only manage 2-3 high end memorized credentials (pattern based password versioning is high risk), so you can only have 2-3 high value services. Low value services get disposable passwords.
4. In the unlikely event that you own a phone that doesn't reveal your gmail address, consider signing up for text message password-reset.
5. Make the Security question your friend. Write your own question, and use either a passphrase you use nowhere else or just enter a GRC password. Write down the answer on paper and save it somewhere safe. Keep the question and answer in your encrypted iPhone password database.

I need to point out a few more things about the Security question [1]

1. If your account is hacked you need to change your Security question. Why? Think about it. You can't read it. You don't know if the person who had control of your account changed it. You can set it to what you meant it to be.
2. Since the Security question can be changed, we have to assume Google keeps a record of past responses. Otherwise it's worthless. On the other hand, if Google keeps a history of Security question/answer pairs then any weak Security question will be a problem forever.
3. Make your security question response an unguessable password or pass phrase. Don't reuse it, this is a special account. Put it on paper and in your encrypted iPhone password repository.

-- footnotes

[1] I'd like Google to provide a unique secret account identifier visible only to persons with password access. This can then be a form of identity claim, with none of the weakness of the Security question or the history problems. The hacker would know it, but so would the true owner.

Update 9/20/10: Ideas on how OpenID could be the solution, not the problem.