Provisioning codes for Google Authenticator

140 views
Skip to first unread message

Kris Lou

unread,
Jun 10, 2015, 6:23:34 PM6/10/15
to priva...@googlegroups.com
Hi all,

Thanks for your work on this - it has proved to be a nice solution for us.

Is there any way to manually provision the Google Authenticator without a QR code?

Thanks!

-Kris

Cornelius Kölbel

unread,
Jun 11, 2015, 12:42:22 AM6/11/15
to priva...@googlegroups.com
Hello Kris,

what do you want to achieve, do you have a work flow in mind?

* You can uncheck the checkbox "Generate OTP key on the server",
and then you can enter a seed. Not that nice, since you must
make up a key on your own.

* You can get the data out of the link of the QR code.
"Click _here_ to scan the QR code" contains the seed data.
You could copy the link and extract it.

So I assume you want to have the data displayed hex encoded?
Why?

Kind regards
Cornelius
> --
> You received this message because you are subscribed to the Google
> Groups "privacyidea" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to privacyidea...@googlegroups.com.
> To post to this group, send email to priva...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/privacyidea/d8695863-5974-47c0-a758-5c6a34b0cbf6%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Cornelius Kölbel
corneliu...@netknights.it
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel


signature.asc

Kris Lou

unread,
Jun 11, 2015, 12:55:32 PM6/11/15
to priva...@googlegroups.com
Potentially, for 2 reasons:

1) I like to store the provisioning key for future reference, but I know that re-provisioning with a new key (QR) is only a minor change.
2) For some users that do not want to use their mobile devices, I'll give an encrypted USB key with a provisioned Google Auth app (https://winauth.com/).  I also have some users at an off-site location that is obviously more difficult to provision.

I realize that this is not a best case for 2FA, but thought I'd ask.  It seems like my boss goes through 3 phones a year.

Thanks,
-Kris

Cornelius Kölbel

unread,
Jun 11, 2015, 1:15:45 PM6/11/15
to priva...@googlegroups.com
Am Donnerstag, den 11.06.2015, 09:54 -0700 schrieb Kris Lou:
Potentially, for 2 reasons:


1) I like to store the provisioning key for future reference, but I know that re-provisioning with a new key (QR) is only a minor change.
At the moment you would have to right click the image and save the image as...

(I) But in future I could think of a workflow, that sends the Enrollment information to the user, either via email or printed (postal letter).
In this case this could also be saved.

It is rather similar to the enrollment letter in the commercial product "SafeNet Authentication Manager".
2) For some users that do not want to use their mobile devices, I'll give an encrypted USB key with a provisioned Google Auth app (https://winauth.com/).  I also have some users at an off-site location that is obviously more difficult to provision.
OK, winauth needs the secret key to inserted as text into the application.
This might be done by just adding the secret key in cleartext next to the QR-Code, so that it can be copied and stored on the USB drive easily.
(A) I think this can be easily implemented.

I also have suggestion for the offsite guys.
There is already a registration token type available.
http://privacyidea.readthedocs.org/en/latest/search.html?q=registration&check_keywords=yes&area=default
It is not visible at the UI at the moment, since it is intended to be used for mass registration.
(A) Do you thin it needs to be added to the UI, so that the administrator can pass the registration code to the users manually?

Kind regards
Cornelius

For more options, visit https://groups.google.com/d/optout.
signature.asc

Cornelius Kölbel

unread,
Jun 11, 2015, 1:27:15 PM6/11/15
to priva...@googlegroups.com
Easy.

You would be able to copy the seed to winauth..
unknown-HC2TZX
signature.asc

Cornelius Kölbel

unread,
Jun 11, 2015, 2:01:38 PM6/11/15
to priva...@googlegroups.com
Hi Kris,

I implemented the enrollment of the Registration token to the webui and
the displaying of the seed in the enrolled token dialog.

This is uploaded at github and will be available shortly in the unstable
ppa-repository

ppa:privacyidea/privacyidea-dev

It will be part of release 2.4 which will be released LATEST in august.

But I assume, I get bored till then, so 2.4 will be early ;-)

Kind regards
Cornelius

Am Donnerstag, den 11.06.2015, 09:54 -0700 schrieb Kris Lou:
> https://groups.google.com/d/msgid/privacyidea/CAGyTNKEQDP6r1yy0ob5MZgeR39VD4gtGma7XOf6yTwY4FXNY2g%40mail.gmail.com.
signature.asc

Kris Lou

unread,
Jun 11, 2015, 4:17:22 PM6/11/15
to priva...@googlegroups.com
Wow, that was fast.

