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.'"
Ugh. Amateurs! Generate error codes, not descriptive strings! Asshats! Security isn't supposed to reward someone for reverse engineering something. Layers, man. Layers of security!
Uhhh right, because that's so much use to the customer when their security token simply says "error -382".
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.
That's security through obscurity, and it can often be extremely detrimental...
When a piece of code runs on a device the user controls, it's not a case of *if* it can be reverse engineered, but simply a case of how long it takes and wether anyone is sufficiently motivated.
So given that, what's more important is that the algorithm itself has no flaws, and the seed/key values it uses cannot be compromised, neither of which should ever depend on the code being obfuscated.
However the obfuscation will deter/delay whitehats, and if the bank brings in any external testers (which they should, and in many places are required by law to do), the obfuscation will just increase the cost of testing while providing no security benefit.
Heavy obfuscation also increases development and other testing costs too, makes it more difficult to debug customer problems, and is likely to make the application larger and buggier.
All in all a lot of effort and cost to cause a minor inconvenience to anyone looking to attack the client.
Heavily obfuscated code is also often used to hide serious design flaws, there is quite a lot of software out there that on the surface looks quite secure, but once you start reverse engineering the binary you find severe shortcomings... Making something harder to find doesn't stop it being exploited, it just increases the time before its discovered by a whitehat and fixed.
Something should be secure even against an attacker who knows everything about how it works... Knowledge of the system should not enable any attacks. Common encryption algorithms and protocols are fully documented, and a lot of security critical devices are based on publicly available source code.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.