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.

After the hack: A disposable Google Identity

Aside from the tedious task of reviewing and upgrading a large number of passwords, the biggest change I've made after my Google account was hacked is that I no longer enter my important credentials on untrusted devices. That includes any machine that lives in the virus and Trojan infested world of the XP based American corporation.

This is a bit of a pain. It would be less of a pain if my iPhone had a keyboard [1] and could drive an external display, but that's a few years away.

For now I'm taking a two step approach when I work with devices I don't control (non-OS X/iOS).

1. Using email as a transaction source.
2. Creating a disposable alter ego - a full gmail identity with limited privileges.

There's a lot of typing work I can do using email to "secret" addresses. I can mail tasks to Toodledo which in turn sync to Appigo's ToDo.app on my iPhone. I can mail drafts or posts to Blogger. I can mail invitations to my Gmail address that will turn into Calendar invites. I can't (yet) mail to Reader Shared Notes, but there are workarounds [2].

Of course a keystroke logger will capture these addresses, but there's no money in abusing these and the damage potential is pretty small.

The second task will be much easier when Google finishes the big project of integrating Google App identities with the Gmail/Google Account infrastructure. When that's done it will be easy to create disposable identities with shared access to calendar and contacts. That's many months away however, and based on some early testing a standard Google App account isn't quite good enough.

So for now I created a full Gmail account to serve as a disposable identity. It will have access to our family calendars and will have read/write (but not admin) access to my blogs but minimal access to Contacts. If I lose control of that account, I'll remove its privileges and walk away.

Annoying new world!

[1] I'm hoping to buy a kb like the one I used to use with my Palm Vx ten years ago, but I get the sense manufacturers are waiting for iOS 4.2.
[2] I mail to buzz.kateva.org which I follow in Reader. I Google Reader share from their.

Some podcasts in smart playlist won't sync to iPhone after 4.1 update

I am pretty sure this new 4.1 bug is related to an age old bug: Apple breaks Smart Playlists on iPhone and iTunes alike (yet again).

Some podcasts referenced in smart playlists won't sync to my iPhone after the 4.1 update. If I force them to sync by manually adding them to another list they appear in the smart playlist, but they appear in the wrong order. They appear first.

Looks like Apple doesn't understand the Smart Playlist bug. They fixed part of it, and broken another part.

My ScanSnap S1300 document scanner review

I bought this scanner because Joe Kissell loved it and Kissell is a good geek. By my standards it was a bit of a shot in the dark, but I'm happy. Even so, I only gave it 3 stars in my Amazon review -- the software is worse than Kissell described (he uses DevonThink Pro Office, $150, so he didn't get the full software experience).

Read the Kissell review, then my own Amazon review. I'll probably do some updating here later, but I wanted to get this out (emphases added) ...

Amazon.com: Customer Reviews: Fujitsu ScanSnap S1300 Instant PDF Sheet-Fed Mobile Scanner (PA03603-B005)

I've been looking for this scanner for 15 years. It's good enough. It could be better, but it's good enough. If it lasts for two years I'll happily buy it again at the same price.

The hardware is essentially perfect. It's a bit annoying that you need two USB cables if you want to avoid the generic (mediocre) power brick, but blame that on USB. We should all be using either old style firewire or never coming USB 3, but we're stuck with USB 2. It scans both sides of paper at once. Yes, DUPLEX.

Although it's primarily a document scanner, I've used it scan color prints. The results were not professional quality, but they were darned good and fast.

The 300 page user guide documentation is excellent.

The software is mediocre. Some of the bundled OS X software is so old it's non-native on Intel machines, fortunately you can omit that install. Unlike the higher end machines you don't get Adobe's superb PDF/OCR combination (yes, once Adobe was competent), you get a much less efficient product called ABBY FineReader. Even so, it does produce PDF images with searchable OCRd text indices.

Most importantly, OS X Spotlight WILL index the text associated with these PDF image files.

