I should be clear at the outset that 1Password is a fantastic product, and it’s not their fault I’m an idiot with weird edge-cases, OCD, myopia, et cetera. Nonetheless, there’s room for some amount of improvement in documentation and setting expectations through UI, here.
This article is about 1Password, and trying to stay freakishly organized in a complex world.
Declaring ‘login bankruptcy’ is tricky. It’s not like declaring e-mail bankruptcy, where the minimum necessary work is to label everything in your inbox, and then archive it. I’ve been using the 1Password for like five years now, and it’s full of all kinds of logins and crap that I’ll never need again. But this is misleading, right? Because every time you register an account online, one of a million things could happen.
If you have an insecure password, and then declare bankruptcy and forget all about it, the site could get hacked and then it really fucking needs to be on your radar again. If you registered an account during the free-love 2007 Rails era when every web programmer and their dog was creating site after site, then maybe the site itself has changed. Maybe they have a database with that old login somewhere, but now they want you to use OAuth. Maybe they’ve taken away the login-component of their site, and you have no idea if they still have your old credentials lying around on a hard drive somewhere. Maybe the site won’t allow you to delete your account. Maybe it’s too much of a fucking hassle to try.
So I was going to content myself with a ‘client-side’ bankruptcy. My plan had several facets:
- Let me find all the logins that use e-mails I’ll never be able to access again, and at least update those e-mail addresses so if something happens I’ll be notified.
- Let me take the 25% most insecure passwords in my 1Password vault, go to those sites and update them with something nice and stable, if they’ll let me.
- Then let me just archive my whole 1Password vault. Now this is important: it needs to be archived in such a way that as I go about the internet with my brand new empty vault, I can quickly and easily import all the passwords I need, with like, one click maximum.
So of course I did this with no research at all. I wrote this dumb little AppleScript to export 1Password logins to plain text. Each one, individually. Because I thought that was the only way to be able to import them selectively: by separating them into separate files. The AppleScript works great. Problem is, it doesn’t save all the information about the password in the file. Notably missing: the day the password was created, and the last date the password was modified. So that really sucks. What sucks worse is, after I tried to import a password back in, I realized that the CSV import requires the user to individually select the ‘meanings’ of the rows in the CSV file. And there’s less ‘meanings’ than fields that are exported from 1Password! For instance, here’s a fake CSV file (oh I guess it’s TSV, whatever):
title notes faveIndex securityLevel contentsHash htmlAction htmlName passwordHistory htmlMethod URLs username password URL/Location example.com 1000 SL5 08800990 http://example.com appleConnectForm post email@example.com secret-pw http://example.com
So there’s some interesting things that are saved, like the
securityLevel. The default is that all passwords require the master password. This can be changed: you can make passwords ‘low level’ security, requiring only a PIN code, or less, for mobile devices. I think. The security settings in 1Password 4 on iOS are confusing and interact in weird ways.
In any event, here are the sum total list of ‘meanings’ that must be manually assigned to the columns of a TSV file upon import:
Notice what’s not there? How about most of the columns that 1Password exported?
More importantly. When I use 1Password to preserve credentials with their browser extension, it doesn’t just save passwords. It saves all the HTML form fields it found the username and password inputs in. Here you can see how it’s captured the HTML input name and value for the submit button on a web form.
But those form fields don’t get saved into TSV format upon text file export. And even if they were, they couldn’t be imported back in. More importantly than that, 1Password allows you to add key-value pairs to the login after it gets created. I have stuff like my secret questions added to logins after the fact. but those additional key-value pairs don’t get saved into TSV format upon text file export, and even if they were, they couldn’t be imported back in.
And, finally, to add insult to injury: you can choose which rows in a TSV file you actually want imported into 1Password (making my AppleScript totally worthless). It even allows you to specify a folder name, and suggests one based on the file’s name. As fucking cool as that is, it’s less cool for a format that’s half broken on the way out and then completely mangled on the way in.
As for the 1Password Interchange Format, the metadata laden, thumbnail-preserving format designed specifically for import and export? You get no choice as to what logins you want imported upon selection, and you get no choice as to where the imported logins go: they simply appear in your global Logins vault, no folders or tags.
Oh well. At least restore from backup is fast.
I don’t want to give the impression that this is some kind of rant about 1Password. What I’m doing is feeling around the edges of a larger problem, the problem that’s plagued technology with insecure passwords, identity theft, and the search for some kind of Holy Grail in the form of OpenID/OAuth/Mozilla Persona/App-based logins. Yes, I would love it if 1Password could tell me when the last time was that I used a login. It would be even better if it counted every time I used one successfully. Maybe one day we could have some set of reliable internet error codes, and a common set of verbs to use on URLs, so that 1Password could even tell if a login was successful or not. But that’s crazy talk.
Technology has tendrils. Every time we register an account somewhere, we’re reaching out, and making some kind of connection. It’s not simple to recall those tendrils on a whim, and I question if it should be. I have no solutions of my own to offer. Decaying logins are an interesting thought (remember me for a week! I mean it!) but product owners are always going to want that big impressive database full of credentials. It’s a lifeline to e-mail accounts, marketing attempts, user preferences. Wanting a clean password database is not sufficient enough reason to upend the world trying to find a better solution. But it’s another reason, added to a growing list, of reasons why the status quo is unsatisfactory.