TOTP

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.

2017-06-24 by English Technical 6

Let’s have a talk about TOTP

You probably noticed that I’m a firm believer in 2FA, and in particular on the usefulness of U2F against phishing. Unfortunately not all the services out there have upgraded to U2F to protect their users, though at least some of them managed to bring a modicum of extra safety against other threats by implementing TOTP 2FA/2SV (2-steps verification). Which is good, at least.

Unfortunately this can become a pain. In a previous post I have complained about the problems of SMS-based 2FA/2SV. In this post I’m complaining about the other kind: TOTP. Unlike the SMS, I find this is an implementation issue rather than a systemic one, but let’s see what’s going on.

I have changed my mobile phone this week, as I upgrade my work phone to one whose battery lasts more than half a day, which is important since my job requires me to be oncall and available during shifts. And as usual when this happens, I need to transfer my authenticator apps to the new phone.

Some of the apps are actually very friendly to this: Facebook and Twitter use a shared secret that, once login is confirmed, is passed onto their main app, which means you just need any logged in app to log in again and get a new copy. Neat.

Blizzard was even better. I have effectively copied my whole device config and data across with the Android transfer tool. The Battle.net authenticator copied over the shared key and didn’t require me to do anything at all to keep working. I like things that are magic!

The rest of the apps was not as nice though.

Amazon and Online.net allow you to add at any time a new app using the same shared key. The latter has an explicit option to re-key the 2FA to disable all older apps. Amazon does not tell you anything about it, and does not let you re-key explicitly — my guess is that it re-keys if you disable authentication apps altogether and re-enable it.

WordPress, EA/Origin, Patreon and TunnelBroker don’t allow you to change the app, or get the previously shared key. Instead you have to disable 2FA, then re-enable it. Leaving you “vulnerable” for a (hopefully) limited time. Of these, EA allows you to receive the 2SV code by email, so I decided I’ll take that over having to remember to port this authenticator over every time.

If you remember in the previous post I complained about the separate Authenticator apps that kept piling up for me. I realized that I don’t need as many: the login approval feature, which effectively Microsoft and LastPass provide, is neat and handy, but it’s not worth having two more separate apps for it, so I downgraded them to just use normal TOTP on the Google Authenticator app, which gets me the Android Wear support to see the code straight on my watch. I have particularly failed to remember when I last logged into a Microsoft product except for setting up the security parameters.

Steam on the other hand, was probably the most complete disaster of trying to migrate. Their app, similarly to the Battle.net one, is just a specially formatted TOTP with a shared key you’re not meant to see. Unfortunately to be able to move the Authenticator to a new phone, you need to disable it first — and you disable it from the logged-in app that has it enabled. Then you can re-enable it on a new phone. I assume there is some specific way to get recovery if that does not work, too. But I don’t count on it.

What does this all mean? TOTP is difficult, it’s hard for users, and it’s risky. Not having an obvious way to de-authenticate the app is bad. If you were at ENIGMA, you could have listened to a talk that was not recorded, on ground of the risky situations there described. The talk title was «Privacy and Security Practices of Individuals Coping with Intimate Partner Abuse». Among various topic that the talk touched upon, there was an important note on the power of 2FA/2SV for people being spied upon to gain certainty that somebody else is not logging in on their account. Not being able to de-authenticate TOTP apps goes against this certainty. Having to disable your 2FA to be able to change it to a new device makes it risky.

Then there are the features that become a compromise between usability and paranoia. As I said I love the Android Wear integration for the Authenticator app. But since the watch is not lockable, it means that anybody who could have access to my watch while I’m not attentive could have access to my TOTP. It’s okay for my use case, but it may not be for all. The Google Authenticator app also does not allow you to set a passcode and encrypt the shared keys, which means if you have enabled developer mode, run your phone unencrypted, or have a phone that is known vulnerable, your TOTP shared keys can be exposed.

What does this all mean? That there is no such thing as the perfect 100% solution that covers you against all possible threat models out there, but some solutions are better than others (U2F) and then compromises depend on what you’re defending against: a relative, or nation-states? If you remember I already went over this four years ago, and again the following year, and the one after talking about threat models. It’s a topic that I’m interested in, if it was not clear.

And a very similar concept was expressed by Zeynep Tufekci when talking about “low-profile activists”, wanting to protect their personal life, rather than the activism. This talk was recorded and is worth watching.

2017-03-11 by English Technical 1

Logging in offline

Over two years ago, I described some of the advantages of U2F over OTP when FIDO keys were extremely new and not common at all. I have since moved most of my login access that support it to U2F, but the amount of services support it is still measly, which is sad. On the other hand, just a couple of days ago Facebook added support for it which is definitely good news for adoption.

