Thank you CIYAM Open!
What a great people here, why I waited so long to join this forum?
Had to PM this MAN, incredible...
Topic: Interested in creating an alternate 2FA app for Android? (Read 1971 times)
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.
My BTC address 1KFy5cc4tkLXZm2FVKgeUxouMs4M7UYp7A
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).
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!
Binary updated.
But I have to check if it won't crash without vibra!
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.
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.
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.
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.
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).
Code:
string key( "MZXW633PN5XW6" );
string secret = base32::decode( key );
uint64_t tm = 43499885;
uint8_t challenge[ 8 ];
for( int i = 8; i--; tm >>= 8 )
challenge[ i ] = tm;
string message( ( const char* )&challenge[ 0 ], 8 );
uint8_t hash[ 20 ];
hmac_sha1( secret, message, hash );
int offset = hash[ 19 ] & 0xf;
unsigned int truncatedHash = 0;
for( int i = 0; i < 4; ++i )
{
truncatedHash <<= 8;
truncatedHash |= hash[ offset + i ];
}
truncatedHash &= 0x7fffffff;
truncatedHash %= 1000000;
string pin = to_string( truncatedHash );
while( pin.length( ) < 6 )
pin = '0' + pin;
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).
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
)
(btw, great site name
) 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.
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.
Oh, and btw, in case you missed this, Google Authenticator is open source (Apache License) : https://code.google.com/p/google-authenticator/
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)?
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.
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).
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 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).
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.
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.
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
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).
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.
Jump to: