Interested in creating an alternate 2FA app for Android?

[CIYAM]

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).

[btchip]

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

What exactly is wrong with RFC 6238 ?

[CIYAM]

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

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

What exactly is wrong with RFC 6238 ?

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.

[btchip]

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

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.

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.

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)

[CIYAM]

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

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.

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).

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.

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 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.

[btchip]

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).

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)

[CIYAM]

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.

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?

[btchip]

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.

[CIYAM]

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)?

[btchip]

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

[btchip]

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

[CIYAM]

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

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:

Code:

hash( secret + to_string( timestamp / interval ) ).substr( 0, 6 );

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.

[CIYAM]

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).

[btchip]

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

[CIYAM]

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

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.

[DeathAndTaxes]

What exactly is wrong with RFC 6238 ?

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.

[CIYAM]

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).

[Mike Hearn]

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.

[CIYAM]

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).

[btchip]

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.