Skip to content
This repository has been archived by the owner on Apr 6, 2021. It is now read-only.

Please allow specification of key in base 16 #35

Open
ThomasHabets opened this issue Oct 10, 2014 · 7 comments
Open

Please allow specification of key in base 16 #35

ThomasHabets opened this issue Oct 10, 2014 · 7 comments

Comments

@ThomasHabets
Copy link
Contributor

Original issue 35 created by tmh@nodomain.org on 2011-02-17T21:52:38.000Z:

Most OTP implementations (in fact every one I've seen except google's) requires and generates keys in base 16. If the app is to be useful with anything except google logins (and I personally have no wish to have multiple different authenticator apps on my phone) it needs to support that.

@ThomasHabets
Copy link
Contributor Author

Comment #1 originally posted by tmh@nodomain.org on 2011-02-17T21:53:42.000Z:

Please tag this as 'feature'. Google doesn't seem to let me do that.

@ThomasHabets
Copy link
Contributor Author

Comment #2 originally posted by adhintz@google.com on 2011-02-26T23:18:25.000Z:

Could you please provide an example OTP implementation that uses base 16? That way we would have something to look at and test against.

@ThomasHabets
Copy link
Contributor Author

Comment #3 originally posted by markus@google.com on 2011-03-09T21:19:44.000Z:

There are really not that many products available yet, that use RFC 4226. And there are several parameters that the specification leaves up to implementors.

So, as much as I would love to have everybody standardize on the-one-true encoding for HOTP and TOTP codes, I suspect we are not quite there yet.

Differences between base32 vs. hex are probably the least of our worries. But if you can point us to other implementations that are a) well-documented, and b) publicly accessible for testing purposes, we can certainly see what would be necessary to make our code accept and/or generate their data formats.

@ThomasHabets
Copy link
Contributor Author

Comment #4 originally posted by datamatrix on 2011-03-11T02:34:40.000Z:

oath-toolkit is a publicly accessible, reasonably well-documented RFC 4226 implementation, which currently only allows key input in hex.

@ThomasHabets
Copy link
Contributor Author

Comment #5 originally posted by markus@google.com on 2011-03-11T03:16:22.000Z:

You didn't go into details, but I suspect you were asking for a way to enter OATH-Toolkit keys into the Android application.

If so, the following one-liner is going to help, until somebody gets around to adding this feature to the Android application:

perl -e 'use MIME::Base32 qw(RFC); chomp(my $i = <>); print "https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/'`whoami`\\@`hostname`'%3Fsecret%3D" . MIME::Base32::encode(pack("H*", $i)) . "\n"'

Just copy and paste into a shell, then enter the key in hex. The script will output a URL that you can paste into your browser. The QR code can be scanned by the Android application.

Yes, I know, this isn't perfect. But at least is should get you going.

@ThomasHabets
Copy link
Contributor Author

Comment #6 originally posted by b.clifford on 2012-01-18T11:37:14.000Z:

I have oath-toolkit installed - I'd even let google have an account to test against if you can't manage to install it yourself... (pm me ;)

@ThomasHabets
Copy link
Contributor Author

Comment #7 originally posted by b.clifford on 2012-01-18T17:34:51.000Z:

btw, two other implementations which use base-16 are yubikey and gooze.eu

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant