The inPhonite Migration: Secure Data Management
Posted on | January 7, 2009 at 11:41 pm | 6 Comments
Arguably, the most important application on my old Palm T|X PDA is the secure password manager. Well, calendar and contacts is the raison d’etre of any PDA/smartphone, but it was the password manager that quickly became most surprisingly indispensable. I use it to store not only all my various passwords for website logins, but also credit card numbers, PINs, account numbers, ID numbers, combinations, and all sorts of personal information that I want secured. Before the PDA, I put all that info in a password-protected spreadsheet which I would print out and keep in my backpack. Not very secure!
The application I used for secure data management on the Palm was InfoSafe Plus. It came with a desktop version, so you could change/enter data on either the desktop or the PDA, and the data would get synced between the two of them. I also liked the fact that it had 10 different customizable fields (including a freeform notes field), which was more than similar applications. I delayed getting a password manager for the iPhone because I wanted to be sure I got the right one, that it would have all the features I wanted, and that I could easily import the data from InfoSafe. There is no iPhone version of InfoSafe currently, and I don’t see any indication from the developer that one is forthcoming. From what I can tell, there’s really only two real choices on the iPhone: SplashID and eWallet. A few months ago, I looked through the user manuals for both and did some experimenting with trial versions, and it looked like they were pretty similar but that it was slightly easier to import into SplashID. Although at this point I don’t really remember what was wrong with eWallet in that regard (not enough fields? fields not as customizable? didn’t import the right format?).
So that’s where things sat for awhile until recently when I decided it was time to get serious about switching over to the iPhone. Secure data management was the last major application that I had not migrated. I read the reviews and recalled my earlier research, and finally decided to go with SplashID. Besides the import issue, I think what tipped things against eWallet is I really don’t like the user interface, where it shows you your data on a simulated credit card (or whatever). I’m sure there’s a way to turn that off, but it just kind of struck me as a bell/whistle that looked cool but was ultimately useless and in the way. Plus, it seemed geared more towards credit cards and such, rather than passwords and secure info in general.
I finally took the plunge a few days ago and bought the SplashID iPhone client ($9.99) and the Windows desktop client ($19.99). You don’t have to buy the desktop, but I wanted it for the syncing/backup ability (it uses the iPhone’s WiFi for that) and for the ability to enter and change data using a real keyboard and a full screen. eWallet actually comes out ahead in the price category, since it’s desktop version is currently only $9.95 and the iPhone client is $9.99. Still, $30 isn’t too bad and is the price you pay for a lot of apps in the Palm world, which is what I’m used to.
Importing the data from InfoSafe to SplashID was even easier than I thought. InfoSafe will export a .csv file and SplashID will import one. They have the same number of fields. They both have a freeform notes field as field #10. Both programs have customizable labels for each field, which matched up pretty closely for the different data types (credit cards, bank accounts, insurance, web logins, etc). Even the names of those data type categories were pretty similar between the two, though I did have to go into the .csv file and modify them to match exactly (in general, SplashID uses plurals for the category names, while InfoSafe doesn’t). The one thing I didn’t like about the import function is that SplashID doesn’t actually import the customizable field names (i.e. “description”, “account #”, “username”, “password”, etc). InfoSafe will export those for each record along with the field values, so it’s a shame SplashID wouldn’t take them. But I found that most of the field names for the pre-defined categories that SplashID was using were pretty much the same as in InfoSafe anyway. But that was the only tweaking I had to do after the import – making sure the field names were correct. And I didn’t have to do that for the Web Login records, since those imported over exactly (site name/username/password/url). So really I just had to go through all the non-website records and make sure the field names were right. It did take me an hour or two, but it wasn’t too tedious.
So I’ve been using SplashID for a few days now and it’s really working well. It syncs up just fine with the desktop over WiFi, despite what some of the App Store reviewers say. I like that I don’t have to sync up with a website, since I don’t want my secure data out there in the cloud. I initially didn’t like the fact that it shows passwords/PINs/account numbers as masked on the iPhone until you touch it, but that feature has grown on me. It’s one more level of security. The desktop app also shows all passwords/PINs/account numbers as masked in the list view of all records, and then reveals them when you view/edit an individual record.
One negative of SplashID is the price, but like I said, I don’t think $30 is too unreasonable for everything it does. All of these applications have the data encrypted and require a password to run the app (on both the phone/PDA and the desktop). InfoSafe had an option to destroy the database if there was more than like 20 failed unlock attempts, which was kind of cool. SplashID doesn’t have that, and I think it should.
When I told my friend Pilto about this, he was incredulous and wondered why I needed a password manager at all and why I just didn’t use the same password for all my website logins (which is the bulk of the data) like he does. In my naive early days of Internet usage, that is what I did, but I quickly switched over to unique passwords. I don’t like using the same one everywhere because then if the password is discovered, it opens up not just one site to the potential criminal, but all of them. Which means having to change the password for every site. Plus, different sites have different password requirements (formats, forced changes, etc), which makes using the same one everywhere impractical. But even if I just used the secure data manager for non-website login info (currently 63 out of the 250 records), it would still be worth it to me. But I’m a junkie for organization!
Latre.
Songs That Came Up On The iPod While Exercising:
- “The Coventry Death Wish” (Dear Leader / Taxpayer)
- “When the Going Gets Dark” (Quasi)
- “Finns For Our Feet” (The Oranges Band)
- “Mother’s Pride” (The Beautiful South)
- “Payphone” (Tribe)
- “Temptation Eyes” (Blake Babies)
- “Sugar Fix” (Gutterball)
- “Lolita” (Elefant)
- “Blood” (Editors)
- “Arabian Sand” (The Coral)
- “Broken Breads” (The New Pornographers)
- “The Idiot on the Bike” (Aveo)
- “One Gun” (54-40)
- “[Untitled Track 18]” (Mind Reels)
Pet Peeve of the Day: Peak time at the gym (5-7 pm). Very crowded/noisy, and sometimes hard to get a machine!
Poignant Search Term Of The Day That Led To This Blog: “musica pass the green light but not go anywhere”.
Videogame(s) Played Since Last Blog Update: None!
Comments
6 Responses to “The inPhonite Migration: Secure Data Management”
January 8th, 2009 @ 10:47 am
Fear not about “peak time at the gym.” After the post-New Year’s Resolution rush, you’ll be able to go anytime without difficulties! Ditto for anyone signing up for Weight Watchers… in May or June, you’ll have no trouble finding a chair.
January 8th, 2009 @ 7:18 pm
Why not use a simple system? Generate each password using the initials of the name of the site, plus your birthdate (subtract 1 from each digit), and a keyword – so, for example, “FP0101dingus”. Easy to remember, easy to adapt to various password requirements, and easy to change.
Or better still, take a step back and ask yourself why you need 250 passwords… I bet there are successful identity thieves who don’t have that many!
January 8th, 2009 @ 7:58 pm
InfK: That sounds reasonable…except that “the name of the site” is often ambiguous. Take this site: is “FlasshePoint” one word or two? Or is the name just “flasshe.com”? Do articles count (is it “The New York Times” or just “New York Times”)?
My own system is that I have three levels of password, ranging from the one I use at sites that shouldn’t even be bothering with a password (such as, uh, The New York Times), to middling sites, to those that need high security. I have variations on each, in case a particular site requires some combination not allowed. Probably I have a total of six or seven passwords. Frankly, that seems plenty: the odds of someone both hacking a site to get your password *and* knowing what other sites you go to and using the same password seem pretty small (unless someone has set out to do exactly that, follows you, watches you and your laptop in binoculars, then mugs you and steals your laptop…but the odds of *that* seem even smaller).
The problem is that passwords need to be simultaneously memorable (to the user) but unguessable (to the hacker). The combination is inherently contradictory. My wife uses a sort of quasi-1337 alphanumeric alteration system, keyed to injokes she has with me, friends, etc.
January 8th, 2009 @ 8:08 pm
Why not use a simple system?
I do have a system, more or less, that helps me remember the passwords for different sites without having to look them up (usually). But the problem with any system is that if a hacker finds out one password for one site, he may be able to guess it for other ones. Although I don’t think that would happen in my case, since it could only very loosely be called a system, and I don’t even really stick to it as much as I used to.
And like 2fs, I use simpler ones for sites that don’t really matter.
Or better still, take a step back and ask yourself why you need 250 passwords…
No, the better question is why do I deal with 250 (actually 187) websites that need logins?
January 9th, 2009 @ 1:41 am
> except that “the name of the site” is often ambiguous
Oh, I know what you mean – but I’m not trying to set up a system that two people can agree on, I’m only doing it for use within my own head – and since *I* would decide that this site should be represented by “FP” then I’ll decide the same way 6 months later. If someone else prefers to call it “RB” (for R’s Blog), that’s not my problem.
In reality, I use a system similar to your 3-tier approach for the most part. My low-security password I can type almost with a single spasm of keystrokes, and it gets me into chatrooms and etc.
But the real problem is the USERNAMES – it’s rare for me to come across a site where my first initial and last name haven’t already been taken, and not uncommon even to see the first two initials and last name combo already in use! There are a few sites where I have to use my full, spelled-out name (including my bank) and so for that reason I have to keep track of passwords in a little text file.
January 9th, 2009 @ 7:17 am
But the real problem is the USERNAMES – it’s rare for me to come across a site where my first initial and last name haven’t already been taken, and not uncommon even to see the first two initials and last name combo already in use!
That’s true – I even have that problem with my name, which isn’t as common as yours. More and more sites are just using the e-mail address for the username these days though, so that’s not as much of an issue as it used to be. Although that does bring in a whole ‘nother issue if you have to change e-mail addresses. Some sites make it easier than others. Some you have to just start a whole new account.