The mediocrity extends to the ScanSnap Manager UI and workflow. Clearly this was a low bid contract. Don't expect much in the way of upgrades or future products. The scans, however, can be sent to products like DevonThink Pro ($150) for processing.

The scanner uses proprietary drives. This is the biggest concern. If they're not upgraded we can be sure that within 3 years they won't work on OS X. Fujitsu, notoriously, does not provide new versions of ScanSnap Manager without a hardware purchase.

There are other problems with the software, but so far it hasn't been unstable.

In summary, 2 star software, 5 star hardware, gives a 3 star review. Surprisingly, I still love the product. If Apple were ever to produce a scanner, it would be a lot like this, though with a better power adapter and infinitely better software.

If you prefer 200K OCRd B&W documents to 8MB grayscale/color you need to set and use Profiles. The software isn't smart enough to make that choice for you.

It occupies a corner of my desk where papers used to pile up. It uses less room than the papers, which now live in the recycling.

Update 9/14/10: various notes I really don't have time to assemble into a coherent whole, but will be of interest if you read this far....

• There's a Carrying case offer
• Scan Snap Manager includes an online update option from the Help menu
• Uses a standard OS X Apple installer and documentation has clear uninstall directions
• 1.2GB installation - watch carefully for the custom install option and disable Cardiris (143MB, needs Rosetta, not useful). ABBY is 526MB, ScanSnap Manager is 2576MB
• Fujitsu sells consumables - cleaning kit, pad assembly (10,000 sheet or 1 year), Pick Roller 100,000 sheets or 1 year. Fujitsu is used to selling to the high end!
• 1 year warrantte, no active exchange
• Options like 1 page vs. multi-page are not obvious.
• You can change options for a single scan without clicking Aplly (which is actually save) but the progress UI shows the saved settings, not the current modified settins
• Profile Management has glitches with OS X Spaces and multiple monitors

Update 9/28/10: OS X black screened on me. First time in a very long time. SSM has to be #1 suspect.

Update 7/8/11: I can't recall what that 9/28/10 crash was, but it wasn't due to ScanSnap. Posting now because a comment on my Amazon review tells us Fujitsu has updated the S1300 drivers for Lion. Indeed, they seem to have updated all their current drivers. This was one of my concerns with the ScanSnap and I'm very pleased to see them do this. I'm not on Lion yet, so I'll hold off updating. I will download a copy however.

Update 4/14/2013: Today, after one mangled page too many, I decided this scanner was a bad idea. The sheet feeder simply isn't good enough.

Twitter feed for my Google Shared Items

Five months ago I started using twitterfeed to route my Google Shares to my (real name) personal twitter account. I pretty much forgot about it, I don't have much use for Twitter.

So I was surprised one day to discover people follow that twitter stream -- including people I know. A stream that has my (c) real name on it! A discoverable stream!

That won't do. The reason I changed all the names on my blog to my first and middle names (John Gordon) is so that my ideas and shares wouldn't be trivially discoverable. Trivial discovery is a poor match to my boring work life.

So today I created a duplicate Twitter feed for my Google Shared items -- as  John Gordon (jgordonshare).

If it keeps working I'll gradually promote that stream, and remind people following my true name Twitter feed to switch over. Then I'll turn off my true name stream.

Identity management is a subspecialization of reputation management.

-- My Google Reader Shared items (feed) (twitter)

After the Gmail hack - passwords and security

My Google (gmail) account was hacked. Interestingly, I've yet to discover any consequences.

My 58,000 email seem intact. There are no obvious changes to my documents. Passwords were not changed. Spam was not sent. Our financial accounts do not appear to have been hacked.

 It's curious.

So what am I doing differently?

I've always followed Schneier-approved security practices. That is I've calibrated my security measures to the value of what I was protecting, and balanced the cost and benefit of security. Since the hack I've not made any radical changes, but I have adopted somewhat more restrictive practices. I fear the cloud more than ever.

I have no reason to expect that my password database, stored in 1Password on my iPhone and dektop, and in a FileMaker 7 database on an encrypted disk image at home, was exposed, but of course control of my email account would facilitate password resets. I'm gradually going through passwords and updating those I care about. That's probably less than 30 of the 1,500 or so entries in my password database. A gmail search of my email for the string "password" did not find much of interest.

Here's what I do now:

1. I revised the passwords on my Gmail account (obviously) and all of our Google accounts. I used the free Password Assistant utility to invoke OS X password assistant to help choose good passwords. I use mostly "readable" passwords or, where needed, the number/letter options. I store these in two places - 1Password and FileMaker Pro [1].
2. I'm incrementally working through the passwords on all of our financial accounts. That's worth doing anyway. Fidelity used to require weak passwords, now they allow reasonably strong passwords. In one case that will go unnamed, their security remains appallingly weak. In several cases the security arrangements remain, essentially, insane.
3. We are storing less in Google documents. We didn't store much, but I'd considered putting some shared material in spreadsheets there.
4. I'm deleting email more. No sense keeping what I don't need. I might send myself a password to enter into my password database, but why keep that around?
5. I printed all password modified in the past two years for Emily and wrote on that directions on how to use the encrypted shares. That's non-electronic and stored in a secured place she controls. If I kick off, she has all she needs to get at the complete set - no passwords required.
6. I don't enter my Gmail/Google credentials on machines I don't control.

The last is the biggest change. It's doable now that I carry an iPhone around.

These are the changes I'm considering and will probably implement:

1. Move my email archives off Gmail. 58,000 emails is a rich attack surface. I may decide to keep only a few hundred emails there.
2. Create Google Apps/Gmail accounts that have limited access to things like my contacts, calendar, blogs and so on. Use these primarily, and limit use of my core Google account. Think of these as perimeter defense that can fall to the enemy.

[1] I don't trust 1Password completely, but there's no easy way to put FileMaker data on an iPhone in a robust encrypted store. So I end up using FMP as my source of truth, and 1Password more or less updates itself and serves as a backup. Both are included in my routine backups, including the encrypted backup I take offsite. I've used both of these for some time.

Update 9/13/10: xkcd on why having a robust password is not enough - creating honey pot services to attract passwords (Ping.FM?). iPhone/Android apps can do the same thing. This could be considered a form of social engineering/phishing. In my case I didn't reuse the Google password.

Operators in Windows Search and Spotlight - Common and Similar

This is a narrowcast post. It's of interest to someone who ...

1. Is a serious geek.
2. Has to routinely find things in very large document and email collections.
3. Uses both Windows Search (built into Vista/7, add-on for XP) and Spotlight for OS X.

If you're still reading we need to go out for a beer the next time you're in MSP. There are only 2-3 like us on earth.

In an earlier post I discussed operators in Spotlight. When I first posted I complained about the difficulty of reconciling Windows Search operators and Spotlight operators. It's tough enough to learn one set, but learning two is kinda painful.

My first impression was wrong though. It turns out that several operators work in both Spotlight and Windows Search. Below is a list of common operators, followed by a list of differing operators and conventions. I'll update both lists over time. I'm only including the ones I use, there are many more.

Common operators (work in both Windows Search and Spotlight)

• author:
• kind:folder
• kind:contacts
• kind:email
• kind:music
• date:>7/4/1776
• Boolean rules with parens (AND, OR, NOT)

Differing operators (W|S)

• Windows uses () to contain phrases, Spotlight uses quotes
• kind:docs | kind:document
• not available | kind:application
• modified:3/7/08..3/10/08 | modified:3/7/08-3/10/08 (hyphen might work in Win)

I think Windows Search accepts a number of variations, so I'm going to try more OS X Spotlight operators and syntax with Windows Search and document what works. Even now, however, it's impressive how much commonality there is.
--
My Google Reader Shared items (feed)