The Highly Experimental Blog of Erik Rose

I Will Stab Password Management In The Face

Thu 11 April 2013

Today I made the monumental error of trying to authenticate myself to work.com. Half an hour, two email accounts, a pair of password databases, and a missing-in-action password-reset email later, I collapsed defeated. I will be emailing my quarterly feedback to my colleagues instead. I tell you, password management needs to be killed with a knife.

This is out of control.

I grant that passwords are an insufficiently strong form of authentication. In time, Persona might wipe them all—or at least the web-based ones—off the face of the earth, putting all our eggs in the baskets of our email providers (which has its own problems). But for now, I've got more password databases than a reasonable person might have passwords, and it's getting worse by the day. This moment, I have before me 3 databases: a commercial one containing 236 entries; a Mac Keychain with 458; and Firefox's, with another 270. This is only on a single computer, mind you; there are various half-synced, slowly diverging copies scattered about on other devices, and it is rare that a password pulled arbitrarily from any one of these works on the first try. The Keychain generously offers 6 or 7 duplicates for many accounts, and I have to manually scan the mod dates to have any hope of success. This is beyond insane.

How did we get into this mess?

The ideal place for password management is, of course, in the OS. There, it can…

  • Work across applications and protocols
  • Know when to evict encryption keys from RAM
  • Track which applications have access to which entries and guarantee the process hasn't been tampered with since access was granted

It also doesn't hurt to have the motivational nudge of the API provider behind a password storage standard.

Though Apple made a promising start with its Keychain, it has since squandered every inch of its lead in this space. Mobile Me provided Keychain syncing across machines (though of dubious accuracy and at an additional $100 per year). iCloud provides none. Older versions of 1Password stored their data in the Keychain's single-file format, which made syncing treacherous. Newer ones abandon it for a custom, multi-file format which can be synced more easily. The rats have left the ship, and my Keychain entries are noticeably moister each time I use them.

It is a shame that Apple has no apparent interest in bringing the Keychain up to snuff, as nothing else provides the smooth integration made possible by its privileged place in the OS. Firefox Sync, LastPass, and Persona are all limited to web-based passwords. And more general databases like 1Password and PasswordWallet are still cumbersome in their ability to remember and auto-fill non-web credentials: ssh, SFTP, wifi, mail, calendar, and encypted disk images. The world is more than the web.

The cross-platform curse

Because every third-party tool is decidedly more at home on one OS than the others, we end up in the insufferable position of being unable to edit our credentials on one device or another:

  • 1Password has been promising edit support on Android "real soon now" for years.
  • PasswordWallet has great iOS sync but none on Android.
  • KeePassX and LastPass take the diplomatic tack of looking and acting equally abhorrent on all OSes.

The way out

Since we clearly cannot rely on any single party to write a password manager to meet all needs…

  • Web and non-web
  • Syncing
  • First-class support on all platforms and devices

…the obvious answer is a standardized file format we can all share. The Agile Keychain is a pretty darn good swat in this direction. It's just JSON, encrypted with 128-bit AES. It stores one entry per file, so you can use simple tools like rsync to synchronize it. Nobody's claiming any patents on it, and Agile Bits has published a rather nice sketch of the spec.

Why aren't we keeping all our passwords in this?

Comments

What They Don’t Tell You Before You Move To Silicon Valley

Wed 27 March 2013

When you move to the Bay Area, people tell you “Rent is high!” and “Public transit exists!” But they don’t think to mention a lot of the day-to-day differences that take newcomers by surprise. I’ve been here a few years now, but some of the more striking ones are still fresh in my mind:

  • You have to shove gasoline nozzles in really hard, or gas won’t dispense. This is important to figure out quickly. I visited about five different stations and nearly emptied my tank before I realized the pumps weren’t broken—merely guarding against escaping vapors.
  • Most local shops welcome dogs. They indicate it by putting a water bowl out front.
  • Surfer speak like “right on” is unsurprising, but there’s also a trademark, rapid-fire “yeahyeah”, used to indicate casual agreement. I like it.
  • Cars don’t require yearly inspection, but you do need a “smog check” every two years. California doesn’t care if your brakes work or your wheels stay on, as long as your emissions are clean.
  • There are Bizarro World versions of various food products. Hellman’s mayonnaise doesn’t exist, but Best Value comes in a cosmetically identical jar. Twizzlers are replaced by Red Vines, a slightly waxier alternative. And when you say “skim milk”, you get quizzical looks. Ask for “fat-free”.
  • Winters are mild—you’ll love it—but many trees still shed their leaves. However, they simply turn brown and fall off; there’s no pyrotechnic detour through reds or yellows for any but a few. However, if you ask your native coworkers, they will wax poetic about the fall colors and tell you the exact coordinates of the one red tree in town.
  • Turn signals don’t work. My theory is that the lingering Reality Distortion Field bleeds the charge right out of the relays.

What about my fellow transplants? Got any more?

Comments

Function Names: To Verb Or Not To Verb?

Wed 20 March 2013

I thoroughly enjoyed Brandon Rhodes’ PyCon talk, The Naming of Ducks, at which he presented and justified a panoply of Python naming best practices, far beyond the mere spelling rules of PEP 8. Among his recommendations was a common one: name your functions as if they were verbs so you know what they do. create_database, polish_silverware, televise_revolution—all make fine function names, or so goes the conventional wisdom.

Except that I’ve almost entirely dropped this practice in the last few years.

My motivation has been simple and pragmatic: verbing a function means obscuring what it returns. What does create_database return? A connection object? The name of the database? Nothing at all? So, instead, I’ve actually taken to nouning my functions, as I care much less about what they’re doing—that’s an implementation detail I’m happy to abstract away—than what they return, which is the immediate concern at the call site. This also fits nicely into my style, which tends toward the functional:

(csv_file_reader(f) for f in files_from_zip(zip_path))

Oddly enough, function-nouning forms a neat corollary to one of Brandon’s other guidelines: naming variables to make clear their types. I’m a big fan of this: name an arg connection_seq or connection_map, and callers can probably guess what kind of data structure to pass in without reading any docs. Combine this with function-nouning, and you make two things automatically clear:

  • The nature of the return value
  • The information that factors into the function’s result—care of the nicely-named args you pass in

Thus, the input is clear, and the output is clear. In fact, the only thing that’s left a mystery is the process by which the function effects the input-to-output transformation, and I contend that’s of secondary importance: most of the time, I’m content just to have the output I need and don’t bother about the implementation. Isn’t that the entire point of abstracting functions to begin with?

What do you think? To verb or not to verb? Perhaps a more imperative style changes the tradeoffs, or maybe there are practical advantages in verbing that I’m not thinking of.

Comments

How to Really Reduce Greenhouse Gas Emissions

Mon 11 March 2013

My friend Fred recently got me thinking about environmental stewardship programs. Like Fred, I’m skeptical of a lot of consumer-targeting “be green” campaigns. As with hotels’ pleas to wash your towels less frequently, they are often corporate profit-boosting measures in altruistic clothing. No one ever offered me a room rate discount for using my towels a bit longer.

More generally, the “ride your bicycle” and “buy cloth shopping bags” crusades that dominate public consciousness are optimizing in the wrong places. In 2009, 16 ships burning essentially tar released as much atmospheric sulfur (the stuff that causes acid rain) as all the cars in the world.

As another example, about a quarter of greenhouse gas emissions are from electricity generation—26% in 2004. The U.S. is still 42% reliant on coal, the dirtiest fuel in common use. Coal releases over twice as much carbon dioxide as the next dirtiest fuel per kWH generated, natural gas. So, what we should be doing is running full-speed toward safe, clean nuclear. Even old generation-II reactors are 62 times less carbon-intense than coal. Modern generation-III reactors may be even lower. The entire transportation sector—including commercial interests driving big, dirty trucks—emits only 13% of greenhouse gases, and fixing that requires energy storage technology we don’t have, along with the coordination of millions of individuals and companies to purchase new equipment. This is not where to optimize.

While carting around reusable shopping bags and driving electric cars makes us feel good, it’s an awfully inefficient way to attack the problem. If you want to conserve the environment, write to your legislators instead. Campaign for cleaner shipping fuel standards. And welcome safe, modern nuclear plants into your back yard.

Comments

  • atom feed
  • github
  • twitter