Thanks for going this far with it, and for the suggestions - I obviously have some reading to do (and we're on CentOS, so will be installing/upgrading from pip).

Also, some of my users are extremely privacy conscious - so they don't like installing apps that ask for access to Contact lists and the like.  Unfortunately, this also includes many QR readers (or at least those suggested by GAuth).  So, this is another reason why I was asking for the "Manual Provisioning" methods that correlate with the Authenticator app configs.


Thanks again,

Cornelius Kölbel

unread,
Jun 11, 2015, 5:04:13 PM6/11/15
to priva...@googlegroups.com
Hi Kris,

regarding your privacy conscious users - have you ever thought of using hardware for this purpose of authenticating?
Especially the yubikey is cute. You can initialize it with your own key material and authenticate against privacyIDEA.
You can be sure, that no vendor knows your secret keys and it is hardware. You can be sure that no trojan or virus extracts the key from the poor store on the smartphone.

If you need any more input on this, drop me a note.
Cornelius

For more options, visit https://groups.google.com/d/optout.
signature.asc

Der PCFreak

unread,
Jun 12, 2015, 1:26:58 AM6/12/15
to priva...@googlegroups.com
Hi Kris,

I only would recommend to use event based otps (hotp) instead of time
based otps (totp) when you use software based otps.

Why?

Imagine someone is able to get a working and configured copy of a
software otp you deployed, then he/she could always use it because if
time based it always shows the same as the "original".
When useing totp (event based), the otp is based on a counter which will
(if someone stole a copy of your app) not work if

a) the otp on the stolen device is "from the past"
b) the otp counter on the stolen device is too far away (usually
configurable on the server side) from the "original"

so you will detect if someone "stole" a hotp and used it because it will
fail sooner or later. with totp it will work like the "original".

Maybe you already thought of this but I just wanted to mention.

Kind regards

PCFreak

Cornelius Kölbel

unread,
Jun 12, 2015, 2:40:38 AM6/12/15
to priva...@googlegroups.com
Hi PCFreak, hi Kris,

thanks a lot for this good point.

Choosing between totp and hotp is always also a kind of a matter of...
...believes.

If the secret key gets compromised, you have a problem.
Many people say, you already have a problem, when using HOTP.

In the past I saw users, who were handed an HOTP hardware token.
As these users were lazy but clever, they pressed the button a hundred
times, and wrote down all the OTP values.
They generated a "TAN list". They could use this sheet of paper to login
with these OTPs, which they crossed of the list.

Such things can not happen with TOTP.

You are right, that - if the seed is compromised or copied on purpose -
there can be 2, 3 or a thousands copies of the token, without realizing
it. So it is harder to tell, if you are compromised.
In addition, the user himself could scan the QR code twice. Or have his
friend and colleagues scan the QR code. In some scenarios this is a
problem. When IT knows, that the users already gave their passwords to
their co-workers. They probably will also give the TOTP seed to their
co-workers. In this case HOTP would be a better choice.

Anyway, if I was the attacker and get hold of the HOTP seed, and my
latest OTP does not work, I am smart enough to try

HOTP(current_counter + 10)
HOTP(current_counter + 20)
HOTP(current_counter + 40)
HOTP(current_counter + 80)

And I will get a hit...
Nevertheless, the original user will realize, that his next OTP value
will not work - since I used it.
The question is, if the original user is smart enough, to think of the
possibility, that his token is compromised.

It is hard to tell. I personally prefer HOTP token, since I experience
it to be more robust.

Thanks a lot for your input and bringing up this topic
Cornelius
signature.asc

Der PCFreak

unread,
Jun 12, 2015, 3:38:11 AM6/12/15
to priva...@googlegroups.com
Hi Cornelius,


On 12.06.2015 08:40, Cornelius Kölbel wrote:
> Hi PCFreak, hi Kris,
>
> thanks a lot for this good point.
>
> Choosing between totp and hotp is always also a kind of a matter of...
> ...believes.
>
> If the secret key gets compromised, you have a problem.
> Many people say, you already have a problem, when using HOTP.
>
> In the past I saw users, who were handed an HOTP hardware token.
> As these users were lazy but clever, they pressed the button a hundred
> times, and wrote down all the OTP values.
> They generated a "TAN list". They could use this sheet of paper to login
> with these OTPs, which they crossed of the list.
>
> Such things can not happen with TOTP.
I personally use TOTP for hardware token and HOTP for software token.
We have users that "play" with their hardware-token-button all the time
so totp is the choice here
to avoid problems.

For the HOTP our server (freeradius + oathtool +liboath + pam_oath is
configured to always fail
on "old" counters and only accept 5 passwords in the future and if one
"from the future" is used
the server adjusts itself to use this as the current, so for an attacker
with a copy of the token
has a harder job.

Also on the authentication server side you should implement a lockout
mechanism after too many
failed logins, then in my opinion, the security is sufficient but of
course (as always) not perfect.

Greets

PCFreak

Cornelius Kölbel

unread,
Jun 12, 2015, 4:09:34 AM6/12/15
to priva...@googlegroups.com
Hi PCFreak,

yes, the sync-window is a problem for HOTP.
With privacyIDEA you can set autoresync.
(http://privacyidea.readthedocs.org/en/latest/configuration/system_config.html#settings)

It also uses a fail counter. Which is usually set to 10.
After 10 wrong login attempts and administrator needs to reset the
counter.

Kind regards
Cornelius
signature.asc

Kris Lou

unread,
Jun 12, 2015, 12:17:14 PM6/12/15
to priva...@googlegroups.com
Insightful discussion.  Thanks for all of your input.


--
You received this message because you are subscribed to the Google Groups "privacyidea" group.
To unsubscribe from this group and stop receiving emails from it, send an email to privacyidea...@googlegroups.com.
To post to this group, send email to priva...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages