Bitcoin Forum

I've read a number of posts about getting 2FA and not trusting Google authenticator.

Although there is no reason not to trust their algo I am willing to offer 5 BTC for the creation of an Android app that basically works on a very similar algo (https://github.com/ciyam/ciyam/blob/master/src/crypt_stream.cpp#L144) in the hope that it will create an alternative that people can choose to use if they are wary of anything originating from Google.

The scope of the app would be to create multiple account entries that each contain a "shared secret" so that the 2FA could be used for multiple websites (it will be used by CIYAM Open as a first).

The Android app would have to be open source of course and preferably written in C++ - if you have any interest (and the skills) to develop such an app then please respond (if enough interest then I will set up a task on CIYAM Open for this).

I'm not really sure that replacing an open standard with a significantly weaker algorithm is such a good idea  ;D

What exactly is wrong with RFC 6238 ?

Can you please explain why the algorithm linked to is significantly weaker?


Technically nothing - the problem is that its more commonly known "name" has Google in it (as explained in the OP).

So the algo I have posted is similar but not exactly the same (so it won't be known as Google Authenticator). If you think the algo could be improved without turning it into Google Authenticator then I am all ears.

The HMAC key space is the size of the block size of the associated hash function - 64 bytes for SHA-1, versus random-size-of-a-C-int-so-often-4-or-8-bytes in your implementation, making it easy to bruteforce.


yes I got that, it's not IMHO a valid point - 2FA is not that popular today, all efforts to make it mainstream are welcome, including Google's implementation of a perfectly valid & audited algorithm. Will the people not using Google Authenticator because it has Google name in it also stop using Android because Google bought it ? it makes almost as much sense to me, at least until they come up with a valid technical issue, such as the "Network permission" of Google Authenticator application on Android, for example.

In any case, it's never a good plan to roll out your own cryptography. If you really want to move forward with that "other than Google" 2FA idea, perhaps try an HMAC with SHA-256 (same people will probably think it's cool, because it's like Bitcoin, you know), or SHA-3 (other people will probably think it's cool, because it's not designed by the NSA, you know)

I grok the key space point but I don't see how that makes it easier to "brute force" - surely the length of the "pin" being used is all that matters for brute forcing (as by definition brute forcing means that you are trying every possible value of that to "crack it").

Assuming a 6 digit pin and a 30 second interval then the brute forcing of either algo would take on average half a year or so (assuming you already know the user's password of course).


I do take your point about "rolling my own" (although I'm not convinced it's flawed yet but I am willing to be convinced) and yes I guess simply swapping hmac_sha1 for hmac_sha256 could be another useful approach.

The issue here is that an attacker getting hold of one of your generated OTPs by any mean (shoulder surfing, open wifi network ...) and knowing when it was generated can retrieve your PIN quite easily then impersonate you later. This is not the case with RFC 6238 implemented properly (i.e. the user should not be the one providing the password, to avoid being in the same situation)

If you have a hold of a users OTP and you the knew the time that it was used then for either algorithm then you can easily brute force the "pin" by just calling the "relevant totp" function across the key space of the PIN.

How is that key space going to be any different with the two approaches if the user is using say a 6 digit PIN?

of course it's the same - the only difference being that your approach forces this by design, while the OATH-TOTP implementations I've seen have the site using the OTP generate a random key, usually on at least 16 bytes.

Okay - maybe we are talking in tangents - as I've never actually *used* Google 2FA perhaps I am just missing something obvious here.

So using Google 2FA on an Android phone requires you to enter a 16 byte key/PIN per app (I honestly don't know and had assumed maybe incorrectly that it was a much shorter PIN in which case my approach would be equally as secure)?

Yes, using any common OATH-TOTP client requires you to enter a secret key per application.

On a smartphone, this is typically made easier by having a QR-code displayed so the application scans it.

For some screenshots you can check this http://www.pcworld.com/article/2036252/how-to-set-up-two-factor-authentication-for-facebook-google-microsoft-and-more.html

Oh, and btw, in case you missed this, Google Authenticator is open source (Apache License) : https://code.google.com/p/google-authenticator/

Okay - thank you very much for clarifying that (I had made a rather silly assumption and will not use an integer).

Now that I am aware of that I see the "key space" problem you were initially getting at I will change the algo although to my thinking something like:


which should be just as secure (assuming "secret" is say 64 bytes from /dev/random).

Of course an even longer secret (or perhaps hash iterations) should also help to harden it against the brute force attack that you mentioned.

Anyway if there are no Android devs interested in working on this then I'll probably just end up using Google 2FA after all (thanks for the link and your comments).

I'd say that's the best way to go in my opinion - you can also easily maintain a very clean version of the Open Source Google Authenticator project, removing all need for extra permissions such as Network Access for the application and extra code that might not be necessary or a bit on the risky side (such as provisioning codes from special URLs, HOTP, ...), thus helping open standards, and saving a few bitcoins in the process ;D

I will consider this and in the meantime I've updated the totp function in the CIYAM repo to take a "secret" string (which should be something in the order of 32-64 bytes of random data) and to use SHA256 rather than SHA1 to hash the combined secret and timestamp strings.

I understand that the TOTP approach being used in Google 2FA uses a HMAC rather than just hashing "secret + timestamp" but from my understanding after reading up about that is that there shouldn't be any need to use that approach when using a more secure hash algo where birthdays are far less likely to occur.

This +21 quadrillion.

RFC 6238 is a robust and peer reviewed standard.  There is absolutely no reason to roll your own.  Google auth isn't RFC 6238, Google Auth is an IMPLEMENTATION OF  rfc6238.  If you wanted to there may be value in making an independent implementation of the same standard.

i.e. you code and google's code given the same input would always produce the same values.

I mean the logic of rolling a new standard (a crypto one at that) would be like saying "I don't trust Verisign certs so I am going to roll my own alternative to SSL".  The obvious (at least to me) solution instead would be to keep using the robust and peer reviewed standard and making an ALTERNATIVE to Verisign.

I *get* the message but really this is only a couple of lines of code - it is not anything like me trying to write my own "crypto library" at all but instead "using" a trusted hash algo to do a very simple thing (which is what I perhaps have wrongly considered a TOTP to be - something trivial).

But sure - if anyone is interested in creating an alternate RFC 6238 implementation for Android then I will put the 5 BTC towards that (the point being to promote 2FA and disassociate the name Google from it because of people's distrust of that name).

As this forum itself is lacking in 2FA maybe theymos might also be interested in contributing to this (and yes if the forum wanted to contribute then it will be done RFC 6238 all the way).

Given that Google employees have written large amounts of code for Bitcoin directly, if someone refuses to use a Google authored open source app, running on a Google authored open source operating system, to do 2FA as part of using a P2P network that contains non-trivial amounts of Google authored (open source) code ...... then they have problems.

I do basically agree with this Mike - but it was a sentiment I had picked up from various other posters and I had also read that the current version of Google Authenticator needs to be given network rights (exactly why I have no idea but if it can get its *secret* from a QR code then I wouldn't think it would need that and it is probably this issue in particular that is bothering people).

I didn't check the details but I assume it does that for time synchronization.

That'd be another improvement for a version based on it : issue a warning (or disable the key altogether) if the devices goes back in time. With the current version it's perfectly fine to enter flight mode, set the time at some point in the future, store the generated code and set the time back.

A good point and something for further investigation.


BTW as the CIYAM open source project uses MIT/X11 is that going to make it problematic to simply drop in that source code (as I am only interested in using the pretty much open slather licensing that MIT/X11 allows)?

http://www.tldrlegal.com/compare?a=MIT+License&b=Apache+License+2.0+(Apache-2.0) seems to agree on merging code (with conditions, not replacing one with the other, of course)

(btw, great site name  ;D)

Well - I have put together my own version (to avoid licensing issues) that does "Google 2FA" now (the following sample source is using a test vector that I found in researching this so both the "key" and "tm" are hard-coded for the test):


It's much uglier than the 3 line algo using SHA256 but I guess I won't be lectured now for "rolling my own crypto" with it. :)

Also interestingly enough from what I've read Google Authenticator does *not* strictly adhere to the RFC (I think this might be due to the way it does base32 conversions as it doesn't deal with padding).

Okay - I did find this fork of Google Authenticator: https://github.com/kaie/otp-authenticator-android but it stills needs the Network permission to install the .apk.

I don't think it is worth 5 BTC to just remove this capability - but if someone would like to clone it and do just that then I will be happy to offer a 2 BTC reward.

Indeed, very little work :)
https://github.com/kactech/otp-authenticator-android/commit/ed1a664a23c75f53f813a690987060b042d134f0
binary
https://dl.dropboxusercontent.com/u/24177759/tmp/Google_Authenticator.apk

Indeed - I had no idea it would be a one-liner.

Well - if you don't mind could you also remove the "vibrate" permission (I don't see any reason for it to be doing that either) and then give me a BTC address.

Here you go https://github.com/kactech/otp-authenticator-android/commit/1591300b8c8a957e0db8222e3bfa0eda76e5b421
Binary updated.
But I have to check if it won't crash without vibra! :)

Thanks - and a promise is a promise so I will pay 2 BTC for this (you can PM the address if you don't want it public or just put it in a reply here).

My BTC address 1KFy5cc4tkLXZm2FVKgeUxouMs4M7UYp7A

2 BTC sent - https://blockchain.info/tx/ff7973b3c7129562dc94a70ebcf2b848c19eb5d7aba60679b6701a17a699f34c - well done!

Also if you are interested in http://ciyam.org/open/?cmd=view&data=20121223024638595000&ident=M100V131&chksum=06d7fdb4 then I might put some BTC towards that.

Thank you CIYAM Open!
What a great people here, why I waited so long to join this forum?
Had to PM this MAN, incredible...