Live data from Hacker News

How I reverse engineered my bank's security token

valverde.me

1–10 of 67 posts

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

#7
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 exactly does this give you as a minimum? If you distribute code to a client, they can look at it. The only way to prevent this is relying on some sort of "trusted hardware" model or not distributing code.

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

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

(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.)

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

#9
post #8

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. (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.)

This specific token is time-based, so a clone would not be detected.

On the other hand, counter-based tokens as you described them do exist, and it would indeed be simple to detect if one of those was cloned.

I wouldn't even call this an attack, given that you would need physical access to a rooted device to carry it out.

Post reply on HN