A very interesting read. Also, I think I saw you on facebook's hackathon this year!
How I reverse engineered my bank's security token
51–60 of 67 posts
Re: How I reverse engineered my bank's security token
#52Earlier quoted context omitted.
Ah, time-based tokens are basically against adversaries with physical access to your time-based token. Good against password guessers / leaked password databases, however, which is a much more realistic attack these days.
OTP tokens usually don't protect you against server database compromise because they're completely symmetric. The server has a copy of the seed/key stored in the clear. OTPs really only protect you against key logging
I mean for the password reuse case. You use the same password for example.com and Gmail. Someone steals the example.com password database. They still can't log into your Gmail account because they don't have your second factor.
Re: How I reverse engineered my bank's security token
#53Think 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…
I don't really agree with the description of the app: "the application that the bank provided sucked". What's the reason for this? The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it. ("calling the bank every so often after changing ROMs, resetting or changing phones") Does that app suck? I don't think so, you should reauthorize the app on every new device and if…
> The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it.
Lots of apps require you flash a new ROM actually. Dropbox and Gmail to name a couple.
Re: How I reverse engineered my bank's security token
#54This 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…
Oh -- and just don't put your phone in the same pocket as your YubiKey! ;-)
Re: How I reverse engineered my bank's security token
#55Earlier quoted context omitted.
I don't really agree with the description of the app: "the application that the bank provided sucked". What's the reason for this? The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it. ("calling the bank every so often after changing ROMs, resetting or changing phones") Does that app suck? I don't think so, you should reauthorize the app on every new device and if…
> The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it. Lots of apps require you flash a new ROM actually. Dropbox and Gmail to name a couple.
Huh? I installed dropbox without doing anything special. Gmail may not be installable from the internet, but gapps can be added without flashing the whole phone.
Re: How I reverse engineered my bank's security token
#56Earlier quoted context omitted.
I don't really agree with the description of the app: "the application that the bank provided sucked". What's the reason for this? The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it. ("calling the bank every so often after changing ROMs, resetting or changing phones") Does that app suck? I don't think so, you should reauthorize the app on every new device and if…
He was able to reverse engineer the whole process. The bank's app definitely sucks.
You know that everything can be reverse engineered, right? It only depends on the time you're prepared to spend on the problem.
Re: How I reverse engineered my bank's security token
#57Earlier quoted context omitted.
Which security concerns have been voiced against iTANs? I saw them as the equivalent of a one-time-pad, secure as long as both the secret and the index are not both intercepted. And super cheap and simple.
Phishing. A MITM attack could "intercept" real transactions and exchange the receiving bank account ID without the user noticing (some even will manipulate the account transaction history!) so you'll only notice it when your bank calls you or your ATM/debit card won't work anymore because your account is empty.
As a matter of fact, this is done (with user consent) by Sofort.com to authorize immediate payments. MITM as a service!
Re: How I reverse engineered my bank's security token
#58While 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. 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…
Luckily, that's not true!
First, I think chipTAN is not publicly documented, and given banks' track record in security matters, I certainly would not want to trust a system that is not publicly documented, and secondly, using a card that I am supposed to carry around all day instead of putting it into my safe at home for transaction authentication doesn't sound like that bright an idea to me.
mTAN is completely braindead, of course, given the essentially non-existent security of mobile networks.
Re: How I reverse engineered my bank's security token
#59Earlier quoted context omitted.
Which security concerns have been voiced against iTANs? I saw them as the equivalent of a one-time-pad, secure as long as both the secret and the index are not both intercepted. And super cheap and simple.
Phishing. A MITM attack could "intercept" real transactions and exchange the receiving bank account ID without the user noticing (some even will manipulate the account transaction history!) so you'll only notice it when your bank calls you or your ATM/debit card won't work anymore because your account is empty.
isn't the same attack valid with token based cards (I'm only familiar with RSA's tokens) .. as long as you're in the middle, anything goes..
Re: How I reverse engineered my bank's security token
#60Earlier quoted context omitted.
Phishing. A MITM attack could "intercept" real transactions and exchange the receiving bank account ID without the user noticing (some even will manipulate the account transaction history!) so you'll only notice it when your bank calls you or your ATM/debit card won't work anymore because your account is empty.
isn't the same attack valid with token based cards (I'm only familiar with RSA's tokens) .. as long as you're in the middle, anything goes..
Some of these tokens (active ones) display the transferred amount. I dont know if these are still actively used, though.