LWN: Comments on "Google Authenticator for multi-factor authentication"

I've put up some notes on using this on a java webapp

kokopelli — Fri, 23 Dec 2011 17:09:24 +0000

I've put up some notes on using this on a java webapp on my blog: http://invariantproperties.com/2011/12/23/using-google-authenticator-totp-on-your-site/

Google Authenticator for multi-factor authentication

mpr22 — Fri, 16 Dec 2011 16:54:33 +0000

Nuremberg process ruled out that enumeration of people is a non-expiring crime against humanity.

I'm having trouble parsing that, since the grammatical inconsistency is such as to make it impossible for me to tell what the intended meaning is. (And what does "enumeration of people" mean, beyond "assigning unique numbers to all members of a group of people"?)

Wikipedia is your friend... or foe

gvy — Thu, 15 Dec 2011 14:24:53 +0000

Victor, just for the neutrality (pun intended): the technical articles on wikipedia might be reasonable (but that's not a given), while e.g. historical or national ones tend to get ugly and distorted by a strangely constant factor. You might be interested in [[VP:ISK256]] (translit back to Cyrillic) on ru.wikipedia.org.

Google Authenticator for multi-factor authentication

gvy — Thu, 15 Dec 2011 14:18:23 +0000

Biometrics are also being pushed down the general public's throat already through chipification, while Nuremberg process ruled out that enumeration of people is a non-expiring crime against humanity.

Google Authenticator for multi-factor authentication

eli — Wed, 14 Dec 2011 20:55:28 +0000

Signature and CC # embossing are on the opposite side of the card.

Take out one of your credit cards. Look at the back of it. Notice that everything on the front of the card is embossed into the card, which changes the shape of the back of the card. If you get a good image of the back of that card, you can read the data embossed on the front.

Google Authenticator for multi-factor authentication

beast — Tue, 13 Dec 2011 17:07:24 +0000

I saw this demonstrated last week at the USENIX LISA conference - a two-factor authentication system that uses QR codes that you scan with your phone camera. There is even a PAM module to generate the QR codes when logging in with ssh.

https://tiqr.org/

Google Authenticator for multi-factor authentication

paulj — Tue, 13 Dec 2011 07:10:37 +0000

So, for the UK, the thing to do is to just ignore the VbV password crap. Hit the "Forgot password" link every time, enter the card data, enter some long, random data for the new password - then forget that.

I don't know if there's causation, but after a couple of times of doing this, I now no longer get prompted at all anymore for a VbV password. ;)

Google Authenticator for multi-factor authentication

ghane — Tue, 13 Dec 2011 03:09:14 +0000

<quote> I'd like to see someone replicate an eyeball, maliciously or otherwise. </quote>

Does it have to be a working eyeball?

:-)

--
Sanjeev

Google Authenticator for multi-factor authentication

BenHutchings — Mon, 12 Dec 2011 19:00:02 +0000

The implementation used in the UK (Visa calls this 'Verified by Visa'; I forget what Mastercard calls it) is even better: no dialog, but an IFRAME. Cardholders are expected to enter their 'secret' details into random shopping sites that embed a frame that probably comes from the payment network. This is literally indistinguishable from phishing, since most users cannot determine where the frame really comes from, and even if they can a framing site can generally snoop on all interaction with a frame.

expiration date in credit card authentication

giraffedata — Sat, 10 Dec 2011 18:02:54 +0000

It doesn't surprise me that for some charges the expiration date has to be right. There's a lot of diversity in this area.

But I know that traditionally, the expiration date wasn't part of authentication. When I did it, it was in 1999 using a traditional merchant credit card terminal.

Banking computing standards often take a decade to make even a trivial change because regulators are very careful. I'm pretty sure that this terminal wasn't even capable of transmitting the expiration date I typed to its partner.

This is strange...

corbet — Sat, 10 Dec 2011 15:16:23 +0000

Our experience as a credit card merchant suggests that banks differ widely in the practices they apply. For a lot of them, if you have a number, that's all they care about. We routinely get emails from people who realize they put in the wrong name or expiration date, but the charges go through just fine. Other banks insist on correct address information and will turn down charges because they don't like the position of the moon that night.

This is strange...

khim — Sat, 10 Dec 2011 06:51:13 +0000

I used to successfully submit charges all the time with made up expiration dates.

How can you do that? I've had card from a few banks, but they all reject transactions with incorrect expiration dates (at least electronic ones). This is PITA when card expires: if order is placed with old expiration date and is not shipped before it's annulled and new one is issued then you need to go to the web site and change the data. And not all sites provide nice interface to do that...

Google Authenticator for multi-factor authentication - credit cards

giraffedata — Fri, 09 Dec 2011 17:05:20 +0000

Expiration date is not normally an authenticating factor. I used to successfully submit charges all the time with made up expiration dates. The reason the rules require the merchant to provide that is to prevent the merchant from neglecting to check the expiration date.

The key value of the card verification code (the few digits printed somewhere on the card, aka CCV2 et al) is that it isn't recorded and transmitted all around, like the card account number obviously is. Anyone involved in accounting can see your card account number, but few people ever see your card verification code.

In the original design, secrecy of the card account number wasn't considered a security feature at all. It was public knowledge and security was provided by physical presence of the card and a signature alone. As telephone ordering became more important, banks started trying to keep the account numbers secret as a security measure, but that's obviously pretty weak. Likewise, even secrecy of checking account numbers is now considered a security measure.

Google Authenticator for multi-factor authentication

giraffedata — Fri, 09 Dec 2011 16:27:16 +0000

I find it impossible to regard a signature as being in any useful sense "something you are". The useful property of "something you are" credentials is that a fraudster can't learn to have them, and a fraudster can certainly learn to have your signature.

And yet the main reason signatures exist is that many people do regard them as something you are, being difficult for a fraudster to learn.

I, for example, could almost certainly not reproduce your signature, no matter how much I practiced. So there's one fewer fraudster to worry about.

None of the security mechanisms we're talking about are perfect, so it's all about reducing, not eliminating, the chance of fraud.

In any case, it's not "something you know" -- if it were, then you could instantly disclose to someone how to write your signature.