But there is one more problem with the 2-factor authentication or, as some services now more correctly call it, 2-step verification: the current trend of service-specific authentication apps, not following any standard.

Right now my phone has a number of separate apps that are either dedicated as authentication app, or has authentication features built into a bigger app. There are pros and cons with this approach of course, but at this point I have at least four dedicated authorization apps (Google Authenticator, LastPass Authenticator, Battle.net Authenticator and Microsoft’s) plus a few other apps that simply include authentication features in the same service client application.

Speaking of Microsoft’s authenticator app, which I didn’t like above. As of today what I had installed, and configured, was an app called “Microsoft Account” – when I went to look for a link I found out that it’s just not there anymore. It looks like Microsoft simply de-listed the application from the app store. Instead a new Microsoft Authenticator is now available, taking over the same functionality. It appears this app comes from their Azure development team, from the Play Store ID, but more important it is the fourth app that appears just as Authenticator on my phone.

Spreading the second factor authentication across different applications kind of make sense: since the TOTP/HOTP (from now I will only call them TOTP, I mean both) system relies on a shared key generated when you enroll the app, concentrating all the keys into a single application is clearly a bit of a risk – if you could easily access the data of a single authentication app and fetch all of its keys, you don’t want it to bring you access to all the services.

On the other hand, having to install one app for the service and one for the authentication is … cumbersome. Even more so when said authentication app is not using a standard procedure, case in point being the Twitter OTP implementation.

I’m on a plane, I have a “new” laptop (one I have not logged on Twitter with). I try to login, and Twitter nicely asks me for the SMS they sent to my Irish phone number. Ooops, I can’t connect phone service from high up in the air! But fear not it tells me that I can give them a code from the backups (on a different laptop, encoded with a GPG key I have with me but not at hand in the air) or a code from the Twitter app, even if I’m offline.

Except, you need first to have it set up. And that you can’t do offline. But turns out if you just visit the same page while online it does initialize and then work offline from them on. Guess when you may want to look for the offline code generator for the first time? Compare with the Facebook app, that also includes a code generator: once you enable the 2-step verification for Facebook, each time you log in to the app, a copy of the shared key is provided to the app, so every app will generate the same code. And you don’t need to request the code manually on the apps. The first time you need to login, with the phone offline, you’ll just have to follow the new flow.

Of course, both Facebook and Twitter allows you to add the code generator to any authenticator TOTP app. But Facebook effectively set that up for you transparently, on as many devices as you want, without needing a dedicated authentication app, just have any logged in Facebook app generate the code for you.

LastPass and Microsoft authenticator apps are dedicated, but both of them also work as a generic OTP app. Except they have a more user-friendly push-approval notification for their own account. This is a feature I really liked in Duo, and one that, with Microsoft in particular, makes it actually possible to log in even where otherwise the app would fail to log you in (like the Skype app for Android that kept crashing on me when I tried to put in a code). But the lack of standardization (at least as far as I could find) requires you have separate app for each of these.

Two of the remaining apps I have installed (almost) only for authentication are the Battle.net and Steam apps. It’s funny how the gaming communities and companies appears to have been those pushing the hardest at first, but I guess that’s not too difficult to imagine when you realize how much disposable money gamers tend to have, and how loud they can be when something’s not to their liking.

At least the Steam app tries to be something else beside an authenticator, although honestly I think it falls short: finding people with it is hard, and except for the chat (that I honestly very rarely use on desktop either) the remaining functions are so clunky that I only open the app to authenticate requests from the desktop.

Speaking of gaming community and authentication apps, Humble Bundle has added 2FA support some years ago. Unfortunately instead of implementing a standard TOTP they decided to use an alternative approach. You can choose between SMS and a service called Authy. The main difference between the Authy service and a TOTP app is that the service appears to keep a copy of your shared key. They also allow you to add other TOTP keys, and because of that I’m very unhappy with the idea of relying such a service: now all your key are not only concentrated on an app on your phone, but also on a remote server. And the whole point of using 2FA, for me, is that my passwords are stored in LastPass 1Password.

There is one more app in the list of mostly-authenticator apps: my Italian bank’s. I still have not written my follow up but let’s just say that my Italian bank used TOTP-token authentication before, and have since moved to an hybrid approach, one such authentication system is their mobile app, which I can use to authenticate my bank operations (as the TOTP-token expired over a year ago and have not replaced yet). It’s kind of okay, except I really find that bank app too bothersome to use and never bother using it right now.

