LastPass Authenticator, Cloud Backup, and you

I’m still not sure how it is that over the past two years I consider myself a big expert of 2FA, it probably has to do with having wanted to implement this for a very long time for the work I did before my current employer, and the fact that things keeps changing, and bad advices keep being sent out. But as it happens here is something more.

A couple of months ago, LastPass announced Cloud Backup for LastPass Authenticator, which effectively means you can upload your TOTP shared key (which is used for the generation of the one-time codes you see in the authenticator app) to LastPass so that you can log in on a different device (phone) and have access to all your previously set up 2FA credentials.

It’s marketed as a solution to the TOTP dance of changing devices which is always a definite pain in the neck, and it’s not alone. Authy (which many may know as the authentication system for Humble Bundle or Twilio) has a similar feature for their app. I have honestly wondered why Google Authenticator still does not have a similar feature either, but let’s not go there for now.

The obvious question that came to me, and probably to anyone with a little bit of security knowledge, when this was announced is «who in their sane mind would use this?». But before we get to that question, let me explain something that, it turns out, is not obvious to many people.

2-factor authentication, also referred to 2-step verification, – which refer to slightly different semantics but I’m not here splitting hairs – is the idea that you need “something you have” (or “something you have access to”) as well as “something you know”. Your username would be effectively the zeroth factor, followed by your password as first factor, and the magical second factor. For the most part at first the reference to this “something you have” related to physical devices, such as the RSA SecurID and other “tamper proof” tokens that display a one-time code, either changing every given amount of seconds or changing every time you pressed a button.

Nowadays, the majority of 2FA users use an authenticator app, such as the already mentioned LastPass Authenticator, Authy and Google Authenticator apps. These run on Android or iOS and provide TOTP-based one-time codes that are used for second factor authentication. These are not really as secure as one would like, and indeed they are still phishable. For proper security, services should really just use U2F.

So if you’re using an authenticator app, any authenticator app, you have your second factor, which is not the device itself! Rather, the second factor is the shared key, that the system gave you through the QR code (in most cases, at least), and that is combined with the current timestamp to give you a one time code (which is why it’s called TOTP: Time-based One Time Password). This is a very important distinction because, as I showed in a previous post, at least one of the services will not re-key the shared key when you set up authenticator on a new device, which means people with access to your old device still have your “factor”.

One obvious problem one might think of is that your phone is likely connected to your Google account, so if you have your authenticator on it, you may get an impression that factors 0, 1 and 2 are all on the same device. Of course that is not the case, because you can’t retrieve the password from a logged in Google account on a mobile device. In place of a password, a single-use token is provided (that is true not only for Google, but for almost every single app out there), which is tied to the device in some form. And that token effectively replaces both factors (password and TOTP). So you really have factors 0 and 2.

Why do I bring up this problem? Well, here’s the thing with LastPass: while all LastPass’s assurances are believable, and they may not have made huge mistakes with their authenticator app as they did for their extensions in the past, you have a basket with multiple eggs on it already, do you want to add all of them for real? Assume I put a TOTP key onto LastPass Authenticator with Cloud Backup, and the username and password for that account are also stored in LastPass, and that someone manages to log into my LastPass (how, that’s a different problem, but just assume they do). Now they have all three factors at their disposal.

Now it is true that LastPass forces you to use 2FA yourself for an account that has the Authenticator Cloud Backup enabled, but it is not clear to me if that means that you can’t use a physical YubiKey for that and whether the Cloud Backup would become unrestorable if you decide to disable 2FA, for instance because your device got stolen (in which case, well, you just lost all your 2FAs). Having had to disable 2FA for LastPass once already (I was in China without my main Authenticator device), it effectively relies on you having access to your registered email address… which for someone who may gain access to my LastPass password, would probably be a cakewalk. It’s also not clear to me whether having the ability to request arbitrary information from the extension (as Tavis managed to do at least once) would allow you to fetch the Cloud Backup shared keys too. In which case, the whole security sandcastle is gone.

An astute reader could ask why am I even considering this a valid option and spending my time figuring out how insecure this is. The answer to that is a bit complicated but I’ll still talk about my reasoning. 2FA is good, and everybody should be using it. On the other hand, 2FA is also cumbersome and it feels it’s not worth the hassle. For services that support U2F, it’s very very easy: you just register a couple of U2F devices (e.g. one you keep at home in a safe, and one you keep with your housekeys), and you would have access to at least one at any time. Minimal amount of work needed, major security.

But would you really do the TOTP registration dance I talked above for things like (and I’m checking my own history here), IFTTT? Maybe, but probably not. It’s more likely that you decide that for those, it’s easier to get SMS as second factor, and you prove you have access to your phone number. Unfortunately this is both a problem, for instance when you fly a lot. It’s also not secure at all, as people have by now repeatedly demonstrated, both because intercepting SMS is getting more and more trivial, and because lots of telcos can be easily manipulated into giving up access to a phone number, particularly in the US, where the phone is tied to a device, rather than to a SIM card.

I also do something like this, except the phone number is a Google Voice number (similar to Google Project Fi), which makes it easier for me to receive the codes wherever I am in the world, and also to receive them when I’m only connected to the Internet and not to cell service. And since my Google account is protected by U2F, and the password is not in LastPass, I feel safe… enough for most of the smaller services. But not all the services allow me to send the code to Google Voice (some of the bridges still fail there), so I have been hoping for some cloud backup option to at least have an easy way to move around a subset of my TOTP shared keys.

Because accounts like EA, AutoDesk (I have no licenses for them) or WordPress (I have no sites there), are probably low-targets enough that I wouldn’t mind using an imperfect (security-wise) solution such as LastPass Authenticator Cloud Backup… except if it defeated the whole purpose of 2FA, which it clearly does, when their password is also there. This is funny because it means I’d feel safer to keep a copy of my Google account TOTP key in LastPass as its password is not in LastPass.

As I noted above, Authy does have something like that as well. Their main API, used by Humble Bundle and Twitch, relies on server-side hosting of the keys, with extra seeds that are given to each device if you install their app and use it. Setting up an account is trivial as it relies on a phone number as username and a one-time code they send to that phone number — effectively it’s a single factor authenticator. This does mean that its base security is not any better than the security of an SMS. Which makes it hardly useful, except for being easier to access when you somehow have no access to SMS. Or, as Twitch will tell you, to “cut down on those expensive SMS” — yeah I always forget in the US you pay to receive text messages. Strange country.

So while I don’t think Authy is a very sensible or secure option, as it has the same vulnerability as SMS do, their system does have an option to backup your TOTP shared keys, which includes an extra password in addition to the SMS auth. Of course by virtue of what I Was saying earlier, you should not be storing that password in LastPass, or you’ll have put effectively one basket into the other.

What does this mean at the end of day? Well, it’s obvious people are finding 2FA hard, and they want to provide better solutions that still work for users and allow them to be protected by 2FA. Unfortunately it does not seem the current options available, except for U2F are very secure or reliable, and U2F is far from widespread.

My personal perfect end state would be for websites to allow me to log in based on Facebook or Google account, the passwords of which are not stored in LastPass, and then asking me for a 2FA token that could be stored in LastPass then. In that case, LastPass would still only have one factor, same as they do right now with the password, but since the first factor is not “password” but “access to {other} account”, that is one less thing to keep in mind.

We’ll see what the future brings ups.

LastPass got hacked, I’m still okay with it

So LastPass was compromised and so they report. I’m sure there are plenty of smug geeks out there, happy about users being compromised. I thought that this is the right time to remind people why I’m a LastPass user and will stay a LastPass user even after this.

The first part is a matter of trust in the technology. If I did not trust LastPass enough to not have easy access to the decrypted content, I wouldn’t be using it to begin with. Since I do not trust the LastPass operators, even in the case the encrypted vault were compromised (and they say they weren’t), I wouldn’t be worrying too much.

On the other hand I followed the obvious course of not only changing the master password, and change the important passwords just to be paranoid. This is actually one good side of LastPass — changing the passwords that are really important is very easy as they instrument the browser, so Facebook, Twitter, Amazon, PayPal, … are one click away from a new, strong password.