(Incidentally, the other major purpose of a signature that people often overlook is not as security, but as a statement. The fact that someone wrote his name (or even an X) on a piece of paper makes it impossible for him to argue he didn't mean to commit himself. As most people are honest, whether he signed or not is often not disputed).

Google Authenticator for multi-factor authentication

dlang — Fri, 09 Dec 2011 16:26:47 +0000

the determining factor is if the website has opted to implement such a feature.

Wikipedia is your friend...

khim — Fri, 09 Dec 2011 16:04:11 +0000

It all explained in much details where usually such things are explained.

Google Authenticator for multi-factor authentication

skitt — Fri, 09 Dec 2011 15:53:30 +0000

Some websites I place orders on now support an extra step, where my bank sends a one-time code to my mobile phone which I then enter to confirm the transaction. I don't know how widespread this is or what the determining factors are; I've seen it used with cards issued by various banks and via both Visa and MasterCard.

Google Authenticator for multi-factor authentication

sdalley — Fri, 09 Dec 2011 11:08:38 +0000

Laughed out loud!

Google Authenticator for multi-factor authentication

mpr22 — Fri, 09 Dec 2011 10:20:01 +0000

I find it impossible to regard a signature as being in any useful sense "something you are". The useful property of "something you are" credentials is that a fraudster can't learn to have them, and a fraudster can certainly learn to have your signature.

Google Authenticator for multi-factor authentication

giraffedata — Fri, 09 Dec 2011 01:23:57 +0000

The signature is something you are, not something you know. It comes from too low a part of the brain to be in the same category as a password.

The system really doesn't rely on a semi-trusted point-of-sale agent; the retailer is about as untrusted as anyone by VISA, which is why he used to have to get an imprint of the card, and now has to swipe it through a reader. To prove to a large extent that the card was actually present. In addition, the retailer has to produce a signature that reasonably matches the one on the card, proving to some extent that the owner of the card was there too.

The only thing I've seen change since the early days is that for small transactions, someone - I don't know if it's Visa or the retailer - is now willing to take the risk of fraud in exchange for speed and convenience.

Yubikey

wahern — Fri, 09 Dec 2011 01:01:53 +0000

Has anybody purchased tokens from http://www.gooze.eu/? They're the only seller of single-unit TOTP tokens I have found so far, and other than Goldkey of public-key crypto tokens as well.

Yubikey

wahern — Fri, 09 Dec 2011 00:49:05 +0000

Regarding the central authority, it's no different than any other method--the server needs access to the secret (or public key) in order to authenticate. Just put the secret on all the servers.

It doesn't matter if the HOTP counters on the servers become out of sync with each other as long as the counter on the key is monotonically increasing. The servers will fast forward until they find a match (within a configurable limit).

Admittedly you open yourself up to replay attacks. But you're hardly in a worse position than with regular passwords. TOTP is better in this regard, but what matters is how much better HOTP is compared to the baseline.

I pine for the day when my Goldkey USB crypto token works out-of-the-box (or my 10 year old Schlumberger crypto card, for that matter), but that day isn't here yet.

Google Authenticator for multi-factor authentication

iabervon — Thu, 08 Dec 2011 17:17:47 +0000

It was originally something you had (the card), and something you knew (how to get a pen to produce your signature). But neither of these works without a semi-trusted point-of-sale agent who watches you sign and sees that you actually have the card. Providing effective authentication for credit cards now (considering both how they're used and the state of forging technology) would cost more than fraud costs, so they haven't bothered. To the extent that they've done anything, it's just an attempt to make their accounts a bit harder to abuse than other cards. (Asking for an extra password to use a card would probably cut way down on fraud at the moment even if you don't compare the password to anything, because attackers will tend to think, "this one's weird" and go on to the next number in their list, which will work fine without anything special.)

Google Authenticator for multi-factor authentication

jwarnica — Thu, 08 Dec 2011 16:21:43 +0000

The distinction of those methods (and also, signature, track 2) are ways that the CC companies can use as proof (well, evidence) that you actually have the card when doing that transaction.

Back in the physical swipe days, the embossing of the card and carbon paper made an imprint. The imprint was not just the card number, but demonstration that the card was actually there when the imprint happened.

"Track 2" data is similar; I dunno what it contains, but provides similar evidence that the actual card was actually used.

Expiry date help for phone or internet transactions, as does the CCV2 codes; just more evidence that someone has the card in hand.

Generally, the theory was that it is hard/impossible to copy two of these at the same time. Signature and CC # embossing are on the opposite side of the card. CCV2 # and CC#, opposite sides (for most cards), etc.

Obviously, as time has moved on, the effort/gain ratio of each of these has been overcome, and thus the introduction of more things.

Google Authenticator for multi-factor authentication

bdauvergne — Thu, 08 Dec 2011 14:21:14 +0000

Some self-promotion....

Here is a Python library implementing all of the OATH OTP-linked standards (HOTP, TOTP and the more obscure OCRA):

https://github.com/bdauvergne/python-oath

Then a little python-snippet to generate a TOTP generator (TOTP client) as a javascript bookmarklet:

https://github.com/bdauvergne/totp-js

If works as google-authenticator but in the browser. You can put the bookmarklet near the QRCode as simple <a/> link, and people can bookmark it. Just click on the bookmark and a message box open with your password. I think it only works with decent browsers (chrome&mozilla).

Google Authenticator for multi-factor authentication

nix — Thu, 08 Dec 2011 13:53:10 +0000

A pedant walks into a bar. Ouch.

access to the shared secret

PlaguedByPenguins — Thu, 08 Dec 2011 13:50:49 +0000

how about using google authenticator (or yubikeys etc.) via radius - then you can put all the plaintext secrets on a "secure" radius machine that's heavily defended. no more secrets on clients.

Google Authenticator for multi-factor authentication

epa — Thu, 08 Dec 2011 13:41:53 +0000

You're forgetting 'enhanced security' in some countries where a crappy dialogue box asks for your password. If you don't know the password, don't worry, you can reset it by providing your bank account number (embossed on card) and your date of birth (*not* on the card, but hardly a secret either).

Google Authenticator for multi-factor authentication

dwmw2 — Thu, 08 Dec 2011 13:12:51 +0000

Google Authenticator doesn't use public/private keys. It has a single symmetric key. Essentially there is no public key; only a private key.

So no, the problematic part is not that it's like the SSH public key. The problematic part is that it's like keeping your SSH private key lying around on the file system without a passphrase.

And yes, the patch I mention above will allow you to keep the files in a root-owned and root-only-readable location.

Yubikey

Cato — Thu, 08 Dec 2011 12:30:08 +0000

For the server case, you would need to have a non-Yubikey login method not using two factor, and this applies to almost any two factor system I would think. Since this 'recovery login' would only be used in the 'something very broken' case, it's not too vulnerable to keyloggers on the client. Google Authenticator has a recovery process with pre-printed emergency token codes, which may be better.

For multiseat, a USB-based login method may not be very suitable as it requires the login process to know more about Yubikey - perhaps a smartphone or traditional token would work better.

Google Authenticator for multi-factor authentication

ekj — Thu, 08 Dec 2011 11:52:25 +0000

That explains why VISA authenthicates transactions by asking you for several items of the same type.

Card-number (embossed on card) expiry-date (embossed on card) CVC (printed on card) owner name (printed on card).

[/cheapshot]

Google Authenticator for multi-factor authentication

drag — Thu, 08 Dec 2011 11:43:26 +0000

ok. I think I understand now. The ~/.google-authenticator is on the server-side and is what pam uses to authenticate your user.

I thought it was part of what you needed on the client side. My mistake.

In this case it's not like kerberos tickets or private ssh key at all. It's more like the public key for SSH RSA/DSA authentication.

Even then it's not horrible or stupid, I think. It seems obvious that ~/.google-authenticator file is intended for the user to setup for themselves without administrative help in addition to passwords. So in that case it makes sense that it's in the home directory.

Is there a mode for the administrator to setup the secrets without user intervention; without the ~/.google-authenticator file?

Google Authenticator for multi-factor authentication

drag — Thu, 08 Dec 2011 10:57:05 +0000

Call me stupid, but I don't really understand what is so horrible about ~/.google_authenticator. I really want to understand exactly why this is bad.

When I am using Kerberos, for example, the ticket cache is stored in something like /tmp/krb5cc_1000. Anybody who has access to my account can read and use those tickets to get access to any service I have access to. These are stored under 700 and are rw by my users. Kerberos can be two-factor if I a service asks for a password in addition to the ticket from the ticket granting service. The 8 hour expiring of the ticket provides plenty of opportunity for mischief.

When I am using OpenSSH, again my keys are stored in ~/.ssh/ and is read/writable by my user. Openssh keys are legit and commonly used two-factor authentication since I need both the keys and the password to decrypt them.

How is ~/.google_autheniticator worse?

Even if I have a hardware dongle or a physical RSAkey-style OTP password then if somebody has access to my account they have access to the hardware key or any OTP key I type into the system just as much as I do. If somebody has access to your account on your PC that your using then it doesn't matter what sort of authentication system your using, your screwed anyways.

Is there something I am missing here?

Yubikey

Yenya — Thu, 08 Dec 2011 09:49:09 +0000

I have tested yubikey briefly, and altough it is an interesting technology, I found it unusable for my needs, because of two problems:

- central authority: I maintain several servers, and I want to be able to log in even in case the server is half-broken (i.e. DNS or network only partly functional). For an ordinary user, Yubikey is a great technology. For a server admin, not so much.

- multiseat: at home, I have a multiseat workstation, and I have so far not found an easy way how to configure to which head the hot-plugged keyboard (the yubikey module) should be mapped. I have primary keyboards for both seats configured statically in their respective ServerLayout sections in xorg.conf.

Google Authenticator for multi-factor authentication

pilif — Thu, 08 Dec 2011 09:42:37 +0000

compared to the commercial solutions, you can run this yourself, you don't have to pay per authentication and no third party is involved at all for the authentication.

Google Authenticator for multi-factor authentication

dwmw2 — Thu, 08 Dec 2011 09:13:54 +0000

"Thanks for flagging this, that's truly a terrible design decision and makes me wonder about the rest of Google Authenticator."

I'd fairly much reached that state as soon as I realised it was kept in Mercurial. The ~/.google_authenticator braindamage just served to confirm my prejudice ☺

Google Authenticator for multi-factor authentication

ssmith32 — Thu, 08 Dec 2011 07:44:12 +0000

Admittedly I'm a little tired & my eyes glazed over the details.. but, as far as functionality, how is this different than a RSA soft token or a VIP soft token (Versign/Symantec equivalent of RSA's soft token)?

Other than seeming way way way more complicated..

And, I guess, it didn't get hacked when RSA did :D

For those who don't like phones

Cato — Thu, 08 Dec 2011 07:02:59 +0000

I use Yubikey as well - currently with LastPass, a password manager that works on Linux, Mac, Windows, iPhone, Android, etc. More applications (web and other) need to support two-factor - currently Fastmail is an email service that supports Yubikey.

The only issue with Yubikey is that it requires a USB port so there's no way to use it on most smartphones, many of which don't even have a USB port. Same goes for some Internet cafes that don't allow USB devices to be plugged in, and some corporates perhaps. The great thing is that it does work without drivers for any computer that has a USB keyboard interface.

Duo Security might be a better option for desktop and phone use. It is more or less a superset of Google Authenticator, with phone/text callback as well as smartphone apps, but also has the option of a hardware token with display for the random passcode.

Links:
- http://yubikey.com/
- http://duosecurity.com/

Google Authenticator for multi-factor authentication

Cato — Thu, 08 Dec 2011 06:55:00 +0000

Thanks for flagging this, that's truly a terrible design decision and makes me wonder about the rest of Google Authenticator.

For those who don't like phones

wahern — Thu, 08 Dec 2011 06:24:33 +0000

I'll vouch for the Yubikey HOTP system: www.yubico.com. Yubikeys are quite slick. They're much faster than even typing in a short TOTP string, yet still don't require any client software. They pose as a USB keyboard. When you press the button the next OTP is printed along with a line feed. Works for SSH, HTML web forms, etc.

When I create a new shell account on my server I hand one of these out.

I just bought 10 for $99 (holiday special). I think if these were in the $3-$5 range they'd sell much better, but what do I know.

Yubico also sells a tiny USB hardware security module to securely (i.e. irretrievably) store the OTP secrets for authentication. It's pricey but still the cheapest HSM solution by far that I'm aware of. The HSM isn't necessary, of course, but it's an extremely nice option.