Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Reverse Engineering a Bank's Security Token 55

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.'"
This discussion has been archived. No new comments can be posted.

Reverse Engineering a Bank's Security Token

Comments Filter:
  • by girlintraining ( 1395911 ) on Saturday January 04, 2014 @01:04PM (#45865647)

    He found a way to accurately generate his unlock codes with some custom code and an Arduino clone.

    By itself, this isn't a bad thing. But the fact that they've obscured the crap out of their code suggests to me this wasn't done by a crypto expert, but an insecure programmer forced by management to develop a solution in a field he didn't fully understand, and did it homebrew. The overwhelming, vast, pitifully large, number of attempts made by non-crypto experts to do this result in a house of cards when it comes to security.

    There are standard, tested, and amply documented alternatives available. It's just criminal that this bank decided to elect some middle manager with no understanding of the technology and his lackies to impliment such a solution. I'm sure the bank official in question, who we'll call Sir Moron McMoneypants, thought that rolling their own would result in a more secure setup, because afterall... who's going to invest all that time to crack one bank's crypto when all the rest use the standard one?

    This is security through obscurity at its worst, and the managers involved should all be rounded up and excommunicated to some remote part of the world where there is no internet, no computers, and no way for them to talk to the outside world and thus give anyone who has money in their pockets any bad advice.

  • by russotto ( 537200 ) on Saturday January 04, 2014 @01:22PM (#45865741) Journal

    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.

  • by MightyYar ( 622222 ) on Saturday January 04, 2014 @01:23PM (#45865749)

    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.

  • by Anonymous Coward on Saturday January 04, 2014 @01:44PM (#45865859)

    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.

  • by Anonymous Coward on Saturday January 04, 2014 @02:12PM (#45866031)

    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.

  • 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.

Thus spake the master programmer: "When a program is being tested, it is too late to make design changes." -- Geoffrey James, "The Tao of Programming"