Oh, and btw, in case you missed this, Google Authenticator is open source (Apache License) : https://code.google.com/p/google-authenticator/
Topic: Interested in creating an alternate 2FA app for Android? - page 2. (Read 1971 times)
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)?
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
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)?
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?
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.
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?
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)
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.
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.
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)
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.
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 ?
What exactly is wrong with RFC 6238 ?
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).
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).
Jump to: