This Time Self-Hosted
dark mode light mode Search

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.

Comments 6
  1. TOTP stored with your password still offers some protection. If you were using a password but not two-factor, then in the event the network between you and the service to which you’re authenticating (or even the server on the remote end but not its database) is compromised, you would have lost complete control of your account. Using TOTP, you’ve lost your password and a single access code – but you have NOT given the attacker the ability to log into your account again in the future, since only a single OTP crossed their compromised network link. The secret stayed in LastPass and was never sent over the compromised wire.I agree, you lose quite a lot of what 2FA is supposed to provide, but I don’t think it’s accurate to say that you get “no” additional security from using TOTP with its secret stored right next to your password. It’s really just “security reduced from full 2FA to just the benefits of using Challenge-Response instead of silly send-me-the-password protocols”.

  2. That is a fair point. There is also the fact that a password manager and a backed up TOTP key are still better than password alone: if the site itself leaks the password, an attacker would still not have access to your account, despite knowing your password.So the question becomes which target is more likely, and what the alternatives are. I don’t really consider no TOTP not an option :)But yup, thanks for bringing that up.

  3. On the Security Now podcast they peridically point out that second factors should not be exportable, and that GA does it right. Now, they are often hugely incompetent on several subjects (e.g. recently claimed that their own solution was the first and only unphishable second factor, which is nonsense of a pretty much OpenBSD level), but it makes it easy to reason about your second factor if it’s not cloneable/migratable.Same with TPM. If they key is not migratable off of TPM, then it’s not. If it is migratable then there’s an “if” there, if someone has the owner password (Windows sets owner password to random bytes and then forgets it).I’m the de facto maintainer of the opensource version of GA, so can say there are three reasons why the opensource fork of GA doesn’t have export functionality:1) I don’t have time to implement it2) I’ve not heard of a way to implement this that I’d be happy with3) Despite being the de facto maintainer, I don’t know Android development, or really Java either. 🙂 (I was interested in the PAM module)Also see https://github.com/google/g

  4. Yeah I ended up dividing my services into “Really want to be secure” and “I want to be secure up to a hassle point” — I would never export the former, if I can avoid it. It’s the usual usability vs perfect security problem.OTOH remember that what goes into the TPM is really a *secret* key, a TOTP is a *shared* key. It is very likely that someone with access to the database of unseeded passwords would also get access to those same shared keys, if the service implemented it wrongly. And given how much of a mess there is in 2FA support nowadays, I’m sure someone implemented it wrongly ;)I mean, even Amazon does not re-key your TOTP key unless you switch to SMS and back to app…

  5. This was a long rambling post. Totally overreacting. Authy is probably the most popular and you downplay it as if its somehow insecure. No one is going to this kind of trouble to hack your account.

  6. Hi hi, i would like to propose an alternative solution to the existing security issues whilst still maintaining use of the last pass systems.

    Have a last pass account for all passwords. (mails, forums, etc)
    Have a last pass authenticator app for 2fa access to above account.
    Have a 2nd last pass account solely for 2fa backup.

    So essentially, if someone hacks the 2nd last pass account to gain access to the 2fa backup, they still have to hack the first original account holding all the passwords.

Leave a Reply to Bryan JacobsCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.