Think about it for a moment. He did all this (impressive) work just because the application that the bank provided sucked.<p>Now, once he writes a better app, what do you think the bank will do? Hire him (or buy the app), or fight him?<p>How much effort do we collectively waste because of moronic organizations that force their crap upon us, that we cannot escape from? (You can go to a different bank, but what if they all uniformly suck?)
Wonderful work, and thank you for documenting the experience. From the title, I thought this would be a story about decoding a banking website's cookies and gaining access to other peoples accounts, or something similar. I was quite surprised to see that your bank did basically everything right. I was also surprised that you went so far as to implement an embedded clone. Very cool!<p>P.S. Consider yourself lucky to have such a bank. Here in the U.S., our major banks do not take security seriously by any stretch of the imagination (they have little incentive to).
This post had me guessing, but good work. First I saw the card with codes and thought you'd be showing that they weren't randomly created. But then you went on to the app -- and from the "What you'll need" section, when I saw the decompiler and the rest, I thought, "I know what comes next," but again I was surprised. You went above and beyond with the decryption of obfuscated error messages, etc. I could have guessed that it was OATH TOTP, as that's how these apps should work. Congrats on getting there from the source code, and indeed it's too bad they didn't retain compatibility with Google.<p>To fix the bug you mention -- root access from phone -- perhaps you could use something like Yubikey Neo loaded with ykneo-oath. I was searching the code for ykneo-oath (it's a java applet for the small key) to see where the timestamp was used for the dates, but it appears to be part of the YubiOATH app: <a href="https://play.google.com/store/apps/details?id=com.yubico.yubioath" rel="nofollow">https://play.google.com/store/apps/details?id=com.yubico.yub...</a> So you'd have to modify the app source (it's on github). The advantage, however, is that your secret isn't stored on your phone and vulnerable to root apps. Instead, your secret is on a mostly-offline key inaccessible from your phone. There's a YouTube video on how it uses NFC to get that OTP from the Yubikey when you need it. In case you're somewhat extremely paranoid, this might interest you. :) For the truly paranoid, you've found a way to disable account recovery methods while mixing time-based and counter authentication mechanisms ;-)
While I don't know about the situation elsewhere in the world, here in Germany most banks retired the single use codes (called TANS or (if indexed) iTans) quite some years ago for being insecure.<p>Most online banking will now require a code created per transaction that is 1. either send to you via text on your mobile phone (and is thus prone to phone malware) or 2. is generated using an external device and the chip on your banking card[1] (a true two factor authentication). Both system will show you the exact details (target account, amount to be send) before confirming the transaction. A virus on the computer is not sufficient to hijack your account.<p>Just out of curiosity: What security measures do your banks employ and do they allow you to upgrade to a higher security level?<p>[1]<a href="https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_faq/FAQ-TAN-Generator.jpg" rel="nofollow">https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_fa...</a>
Just another example of a proprietary implementation tweaking a de-facto standard / well-known algorithm (RFC 6238) just enough to be annoying.<p>Fresh in my mind is the Wii U controller reverse-engineering presented at 30C3, where the WPA-PSK handshake protocol was tweaked by performing bit-rotations on the resulting keys.
A good lesson for those of us who have had the idea of building a similar app to generate one-time passwords. Now we have a better idea of the minimum that needs to be done to build such an app securely. Thanks.
The only point of these token generators is to provide a stream of tokens, so that if the generator is cloned (which is trivial), that can be detected. That's it. As far as I can tell, this attack does not prevent the server from detecting a cloned token.<p>(To do that, you would have to install a new client on the victim's device that will increment its counter and tell you the counter when you ask.)
he is going to get a very awkard phone call from the bank...<p>Some years ago I stumbled with something similar on a webpage, posted it on reddit, and the next day the IT manager of the company called me... it was one of the most embarrassing days of my life.<p>Lesson: don't mess with other peoples work just because you can...