The remaining authentication systems either send me SMS or are configured on Google Authenticator. In particular, for SMS, the most important services are configured to send me SMS to my real Irish phone number. The least important ones, such as Humble Bundle itself, and Kickstarter, which also insist on not even letting me read a single page without first logging in, send their authentication code to my Google Voice phone number, so they require an Internet connection, but that also means I can use them while on a flight.

Oh yes, and of course there are a couple of services for which the second factor can be an email address, in addition, or in place, of a mobile phone. This is actually handy for the same reason why I send them to Google Voice: the code is sent over the Internet, which means it can reach me when I’m out of mobile connectivity, but still online.

As for the OTP app, I’m still vastly using the Google Authenticator app, even though FreeOTP is available: the main reason is that the past couple of years finally made the app usable (no more blind key-overwrites when the username is the only information provided by the service, and the ability to change the sorting of the authenticator entries). But the killer feature in the app for me is the integration with Android Wear. Not having to figure out where I last used the phone to log in on Amazon, and just opening the app on the watch makes it much more user friendly – though it could be friendlier if Amazon supported U2F at this point.

I honestly wonder if a multiple-weeks battery device, whose only service would be to keep TOTP running, would be possible. I could theoretically use my old iPod Touch to just keep an Authenticator app on, but that’d be bothersome (lack of Android Wear) and probably just as unreliable (very shoddy battery). But a device that is usually disconnected from the network, only dedicated to keep TOTP running would definitely be an interesting security level.

What I can definitely suggest is making sure you get yourself a FIDO U2F device, whether it is the Yubico, the cheapest, or the latest BLE-enabled release. The user friendliness over using SMS or app codes makes up for the small price to pay, and the added security is clearly worth it.

2017-01-28 by English Technical 5

Why is U2F better than OTP?

It is not really obvious to many people how U2F is better than OTP for two-factor authentication; in particular I’ve seen it compared with full-blown smartcard-based authentication, and I think that’s a bad comparison to do.

Indeed, since the Security Key is not protected by a PIN, and the NEO-n is designed to be semi-permanently attached to a laptop or desktop. At first this seems pretty insecure, as secure as storing the authorization straight into the computer, but it’s not the case.

But let’s start from the target users: the Security Key is not designed to replace the pure-paranoia security devices such as 16Kibit-per-key smartcards, but rather the on-phone or by-sms OTPs two-factor authenticators, those that use the Google Authenticator or other opensource implementations or that are configured to receive SMS.

Why replacing those? At first sight they all sound like perfectly good idea, what’s to be gained to replace them? Well, there are plenty of things, the first of being the user friendliness of this concept. I know it’s an overuse metaphor, but I do actually consider features on whether my mother would be able to use them or not — she’s not a stupid person and can use a computer mostly just fine, but adding any on more procedures is something that would frustrate her quite a bit.

So either having to open an application and figure out which of many codes to use at one time, or having to receive an SMS and then re-type the code would be not something she’d be happy with. Even more so because she does not have a smartphone, and she does not keep her phone on all the time, as she does not want to be bothered by people. Which makes both the Authenticator and SMS ways not a good choice — and let’s not try to suggests that there are way to not be available on the phone without turning it off, it would be more to learn that she does not care about.

Similar to the “phone-is-not-connected” problem, but for me rather than my mother, is the “wrong-country-for-the-phone” problem: I travel a lot, this year aiming for over a hundred days on the road, and there are very few countries in which I keep my Irish phone number available – namely Italy and the UK, where Three is available and I don’t pay roaming, when the roaming system works… last time I’ve been to London the roaming system was not working – in the others, including the US which is obviously my main destination, I have a local SIM card so I can use data and calls. This means that if my 2FA setup sends an SMS on the Irish number, I won’t receive it easily.

Admittedly, an alternative way to do this would be for me to buy a cheap featurephone, so that instead of losing access to that SIM, I can at least receive calls/SMS.

This is not only a theoretical. I have been at two conferences already (USENIX LISA 13, and Percona MySQL Conference 2014) and realized I cut myself out of my LinkedIn account: the connection comes from a completely different country than usual (US rather than Ireland) and it requires reauthentication… but it was configured to send the SMS to my Irish phone, which I had no access to. Given that at conferences is when you meet people you may want to look up on LinkedIn, it’s quite inconvenient — luckily the authentication on the phone persists.

The authenticator apps are definitely more reliable than that when you travel, but they also come with their set of problems. Beside the not complete coverage of services (LinkedIn noted above for instance does not support authenticator apps), which is going to be a problem for U2F as well, at least at the beginning, neither Google’s or Fedora’s authenticator app allow you to take a backup of the private keys used for OTP authentication, which means that when you change your phone you’ll have to replace, one by one, the OTP generation parameters. For some services such as Gandi, there is also no way to have a backup code, so if you happen to lose, break, or reset your phone without disabling the second factor auth, you’re now in trouble.

Then there are a few more technical problems; HOTP, similarly to other OTP implementations, relies on shared state between the generator and the validator: a counter of how many times the code was generated. The client will increase it with every generation, the server should only increase it after a successful authentication. Even discounting bugs on the server side, a malicious actor whose intent is to lock you out can just make sure to generate enough codes on your device that the server will not look ahead enough to find the valid code.

TOTP instead relies on synchronization of time between server and generator which is a much safer assumption. Unfortunately, this also means you have a limited amount of time to type your code, which is tricky for many people who’re not used to type quickly — Luca, for instance.

There is one more problem with both implementations: they rely on the user to choose the right entry and in the list and copy the right OTP value. This means you can still phish an user to type in an OTP and use it to authenticate against the service: 2FA is a protection against third parties gaining access to your account by having your password posted online rather than a protection against phishing.

U2F helps for this, as it lets the browser to handshake with the service before providing the current token to authenticate the access. Sure there might still be gaps on is implementation and since I have not studied it in depth I’m not going to vouch for it to be untouchable, but I trust the people who worked on it and I feel safer with it than I would be with a simple OTP.

2014-10-27 by English Technical 9

How not to sell me something — Why I won’t be maintaining Yubikey software directly in Gentoo

You probably remember my previous notes about WordPress, FTP and the problem with security. At the end after a (boring) set up session I was able to get vsftpd provide FTPS service, which should be usable both by WordPress and by Dreamweaver, so that my friend the webmaster can upload through it directly.

This is important because as it happens I have another prospective customer who’s going to run WordPress, and FTPS now start to look more interesting than SSH, as it doesn’t require me to give shell access to the server either.

Unfortunately I’m a bit worried (maybe more than I should be) for the use of standard passwords rather than certificates or keypairs for authentication. Which meant I went tried to think of other alternatives.. of which there are mostly two: Google Authenticator and YubiKey .

The latter I knew by name already because I proxy-maintain the required software for Brant, and I know it’s outdated already and would require a new maintainer who can deal with those packages – I already posted about hardware-related maintenance for what it’s worth – so it was my first choice: while it meant I had to spend some money, it would have solved my problem and improved Gentoo, even if just for a tiny bit. The price for YubiKey devices is also low enough that, if I felt like providing more FTPS access to customers, I could simply bill it to them without many complaints.

So I went on the manufacturer’s (Yubico’s) website and tried to buy two of them (one for me to test and set up, and one to give my friend to access the server); despite publishing the prices in dollars, they sell through Sweden and UK, which means they are part of EU’s VAT area, and me being a registered business within EU, I should receive a reverse-charge invoice by stating my own VAT ID… never had much of a problem with it, as many of my suppliers are sparse through Europe, I registered for the “foreign-enabled” registry right when I opened business — don’t ask me why Italian (and Spanish as far as I can tell) business owners are not enabled by default to have intra-union suppliers.

Now trouble starts: since, as I just noted, not all VAT IDs are valid to use for intra-union trade, there has to be a way to ensure you’re dealing with an acceptable party. This is implemented through VIES the VAT Information Exchange System which, for what concerns Italian businesses, only tells you a boolean result of valid/invalid (and not the full registration data that most other states seem to provide). I knew VIES from a previous business agreement, but I never cared much. Turns out though that most e-Shops I encountered validate the VAT ID after order completed — or in the case of Amazon it seems like they check their internal database as well as VIES.

Yubico instead validates the request through VIES at the time of registration:

VAT Number could not be validated with VIES at this time. This typically happens when the service is under maintenance. Please retry after some time. For urgent orders, please contact order@yubico.com

Considering that the VIES website has a long disclaimer (which I can’t quote here for reasons that will be clear in a moment) stating that they do not guarantee the availability of the service at any time, and only seem to guarantee the validity of the data to the extent that the law ask them to (which probably means “as long as the states’ own databases are correct”), relying on such a service for registration is .. bad.

The VIES website is indeed down since at least 11am today (over four hours ago as I write this); for a moment they also gave me an interesting page (which I forgot to save), telling me that there were too many requests’ failures from “my IP address” … listing an IP address in the 212⁄8 range — my actual IP address is in the 94⁄8 range.

What’s the end result here? I’ll probably waste some more time trying to get Google Authenticator; Yubico basically lost a customer and a (possible) contributor by trying and failing to be smarter and won’t have a dedicated maintainer in Gentoo in the near future. It’s sad, because it seems to be easily the most cost- and time-effective solution out there (Google Authenticator is free, but it requires a greater investment of time, and time is money as we all should know).

2012-01-27 by English Technical 5