Once again, the main reason why I suggest tools such as LastPass (and I like LastPass, but that’s just preference) is that they are easy to use, and easy to use means people will use them. Making tools that are perfectly secure in theory but very hard to use just means people will not use them, full stop. A client-side certificate is much more secure than a password, but at the same time procuring one and using it properly is non-trivial so in my experience only a handful of services use that — I know of a couple of banks in Italy, and of course StartSSL and similar providers.

The problem with offline services is that, for the most part, don’t allow good access while from phones, for instance. So you end up choosing, for things you use often from the phone, memorable passwords. But memorable passwords are usually fairly easy to crack, unless you use known methods and long password — although at least it’s not the case, like I read on Arse^H recently, that since we know the md5 hash for “mom”, any password with that string anywhere is weakened.

Let’s take an example away from the password vaults. In Ireland (and I assume UK simply because the local systems are essentially the same in many aspects), banks have this bollocks idea that is more secure to ask for some of the characters of a password rather than a full password. I think this is a remnant of old bank teller protocols, as I remember reading about that in The Art of Deception (good read, by the way.)

While in theory picking a random part of the password means a phishing attempt would never get the full password, and thus won’t be able to access the bank’s website unless they are very lucky and get exactly the same three indexes over and over, it is a frustrating experience.

My first bank, AIB, used a five-digits PIN, and then select three digits out of it when I log in, which is not really too difficult to memorize. On the other hand, on their mobile app they decided that the right way to enter the numbers is by using drop-down boxes (sigh.) My current bank, Ulster Bank/RBS, uses a four digits pin, plus a variable length password, which I generated through LastPass as 20 characters, before realizing how bad that is, because it means I now get asked three random digits off the four… and three random characters of the 20.

Let that sink in a moment: they’ll ask me for the second, fifth and sixteenth character of a twenty characters randomly generated password. So no auto-fill, no copy-paste, no password management software assisted login. Of course most people here would just not bother and go with a simple password they can remember. Probably made of multiple words of the same length (four letters? five?) so that it becomes easy to count which one is the first character of the fourth word (sixteenth character of the password.) Is it any more secure?

I think I’ll write a separate blog post about banks apps and website security mis-practices because it’s going to be a long topic and one I want to write down properly so I can forward it to my bank contacts, even though it won’t help with anything.

Once again, my opinion is that any time you make security a complicated feature, you’re actually worsening the practical security, even if your ideas are supposed to improve the theoretical one. And that includes insisting on the perfect solution for password storage.

My thoughts on the Self-Hosting Solution

You probably noticed that in the (frequent) posts talking about security and passwords lately, I keep suggesting LastPass as a password manager. This is the manager that I use myself, and the reason why I came to this one is multi-faceted, but essentially I’m suggesting you use a tool that does not make it more inconvenient to maintain proper password hygiene. Because yes, you should be using different passwords, with a combination of letters, numbers and symbols, but if you have to come up with a new one every time, then things are going to be difficult and you’ll just decide to use the same password over and over.

Or you’ll use a method for having “unique” passwords that are actually comprised of a fixed part and a mobile one (which is what I used for the longest time). And let’s be clear, using the same base password suffixed with the name of the site you’re signing up for is not a protection at all, the moment more than one of your passwords is discovered.

So convenience being important, because inconvenience just leads to bad security hygiene, LastPass delivers on what I need: it has autofill, so I don’t have to open a terminal and run sgeps (like I used to be) to get the password out of the store, it generates the password in the browser, so I don’t have to open a terminal and run pwgen, it runs on my cellphone, so I can use it to fetch the password to type somewhere else, and it even auto-fills my passwords in the Android apps, so I don’t have to use a simple password when dealing with some random website that then patches to an app on my phone. But it also has a few good “security conveniences”: you can re-encode your Vault on a new master password, you can use a proper OTP pad or a 2FA device to protect it further, and they have some extras such as letting you know if the email you use across services are involved in an account breach.

This does not mean there are no other good password management tools, I know the name of plenty, but I just looked for one that had the features I cared about, and I went with it. I’m happy with LastPass right now. Yes, I need to trust the company and their code a fair bit, but I don’t think that just being open source would gain me more trust. Being open source and audited for a long time, sure, but I don’t think either way it’s a dealbreaker for me. I mean Chrome itself has a password manager, it just feels not suitable for me (no generation, no obvious way to inspect the data from mobile, sometimes bad collation of URLs, and as far as I know no way to change the sync encryption password). It also requires me to have access to my Google account to get that data.

But the interesting part is how geeks will quickly suggest to just roll your own, be it using some open-source password manager, requiring an external sync system (I did that for sgeps, but it’s tied to a single GPG key, so it’s not easy for me having two different hardware smartcards), or even your own sync infrastructure. And this is what I really can’t stand as an answer, because it solves absolutely nothing. Jürgen called it cynical last year, but I think it’s even worse than that, it’s hypocritical.

Roll-your-own or host-your-own are, first of all, not going to be options for the people who have no intention to learn how computer systems work — and I can’t blame them, I don’t want to know how my fridge or dishwasher work, I just want them working. People don’t care to learn that you can get file A on computer B, but then if you change it on both while offline you’ll have collisions, so now you lost one of the two changes. They either have no time, or just no interest or (but I don’t think that happens often) no skill to understand that. And it’s not just the random young adult that ends up registering on xtube because they have no idea what it means. Jeremy Clarkson had to learn the hard way what it means to publish your bank details to the world.

But I think it’s more important to think of the amount of people who think that they have the skills and the time, and then are found lacking one or both of them. Who do you think can protect your content (and passwords) better? A big company with entire teams dedicated to security, or an average 16 years old guy who think he can run the website’s forum? — The reference here is to myself: back in ²⁰⁰⁰⁄₂₀₀₁ I used to be the forum admin for an Italian gaming community. We got hacked, multiple times, and every time it was for me a new discovery of what security is. At the time third-party forum hosting was reserved to paying customers, and the results have probably been terrible. My personal admin password matched one of my email addresses up until last week and I know for a fact that at least one group of people got access to the password database, where they were stored in plain text.

Yes it is true, targets such as Adobe will lead to many more valid email addresses and password hashes than your average forum, but as the “fake” 5M accounts should have shown you, targeting enough small fishes can lead to just about the same results, if not even better, as you may be lucky and stumble across two passwords for the same account, which allows you to overcome the above-mentioned similar-but-different passwords strategy. Indeed, as I noted in my previous post, Comic Book Database admitted to be the source of part of that dump, and it lists at least four thousand public users (contributors). Other sites such as MythTV Talk or PoliceAuctions.com, both also involved, have no such statement ether.

This is not just a matter of the security of the code itself, so the “many eyes” answer does not apply. It is very well possible to have a screw up with an open source program as well, if it’s misconfigured, or if a vulnerable version don’t get updated in time because the admin just has no time. You see that all the time with WordPress and its security issues. Indeed, the reason why I don’t migrate my blog to WordPress is that I won’t ever have enough time for it.

I have seen people, geeks and non-geeks both, taking the easy way out too many times, blaming Apple for the nude celebrity pictures or Google for the five million accounts. It’s a safe story: “the big guys don’t know better”, “you just should keep it off the Internet”, “you should run your own!” At the end of the day, both turned out to be collections, assembled from many small cuts, either targeted or not, in part due to people’s bad password hygiene (or operational security if you prefer a more geek term), and in part due to the fact that nothing is perfect.

Make password management better

When I posted my previous post on accounts on Google+ I received a very interesting suggestions that I would like to bring to the attention of more people. Andrew Cooks pointed out that what LastPass (and other password managers) really need, is a way to specify the password policy programmatically, rather than crowdsourcing this data as LastPass is doing right now.

There are already a number of cross-product specifications of fixed-path files used to describe parameters such as robots.txt or sitemap.xml. While cleaning up my blog’s image serving I also found that there is a rules.abe file used by the NoScript extension for Firefox. In this optic, adding a new password-policy.txt file to define some parameters for the password policy of the website.

Things like the minimum and maximum length of the password, which characters are allowed, whether it is case sensitive or not. These are important information that all the password managers need to know, and as I said not all websites make it clear to the user either. I’ll recount two different horror stories, one in the past and one more recent, that show how that is important.

The first story is from probably almost ten years ago or so. I registered with the Italian postal service. I selected a “strong” (not really) password, 11 characters long. It was not really dictionary-based, but it was close enough if you knew my passwords’ pattern. Anyway, I liked the idea of having the long password. I signed up for it, I logged back in, everything worked. Until a few months later, when I decided I wanted to fetch that particular mailbox from GMail — yes, the Italian postal service gives you an email box, no I don’t want to comment further on that.

What happens is that the moment I tried to set up the mail fetching on GMail, it kept failing authentication. And I’m sure I used the right password that I’ve insisted using up to that point! I log in on the website just fine with it, so what gives? A quick check at the password that my browser (I think Firefox at the time) think is the password of that website shows me the truth: the password I’ve been using to log in does not match the one I tried to use from GMail: the last character is not there. Some further inspection of the postal service website shows that the password fields, both in the password change and login (and I assumed at the time the registration page for obvious reasons), set a maxlength value to 10. So of course, as long as I typed or pasted the password in the field, the way I typed it when I registered, it worked perfectly fine, but when I tried to login out of band (through POP3) it used the password as I intended, and failed.

A similar, more recent story happened with LastMinute. I went to change my password, in my recent spree of updating all my passwords, even for accounts not in use (mostly to make sure that they don’t get leaked and allow people to do crazy stuff to me). My default password generator on LastPass is set to generate 32-characters passwords. But that did not work for LastMinute, or rather, it appeared to. It let me change my password just fine, but when I tried logging back in, well, it did not work. Yes, this is the reason that I try to log back in after generating the password, I’ve seen that happening before. In this case, the problem was to be found in the length of the password.

But just having a proper range for the password length wouldn’t be enough. Other details that would be useful are for instance the allowed symbols; I have found that sometimes I need to either generate a number of passwords to find one that does not have one of the disallowed symbols but still has some, or give up on the symbols altogether and ask LastPass to generate only letters and numbers. Or having a way to tell that the password is case sensitive or not — because if it is not, what I do is disable the generation of one set of letters, so that it randomises them better.

But there is more metadata that could be of use there — things like which domains should the password be used with, for instance. Right now LastPass has a (limited) predefined list of equivalent domains, and hostnames that need to match exactly (so that bugs.gentoo.org and forums.gentoo.org are given different passwords), while it’s up to you to build the rest of the database. Even for the Amazon domains, the list is not comprehensive and I had to add quite a few when logging in the Italian and UK stores.

Of course if you were just to tell that your website uses the same password as, say, google.com, you’re going to have a problem. What you need is a reciprocal indication that both sites think the other is equivalent, basically serving the same identical file. This makes the implementation a bit more complex but it should not be too difficult as those kind of sites tend to at least share robots.txt (okay, not in the case of Amazon), so distributing one more file should not be that difficult.

I’m not sure if anybody is going to work on implementing this, or writing a proper specification for it, rather than a vague rant on a blog, but hope can’t die, right?

Anatomy of a security disaster

I have made a note of this in my previous post about Magnatune being terribly insecure. Those who follow me on Twitter or Google+ already got the full details of it but I thought I would repeat them here. And add a few notes about that.

I remember Magnatune back in the days in which I hang around #amarok and helped with small changes here and there, and bigger changes for xine itself. It was at the time often used as an example of good DRM-less services. Indeed, it sold DRM-free music way before Apple decided to drop its own music DRM, and its still one of the few services selling lossless music — if we exclude Humble Bundle and the games OSTs.

But then again, this is not a license to have terrible security, which is what Magnatune has right now. After naming Magnatune in my the aforementioned post I realized that I had not given it a new, good password but it’s instead still using one of the old passwords I used to use, which are both insecure by themselves, a bit too short, possibly suitable to dictionary attacks, and I was not even sure if it was using the password I used by default on many services before, which is of course terrible, and was most likely leaked at multiple points in time — at least my old Adobe account was involved in their big leak.

As I said before, I stopped using fixed passwords some time last year, and then I decided to jump on LastPass when Heartbleed required me to change passwords almost everywhere. But it takes a while to change passwords in all your accounts, especially when you forget about some accounts altogether, like the Magnatune one above.

So I went to Magnatune website to change my password, but of course I forgot what the original was, so I went on and decided to follow the procedure for forgotten passwords. The first problem happens here: it does not require me to know which email address I registered with, instead it asks me (alternatively) for an username, which is quite obvious (Flameeyes, what else? There are very few sites where I use different usernames, one of which being Tumblr, and that’s usually because Flameeyes is taken). When I type that in, it actually shows me on the web page the email address I’m registered with.

What? This is a basic privacy issue: if it wasn’t that I actually don’t vary my email addresses that much, an attacker could now find an otherwise private email address. Worse yet, by using the users available in previous dumps, it’s possible to assign them to email addresses, too. Indeed, A quick check provided me with at least one email address of a friend of mine by just using her usual username — I already knew the email address but that shouldn’t be a given.

Anyway, I got an email back from Magnatune just a moment later. The email contains the password in plain text, which indicates they store it that way, which is bad practice. A note about plain text passwords: there is no way to prove beyond any doubt that a service is hashing (or hashing and salting) user passwords, but you can definitely prove otherwise. If you receive your password back in plain text when you say you forgot it, then the service does not store hashed passwords. Conversely, even if the service sends you a password reset link instead, it’s still possible it’s storing the plain text password. This is most definitely unfortunate.

Up to here, things would be bad but not that uncommon, as the linked Plain Text Offenders site above would show you — and I have indeed submitted a screenshot of the email to them. But there is one more thing you can find out from the email they sent. You may remember that some months ago I wrote about email security and around the same time so did the Google Official blog – for those who wonder, no I had no idea that such a post was being written and the similar timing was a complete coincidence – so what’s the status of Magnatune? Well, unfortunately it’s bleak, as they don’t encrypt mail in transit:

Received: from magnatune.com ([64.62.194.219])
        by mx.google.com with ESMTP id h11si9367820pdl.64.2014.08.28.15.47.42
        for <f********@*****.***>;
        Thu, 28 Aug 2014 15:47:42 -0700 (PDT)

If the sending server spoke TLS to the GMail server (yes it’s gmail in the address I censored), it would have shown something like (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); (which appears in the comment messages I receive from my own blog).

Not encrypting the email in transit means that anybody that could have sniffed the traffic coming out of Magnatune’s server would be able to access any of their customers’ accounts: they just need to snoop the email traffic and they can receive all the password. Luckily, the email server from which the email arrived is hosted at a company I trust very much, as I’m their customer too.

So I tried logging in with my username and newly-reminded password, unfortunately my membership expired years ago, which means I get no access at all — so I can’t even change my password or my email address. Too bad. But then it allowed me to figure out some more problems with the security situation of Magnatune.

When you try to login, you get sent on a different website depending on which kind of membership you subscribe(d) to. In my case I got the download membership — when you go there, you get presented with a dialog requesting user and password from your browser. It’s standard HTTP based authentication. It’s not very common because it’s not really user friendly: you can’t serve any content until the user either puts the right username/password or decides they don’t know a valid combination and cancel the dialog, in which case a final 401 error is reported, and whichever content the server sent will be displayed by the browser.

Beside the userfriendliness (or lack thereof), HTTP authentication can be tricky, too. There are two ways to provide authentication over HTTP, one is Basic and the other is Digest — neither is very secure by default. Digest is partially usable, but suffer from lack of authentication of parties, making MitM attacks trivial, while Basic, well, allows a sniffer to figure out username and password as they travel in plaintext over the wire. HTTP authentication is, though, fairly secure if you use it in conjunction with TLS. Indeed for some of my systems I use HTTP authentication on a HTTPS connection, as it allows me to configure the authentication at the web server level without support from the application itself.

What became obvious to me while failing to log in to Magnatune was that the connection was not secure: it was cleartext HTTP that it was trying to get me to log in through. So I checked the headers to figure out which kind of authentication it was doing. At this point I have to use “of course” to say that it is using Basic authentication: cleartext username and password on the wire. This is extremely troublesome.

While not encrypting email reduces the attack surface, making it mostly a matter of people sniffing at the datacenter where Magnatune is hosted – assuming you use an email provider that is safe or trustworthy enough, I consider mine so – using basic authentication extend the surface immensely. Indeed, if you’re logging in Magnatune from a coffee shop or any other public open WiFi, you are literally broadcasting over the network your username and password.

I can’t know if you can change your Magnatune password once you can log in, since I can’t log in. But I know that the alternative to the download membership is the streaming membership, which makes it very likely that a Magnatune user would be logging in while at a Starbucks, so that they can work on some blog post or on source code of their mobile app while listening to music. I would hope they used a different password for Magnatune than for their email address — since as I noted above, you can get to their email address just by knowing their username.

I don’t worry too much. My Magnatune password turned out to be different enough from most of my other passwords that even if I don’t change it and gets leaked it won’t compromise any other service. Even more so now that I’m actively gathering all my account and changing their passwords.

Heartbleed and SuperGenPass

After an older post of mine a colleague pointed out SuperGenPass to generate different passwords for each service out there from a single master password and the domain name in use. The idea was interesting, especially since it’s all client-side, which sounded very appealing to me.

Unfortunately, it didn’t take long for me to figure out a few limitations in this approach; the most obvious one is of course Amazon: while nowadays the login page even for Audible is hosted at the amazon.com domain, the localized stores still log in on, e.g., amazon.co.uk, but with the same password. Sure it’s easy to fix this, but it’s still a bit of a pain to change every time.

Also, at least the Chrome extension I’m using, makes it difficult to use different passwords for different services hosted at the same domain. You have an option to enable or disable the subdomain removal, so if you disable it, you’ll get different passwords for http://www.example.com and example.com (unlikely to be what you want) while if you enable it, you’ll get the same password for forums.gentoo.org and bugs.gentoo.org (which is not what I want). Yes you can fix it on a per-service basis, but it adds to the problem above.

The last bother in the daily usage of the extension, has been with special characters. SuperGenPass does not, by default, use any special characters, just letter (mixed case) and numbers. Which is perfectly fine, unless you have a website that stupidly insists on requiring you to use symbols as well, or that requires you to use (less stupidly) longer or (insanely stupidly) shorter passwords. You then have to remember.

All three of these complains mean that you have to remember some metadata in addition to the master password: whether you have to change the domain used, whether you’re using subdomain removal or not for that particular service, and whether you have to change the length, or add special characters. It partly defeats the purpose of having a fully stateless hashing password generator.

There is also one more problem that worried me much more: while it makes it so that a leak from a single website would leak your base password for everything else, it does not entirely make it impossible. While there’s no real way to tell that someone is using SuperGenPass, if you’re targeting a single individual, it’s not impossible to tell; in particular, you now know I’ve been using SGP for a while, so if a password for an account named Flameeyes gets leaked, and it looks like an SGP password, it’s a good assumption that it is. Then, all you need to do is guess the domains that could be used to generate the password (with and without subdomain removal), and start generating passwords until you get to the master password used to generate that particular site password. Now you just need to have an educated guess to the domain you’re going to try login as me, and you’re done. And this is with me assuming that there is no weakness in the SGP algorithm — crypto is honestly too hard for me.

And now there is heartbleed — go change all your passwords, starting from xine. But how do you change your passwords when you have them generated? You have to change your master password. And now you have to remember if you changed the password for a given service already or not. And what happens if one of the services you’re using has been compromised before, such as Comixology? Now you have three different master passwords, if not more, and you’re back to square one, like SGP was never used.

So with all this considered, I’ve decided to say goodbye to SGP — I still have a few services that have not been migrated – but not those that I’ve named here, I’m not a moron – but I’m migrating them as I got. There are plenty of things I forgot I registered to at some point or another that have been mailing me to change their password. I decided to start using LastPass. The reason was mostly that they do a safety check for heartbleed vulnerabilities before you set up your passwords with them. I was skeptical about them (and any other online password storage) for a long time, but at this point I’m not sure I have any better option. My use of sgeps is not scalable, as I found out for myself, and the lack of 2FA in most major services (PayPal, seriously?) makes me consider LastPass as the lesser evil for my safety.