Live data from Hacker News

How I reverse engineered my bank's security token

valverde.me

21–30 of 67 posts

Re: How I reverse engineered my bank's security token

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

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: https://play.google.com/store/apps/details?id=com.yubico.yub... 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 ;-)

Re: How I reverse engineered my bank's security token

#25
post #6

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.

What's the point on securing the algorithm?

Especially since this is just OATH-TOTP under the hood, with a weird key provision scheme that uses SHA1 of device's ID (huh?) instead of bank- or user-provided random key.

On the contrary, I think it should be open, so anyone can audit the application.

Re: How I reverse engineered my bank's security token

#26
post #6

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.

I would add one thing to the list though: the PIN is stored as part of the data, instead of being used as the basis of an encryption key. With PBKDF2 and the option to supply longer PINs/passphrases, this can improve security by another significant step.

Re: How I reverse engineered my bank's security token

#27
Think about it for a moment. He did all this (impressive) work just because the application that the bank provided sucked.

Now, once he writes a better app, what do you think the bank will do? Hire him (or buy the app), or fight him?

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

Re: How I reverse engineered my bank's security token

#28

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…

[deleted]
Post reply on HN