Slashdot Mirror
Reverse Engineering a Bank's Security Token
An anonymous reader writes "An engineer from Brazil has posted a technical walkthrough of how he was able to reverse engineer his bank's code-generating security token. He found a way to accurately generate his unlock codes with some custom code and an Arduino clone. (Don't worry: his method doesn't give him access to anybody else's codes.) 'Every exception thrown by this piece of code is obfuscated, as well as many of the strings used throughout the code. That is a major roadblock, since exception messages and strings in general are a great way of figuring out what the code is doing when reverse engineering something. Luckily, their developers decided to actually show useful text when a problem occurs and an exception gets thrown, so they wrapped those obfuscated strings with a.a, presumably a decryption routine that returns the original text. That routine is not too straightforward, but it is possible to get a high level understanding of what it is doing.'"
They used a standard algorithm (TOTP from RFC6238, with a Time Step X of 36 seconds and a T0 of April 1, 2007). They obfuscated it for what amounts to no good reason, but there's no loss of security. The problem of preventing someone who controls the device from obtaining the key is the DRM problem, unsolvable without specialized hardware.
This is security through obscurity at its worst,
I don't get that impression from reading TFA. It sounds like the implementation is mostly OK. Remember that all this generator is supposed to do is verify that you possess the token. Knowing the algorithm, so long as it is sound, shouldn't be a security problem - someone would still need to get their hands on the real token in order to clone it.
Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Does this work on Chuck E Cheese tokens too? I need to feed my skee ball addiction.
Better known as 318230.
The code should not need to be hard to reverse engineer. Good cryptographic systems need the secret to be secret and nothing else. Obfuscation can be a layer, but more often it is used to hide shoddy algorithms.
There is still a problem here. Even though physical access is needed to clone the device, it should be prohibitively difficult to do so, otherwise you leave yourself open to an attack where, for instance, someone steals the token while you're sleeping or left it unattended at home and clones it, then replaces it.
They retain a valid access token, and you're not aware of it because you still have yours.
I will not disclose the name of the company tho..
In other words: Your post is security by obscurity too.
Unsolvable even with specialized hardware, you just increase the costs for both yourself and any potential attacker... Probably increasing your own costs far more than that of the attacker.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
never confirm they had the correct username but a bad password
My bank must not have got the memo. After I submit my username, the login process presents an image associated with my account to prove to me that it is my bank and not a phishing site before I enter my password. Both GE Capital and Ally do this. Besides, one can verify whether a username corresponds to an account by attempting to register for an account under that username.
FYI: This is not a security breach. The algorithm is not supposed to be the secret. There are lots of android/iphone apps to do this, and most of them use HOTP or TOTP which is an IETF standard algorithm. The security is in the secret key that is generated when you run the app the first time. This key is synchronized between the server and the key generator when it is setup.