Google Authenticator API - like dragons, for cans
-
@dkf said in Google Docs API - like crabs, for programmers:
@Steve_The_Cynic So… Google's APIs are a can of … dragons?
TLDR: Google produces another API where half the parameters are either redundant copies of other parameters, or are ignored completely in favour of the defaults
I've had reason to look into implementing OTP for a personal project which will probably end up being used at work.
So I go reading relevant docs and RFCs*, got them understood, then go find out what Google Authenticator requires. Most of you are probably aware you can just get GA's barcode reader to read a QR code off the screen and magic happens.
What it's doing is reading a QR encoded URI of the form:
otpauth://TYPE/LABEL?PARAMETERS
Where
TYPE-hotportotp- (whether it's a counter- or time-based OTP)LABEL- this is where it starts gets messy. This is eitheruser_id(username/email address/unique identifier for your site)issuer:user_id(prefix of name or other identifier of your site)- Note, that because of that
:separator,:cannot appear in eitheruser_idorissuer. Got a colon in your company name? Tough.
PARAMETERS:secret- shared secretissuer- same thing, if present, that's inLABEL(Legacy
- the LABELversion is for older and deprecated. Both should be specified. And be the same)algorithm. Underlying hash function used for generation. Can be one ofsha1|sha256|sha256, default ofsha1. Ignoreddigits. How many digits to show/user needs to enter.- RFC allows 6,7,8,9.
- 10 doesn't make sense (maximum range you can get is
0-0x7ffff ffffrestricting the 1st digit to 0, 1 or 2) - 11 is impossible (for the above reason)
- Allowed here? Only 6 (default) or 8 .
- Doesn't matter anyway - it's ignored
counter- where to start the sequence withHOTPperiod- time-slice duration forTOTP(shows up as how frequently the number changes.) Can be anything from 1s (unusable) to .. well. Any other unusable number, but 15s might be useful. As could 60s. Defaults to 30s. Doesn't matter anyway - it's ignored
So, in the following (your GA will accept this)..
- One of these bits are redundant:
otpauth://totp/example%20co:pjh?secret=NB2W45DFOIQDGMRA&issuer=example%20co&algorithm=sha256&digits=7&period=60
- This next is allowed by RFC, but not API, but never mind, it's ignored even if it was a value allowed by API
otpauth://totp/example%20co:pjh?secret=NB2W45DFOIQDGMRA&issuer=example%20co&algorithm=sha256&digits=7&period=60
- In fact all of these bits are ignored (the first bit ignored only in newer GA implementations)
otpauth://totp/example%20co:pjh?secret=NB2W45DFOIQDGMRA<&issuer=example%20co&algorithm=sha256&digits=7&period=60
- Reducing what's actually useful to
otpauth://totp/pjh?secret=NB2W45DFOIQDGMRA&issuer=example%20co
Or
* Boring RFC details
Algorithmically, from the bottom up, if anyone's interested:
-
@PJH said in Google Authenticator API - like dragons, for cans:
secret- shared secretWhy is a shared secret being shown in the plain in a QR code? Are these expected to be served over an encrypted connection only?
-
@PleegWat said in Google Authenticator API - like dragons, for cans:
Why is a shared secret being shown in the plain in a QR code? Are these expected to be served over an encrypted connection only?
Absolutely that’s the expectation.
-
@PleegWat The expectation is that you only show it to the trusted user, who then points their phone at it to register with the local Google Authenticator app on their phone, and then the QRcode is never seen again.
-
@PleegWat said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
secret- shared secretWhy is a shared secret being shown in the plain in a QR code? Are these expected to be served over an encrypted connection only?
Yes. Usually via HTTPS:
- Create account
- Verify account
- Log into account
- User -> Profile
- Enable 2FA
- QR displayed on screen
- Open Google Authenticator and show it the QR code
- Move away from that screen and pretend that no-one else was shoulder surfing you.
-
@PJH said in Google Authenticator API - like dragons, for cans:
Move away from that screen and pretend that no-one else was shoulder surfing you.
Often not that difficult to achieve in practice. Sure, not great if you're somewhere public, but that's only some places. Compromises, compromises…
And less error-prone than typing a long random UUID by hand. On a godawful phone keyboard…
-
@hungrier said in Google Authenticator API - like dragons, for cans:
@PleegWat The expectation is that you only show it to the trusted user, who then points their phone at it to register with the local Google Authenticator app on their phone, and then the QRcode is never seen again.
Ah, enrollment. That makes sense.
-
@dkf said in Google Authenticator API - like dragons, for cans:
And less error-prone than typing a long random UUID by hand. On a godawful phone keyboard…
Well the only thing that would have to be typed (and is the other method in GA if you can't read a bar-code) is manually type the
secretparameter.Which is a
Base32encoding of whatever the raw secret is.RFC3548(the quoted reference) describes
Base32asdesigned to represent arbitrary sequences of octets in a form that needs to be case insensitive but need not be humanly readable.
|raw secret|should be at least 128 bits, with 160 bits recommended.So that's at least 26 characters, with 32 normally as represented in the way Google wants it.
-
Slight tangent...
@PJH said in Google Authenticator API - like dragons, for cans:
TYPE - hotp or totp - (whether it's a counter- or time-based OTP)
[...]
counter - where to start the sequence with HOTP
Google's Authenticator, while allowing you to manually enter keys, doesn't actually allow you to enter the starting counter number for a HTOP, so you have to start from
counter=0While the server you're trying to authenticate against is probably on a vastly different value...
-
@PJH Should I start screenshotting these codes to get data for haxoring peoples.
-
@PJH said in Google Authenticator API - like dragons, for cans:
Note, that because of that : separator, : cannot appear in either user_id or issuer. Got a colon in your company name? Tough.
I long for the day when we learn to do serialization of basic data types right.
Currently, the digits parameter is ignored by the Google Authenticator implementations.
Currently, the period parameter is ignored by the Google Authenticator implementations.
Currently, the algorithm parameter is ignored by the Google Authenticator implementations.So basically Google openly ignores 2/3rds of the standard and just implements what it needs.
And they sell it as a "standard and open protocol". God this pisses me off. These kind of things can seriously create decades of pain and confusion for users and developers alike.
This is why you trademark your standards! So you can sue anyone who claims to implement it but doesn't.
-
@anonymous234 said in Google Authenticator API - like dragons, for cans:
So basically Google openly ignores 2/3rds of the standard that they mention and just implements what it needs.
There are other (less used, but nevertheless mentioned) bits in the RFC's.
Like for TOTP, when do you start counting the time-slices from? Defaults to midnight Jan 1st 1970, but it's entirely cromulent to start from another point, and they haven't even accounted for that in their
parameterslist.
-
I don't really see this as a huge WTF. Google Authenticator doesn't fully implement the RFC. It just implements the most commonly-used parts of it, and that's good enough for the vast majority of users.
Also, AFAIK Google Authenticator doesn't ignore the issuer (example.co in your example). Are you saying the latest version ignores it?
But anyway, now I have a good excuse to show off my thingy:
-
@PJH said in Google Authenticator API - like dragons, for cans:
@PleegWat said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
secret- shared secretWhy is a shared secret being shown in the plain in a QR code? Are these expected to be served over an encrypted connection only?
Yes. Usually via HTTPS:
- Create account
- Verify account
- Log into account
- User -> Profile
- Enable 2FA
- QR displayed on screen
- Open Google Authenticator and show it the QR code
- Move away from that screen and pretend that no-one else was shoulder surfing you.
You forgot step 6 1/2) Take a screenshot and keep it somewhere safe so that if you ever lose the phone that has GA installed you won't be locked out of your account. (Exporting the code generator account to a different device is not possible, for obvious raisins.)
-
@PJH said in Google Authenticator API - like dragons, for cans:
Slight tangent...
@PJH said in Google Authenticator API - like dragons, for cans:
TYPE - hotp or totp - (whether it's a counter- or time-based OTP)
[...]
counter - where to start the sequence with HOTP
Google's Authenticator, while allowing you to manually enter keys, doesn't actually allow you to enter the starting counter number for a HTOP, so you have to start from
counter=0While the server you're trying to authenticate against is probably on a vastly different value...
AFAIK, GA only works with time-based OTP. It doesn't work for the counter-based ones at all.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
(Exporting the code generator account to a different device is not possible, for obvious raisins.)
Depends on the app you're using - I backed up the tokens on my old phone and imported them on the new one.
-
@PJH said in Google Authenticator API - like dragons, for cans:
Note, that because of that
:separator,:cannot appear in eitheruser_idorissuer. Got a colon in your company name? Tough.They're meant to be short, human-readable identifiers, so that really isn't a problem.
Basically, they are just supposed to be so that if a user has multiple accounts on their code generator app, they know which code is the one that they should use for that specific account (on that site).
-
@ender Yes, some apps do allow you to back up/restore the secret codes or move them to a different device. GA doesn't let you.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
AFAIK, GA only works with time-based OTP. It doesn't work for the counter-based ones at all.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
They're meant to be short, human-readable identifiers, so that really isn't a problem.
well since it's not part of the generation algorithm, it's technically not a problem.
s/:/googlecolon/gor whatever.It's the thought (or rather lack of) that went into the API that made it an issue to begin with.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
@ender Yes, some apps do allow you to back up/restore the secret codes or move them to a different device. GA doesn't let you.
So what you're saying is it's utterly worthless.
2FA either needs to be transferrable between devices, trivially resettable, or not tethered to a very fragile device. And yes, both of the first two severely weaken actual security.
There's a reason RSA hardtokens are fully potted and effectively bombproof.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
Are you saying the latest version ignores it?
No. Old versions expect it in the label, new versions expect it as a parameter.
To cater for either (or 3rd party who use either schema), you must specify it twice.
Of course, any new 3rd party authenticator using this must now look for both as well.
This isn't how deprecation->obsolescence works. This is the complete opposite, because it's ingraining things that should no longer be.
-
@Weng said in Google Authenticator API - like dragons, for cans:
There's a reason RSA hardtokens are fully potted and effectively bombproof.
Even then, would you really trust a vital account to that device? What if some idiot accidentally tosses it in the bin or something and by the time you notice it's already buried in a garbage dump 100km away?
You always need an external backup of some sort. This is why practical security is so hard, even if the theory is simple.
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
Exporting the code generator account to a different device is not possible, for obvious raisins.
Not from Google Authenticator it isn't...
-
@sloosecannon said in Google Authenticator API - like dragons, for cans:
@anotherusername said in Google Authenticator API - like dragons, for cans:
Exporting the code generator account to a different device is not possible, for obvious raisins.
Not from Google Authenticator it isn't...
The one I use is authenticator plus. It allows sync via Google Drive
-
@anotherusername said in Google Authenticator API - like dragons, for cans:
Exporting the code generator account to a different device is not possible
Why? It seems like that should be a thing it can do. It's not like any of the QR code's data gets lost when the authenticator reads it.
-
@sloosecannon said in Google Authenticator API - like dragons, for cans:
It allows sync via Google Drive
Now you have a backup of your Google account's access keys in your Google account!
(me, I keep a manual copy in my KeePass database - plus the printed backup codes)
-
@ben_lubar It's by design. It permanently ties the secret key to the physical device so malware (or bad users) can't get it out if it's temporarily compromised.
In fact I believe "here's a secret key, now store it and never let it out again" is the main feature of all security hardware: smart cards, TPMs, or in this case Android's Hardware-backed Keystore.
-
@Weng said in Google Authenticator API - like dragons, for cans:
fully potted
I didn't pot mine, I put it on a keychain.
Was I supposed to bury it next to the tomato plant?
-
@anonymous234 said in Google Authenticator API - like dragons, for cans:
@ben_lubar It's by design. It permanently ties the secret key to the physical device so malware (or bad users) can't get it out if it's temporarily compromised.
In fact I believe "here's a secret key, now store it and never let it out again" is the main feature of all security hardware: smart cards, TPMs, or in this case Android's Hardware-backed Keystore.
Ok, but if malware is running on your android phone, couldn't it also change the password to your GMail account?
-
@blakeyrat said in Google Authenticator API - like dragons, for cans:
@Weng said in Google Authenticator API - like dragons, for cans:
fully potted
I didn't pot mine, I put it on a keychain.
Was I supposed to bury it next to the tomato plant?
Fully potted as in "all the electronics are encased in a solid block of epoxy".
The IT security crowd and opensource folk like to interpret potted boards as an attempt at security by obscurity because it makes it really hard to take them apart and see how they work without destroying them.
But it's really a durability thing, because it utterly prevents components from moving relative to each other, and prevents contamination from water, dust, etc.
And the epoxy itself is super tough and therefore very protective.
-
@blakeyrat so, yes, you could also have buried it next to the tomato plant, with a webcam pointed at it, but the webcam would fail pretty quickly compared to the RSA key. Also you can probably beat it medium-style with a hammer without breaking much more than the screen.
-
@PJH said in Google Authenticator API - like dragons, for cans:
@anotherusername said in Google Authenticator API - like dragons, for cans:
AFAIK, GA only works with time-based OTP. It doesn't work for the counter-based ones at all.
Well that's pretty much entirely pointless.
@Weng said in Google Authenticator API - like dragons, for cans:
@anotherusername said in Google Authenticator API - like dragons, for cans:
@ender Yes, some apps do allow you to back up/restore the secret codes or move them to a different device. GA doesn't let you.
So what you're saying is it's utterly worthless.
2FA either needs to be transferrable between devices, trivially resettable, or not tethered to a very fragile device. And yes, both of the first two severely weaken actual security.
No, whatever service that you're trying to use 2FA for should have some way of verifying your identity and then resetting the 2FA, in case you somehow lose your device. If it doesn't, then that's on the service.
But having the QR code somewhere is awfully nice if you want to avoid all of that hassle and just add the same 2FA code to a different device.
@ben_lubar said in Google Authenticator API - like dragons, for cans:
@anonymous234 said in Google Authenticator API - like dragons, for cans:
@ben_lubar It's by design. It permanently ties the secret key to the physical device so malware (or bad users) can't get it out if it's temporarily compromised.
In fact I believe "here's a secret key, now store it and never let it out again" is the main feature of all security hardware: smart cards, TPMs, or in this case Android's Hardware-backed Keystore.
Ok, but if malware is running on your android phone, couldn't it also change the password to your GMail account?
It's not about malware, it's about what happens if your device isn't locked and some bad person gets access to it for 30 seconds. They shouldn't be able to copy all of the secret keys in your electronic keychain.
-
@anonymous234 said in Google Authenticator API - like dragons, for cans:
@sloosecannon said in Google Authenticator API - like dragons, for cans:
It allows sync via Google Drive
Now you have a backup of your Google account's access keys in your Google account!
(me, I keep a manual copy in my KeePass database - plus the printed backup codes)
If my phone, retired phone, and tablet all simultaneously die then yes I suppose I'm fucked, and will have to use the backup codes in LastPass.
-
@sloosecannon A few months ago I would have said "Use 1Password instead since that can act as an OTP authenticator app", but their pricing shenanigans with the new versions a few months ago (requiring you to download the app to see the non-subscription pricing; no longer bundling Windows and Mac versions together) annoy me enough that I don't recommend anybody start using it anymore.
Are there other password keepers that offer that functionality? (I take it LastPass doesn't given what you just said.)
-
@Unperverted-Vixen said in Google Authenticator API - like dragons, for cans:
Are there other password keepers that offer that functionality? (I take it LastPass doesn't given what you just said.)
There are a couple of plugins for KeePass for Windows that give OTP functionality, in both the "you must provide an OTP from somewhere else to open the database" and "KeePass provides OTPs for use in other software" senses.
KeePass2Android has the functionality of one of each kind of plugin built-in.
-
@Unperverted-Vixen said in Google Authenticator API - like dragons, for cans:
(I take it LastPass doesn't given what you just said.)
I believe it does, actually. I just haven't used it because i started using authenticator plus first.
-
@Weng said in Google Authenticator API - like dragons, for cans:
But it's really a durability thing, because it utterly prevents components from moving relative to each other, and prevents contamination from water, dust, etc.
And can't be done with a smartphone CPU because of the epoxy's effect on heat dissipation.
-
@ben_lubar That (and disabling 2FA) requires re-entering your password, so hopefully not.
-
@anonymous234 said in Google Authenticator API - like dragons, for cans:
This is why you trademark your standards! So you can sue anyone who claims to implement it but doesn't.
Can you really do that? It sounds too awesome.
-
@marczellm Sort of... as I understand, you can trademark a logo so other people can't legally use it in their products without your permission (example). That doesn't stop them from simply selling products without the logo. Or simply using the logo anyway because they're in China and don't give a crap.
-
@anonymous234 I know what a trademark is, but can you trademark a standard?
-
@marczellm said in Google Authenticator API - like dragons, for cans:
can you trademark a standard?
No. Standards may be copyrighted, may talk about patented techniques, and may have trademarked symbols placed upon them (e.g., of the standards organisation responsible for producing them) but cannot be trademarked themselves as they are not a piece of non-functional trade-dress.
-
@PJH said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
-
@Zecc said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
English of course, it says so right there:
-
@M_Adams said in Google Authenticator API - like dragons, for cans:
@Zecc said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
English of course, it says so right there:
Instead of a spacebar it has a button you press to insert the word English.
-
@ben_lubar said in Google Authenticator API - like dragons, for cans:
@M_Adams said in Google Authenticator API - like dragons, for cans:
@Zecc said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
English of course, it says so right there:
Instead of a spacebar it has a button you press to insert the word English.
On second thought, maybe Welsh? Given the vowels are oddly placed giving precedence to the consonants...
-
@M_Adams said in Google Authenticator API - like dragons, for cans:
Given the vowels are oddly placed giving precedence to the consonants...
The vowels all appear to be on the home row under the left hand. Or would be if it was a physical keyboard…
-
@Zecc said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
Dvorak.
-
@Zecc said in Google Authenticator API - like dragons, for cans:
@PJH said in Google Authenticator API - like dragons, for cans:
What kind of weird ass keyboard is that?
Often known as a "soft" keyboard, or "on-screen" keyboard, it is a simulated input method commonly used on devices lacking a physical equivalent for the purpose of providing that functionality.
