Reverse Engineering a Bank's Security Token

← Back to Stories (view on slashdot.org)

Reverse Engineering a Bank's Security Token

Posted by Soulskill on Saturday January 4, 2014 @04:39AM from the push-button-get-numbers dept.

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.'"

55 comments

Min score:

Reason:

Sort:

Security Measures Made Hard To Decipher? by Anonymous Coward · 2014-01-04 05:01 · Score: -1

'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.
It's supposed to be difficult!

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!
1. Re:Security Measures Made Hard To Decipher? by beelsebob · 2014-01-04 05:10 · Score: 2
  
  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".
2. Re:Security Measures Made Hard To Decipher? by Anonymous Coward · 2014-01-04 05:19 · Score: 1
  
  It's not supposed to be useful for the consumer. If they are running into errors with authentication related processes they need to either get tech support or try again later.
  Useful authentication error strings make breaking in a guessing game. You shouldn't even tell them that their password is wrong. "Login Failed!" is more than enough (never confirm they had the correct username but a bad password).
3. Re:Security Measures Made Hard To Decipher? by Anonymous Coward · 2014-01-04 05:44 · Score: 3, Insightful
  
  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.
4. Re:Security Measures Made Hard To Decipher? by Bert64 · 2014-01-04 06:43 · Score: 2
  
  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!
5. Re:Security Measures Made Hard To Decipher? by epyT-R · 2014-01-04 13:10 · Score: 1
  
  administrators/developers are users too. I'd prefer to have the error code AND the description.
6. Re:Security Measures Made Hard To Decipher? by beelsebob · 2014-01-04 13:57 · Score: 1
  
  You shouldn't tell them their PIN is wrong and that if they get it wrong 2 more times, then their card is going to be blocked? Riiiiight....
7. Re:Security Measures Made Hard To Decipher? by AmiMoJo · 2014-01-04 16:51 · Score: 1
  
  I doubt that the original source code used for development and debugging is obfuscated. Chances are they run it through a script that renames everything and removes and left over debug data. It's a fairly standard thing to do.
  In other words I doubt that they are relying on obfuscation for security, it was just a checkbox in the build system that costs them nothing.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
8. Re:Security Measures Made Hard To Decipher? by Anonymous Coward · 2014-01-05 06:46 · Score: 0
  
  I think you got lost somewhere, we weren't talking about entering PINs. Those messages would be okay, because if someone has your bank card they can be pretty sure it is valid, not so with a random username they might have guessed, and I'm sure most crooks know they'd only get three attempts at entering a PIN.
9. Re:Security Measures Made Hard To Decipher? by RockDoctor · 2014-01-08 05:55 · Score: 1
  
  I think that the point is that the developers can have what they want, but after putting the program through it's acceptance and validation tests, the useful (to a reenigne) error descriptions should be stripped out. Really out. It should NOT be left in place for the public-facing code.
  
  --
  Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
Read between the lines by girlintraining · 2014-01-04 05:04 · Score: 1, Insightful

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.

--
#fuckbeta #iamslashdot #dicemustdie
1. Re:Read between the lines by Anonymous Coward · 2014-01-04 05:15 · Score: 0
  
  Looking at the details in the post makes me doubt that the bank rolled out their own application. Some of the details in the post actually point to a standard setup that they bought from a company.
  I will not disclose the name of the company tho..
2. Re:Read between the lines by russotto · 2014-01-04 05:22 · Score: 5, Insightful
  
  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.
3. Re:Read between the lines by MightyYar · 2014-01-04 05:23 · Score: 4, Insightful
  
  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.
4. Re:Read between the lines by Anonymous Coward · 2014-01-04 05:25 · Score: 0
  
  Even people who make use of standards tend to mess them up or have other side channel attacks introduced by how they use it. I've always assumed the attacker knows what I know, so how do I make a secure system if someone knows the exact layout of my system?
  
  When I was fresh out of college, I used AES for create an encrypted token. I didn't know what the IV was, so I used a static IV, but I did know that if a given byte stream is encrypted with the same key, it will result in the same output, so I added random data to the beginning. I also know that block-mode re-encrypted at the beginning of each block, so I just made sure to use stream cipher mode.
5. Re:Read between the lines by Anonymous Coward · 2014-01-04 06:07 · Score: 1
  
  It does break some assumptions though: For any token device, someone can clone it without your knowledge and abuse it.
  Having the physical token is no longer the assurance against abuse by a third party that one would assume.
6. Re:Read between the lines by Anonymous Coward · 2014-01-04 06:12 · Score: 3, Insightful
  
  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.
7. Re:Read between the lines by Anonymous Coward · 2014-01-04 06:28 · Score: 0
  
  Errrr... okay we're talking about an android app. Sorry about my parent post, this isn't even something that can meet a high level of security to begin with, and I'm not sure it's worth talking about any further.
8. Re:Read between the lines by Anonymous Coward · 2014-01-04 06:31 · Score: 0
  
  That is not a valid assumption when it comes to general purpose computers, which smartphones certainly have become by now.
9. Re:Read between the lines by Anonymous Coward · 2014-01-04 06:34 · Score: 3, Funny
  
  I will not disclose the name of the company tho..
  In other words: Your post is security by obscurity too.
10. Re:Read between the lines by Bert64 · 2014-01-04 06:46 · Score: 4, Informative
  
  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!
11. Re:Read between the lines by Bert64 · 2014-01-04 06:50 · Score: 1
  
  Such an assumption has always been false.
  The problem is the obscurity of the code, if you don't know how it works then you can't be sure...
  If you do know how it works (as mentioned above, TOTP from RFC6238) then you know that it can be cloned, but only if you have the initial seed values...
  Knowledge is power, if you as a user know how the system works then you know what to protect, and you can more easily raise the appropriate red flags if you detect compromise of the seeds.
  As a user i would never be happy with a black box and no knowledge of how it works.
  
  --
  http://spamdecoy.net - free throwaway anonymous email - avoid spam!
12. Re:Read between the lines by Anonymous Coward · 2014-01-04 07:02 · Score: 0
  
  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
  It's clear that someone doesn't understand the technology and the standards, but I don't think it was the bank.
13. Re:Read between the lines by MightyYar · 2014-01-04 07:26 · Score: 1
  
  But this "token device" is a smartphone, and the bank generator is just an app. You have to assume that physical access means security has been compromised, just as with any other computer. There is nothing on a smartphone that can't be cloned with Titanium Backup and friends plus a few minutes of time.
  
  --
  W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
14. Re:Read between the lines by girlintraining · 2014-01-04 08:19 · Score: 1
  
  Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.
  Since has has duplicated the functionality of the device, including its ability to generate codes... then the "secret device id" is no longer secret. It also invalidates the security model that you need to be in physical possession of the token to access the account.
  He has effectively copied a key that had "do not duplicate" stamped on it. This attack could be carried out against a customer and then used to impersonate them in the future.
  This is not my definition of security that is working, and I'm disappointed that Slashdot has downmodded me for pointing this out... it's as if people are are becoming incapable of critical thinking.
  
  --
  #fuckbeta #iamslashdot #dicemustdie
15. Re:Read between the lines by Animats · 2014-01-04 08:29 · Score: 1
  
  Right. But a big problem is preventing some hostile app on the user's phone from obtaining the user's secret key used in the challenge/response algorithm. With the code reverse engineered, atttackers now know where to go looking for that key and what to do with it when they have it.
  Smartphones are not a secure platform. The carrier and Google (for Android) or Apple (for their phones) have total backdoor access. So does anyone who has their signing keys.
16. Re:Read between the lines by Anonymous Coward · 2014-01-04 08:44 · Score: 0
  
  If your security depends on the assumption that android malware authors don't know how to use a java decompiler, you have a problem.
17. Re:Read between the lines by MightyYar · 2014-01-04 10:20 · Score: 1
  
  It also invalidates the security model that you need to be in physical possession of the token to access the account.
  That was not the security model. If that were the security model, the bank would require a dongle instead of an Android app. The security model is that he possesses a unique ID, a password, and a token (in this case, generated from his Android's ID). An attacker would need all three of those things to access his account. One can be read in plain text, one can be picked up with a keylogger, and the third by cloning his phone. Certainly not perfect security, but every piece makes an attacker's life more difficult.
  Now if he had one of those little hardware dongles and he figured out how to clone it without obviously tampering with the dongle... that would be disturbing news for users of the dongle.
  
  --
  W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
18. Re:Read between the lines by jimicus · 2014-01-04 11:00 · Score: 1
  
  Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.
  Worse than "bad".
  Looking at the (admittedly obfuscated) screen grabs and the comments that say the bank provide RSA hardware tokens if anyone wants one - I reckon it's a software implementation of an RSA SecurID token, probably bought in directly from RSA. And if it's bought in from a third party, it follows that anyone else who's bought in the same product would almost certainly be vulnerable to the same issues.
19. Re:Read between the lines by Anonymous Coward · 2014-01-04 11:25 · Score: 0
  
  Android's SDK enables by default the obfuscation:
  
  The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. Because ProGuard makes your application harder to reverse engineer, it is important that you use it when your application utilizes features that are sensitive to security like when you are Licensing Your Applications.
  ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode. Having ProGuard run is completely optional, but highly recommended.
20. Re:Read between the lines by mveloso · 2014-01-04 13:30 · Score: 1
  
  The obfuscated it for the same reason that passwords on-disk should be encrypted: to make it harder for idiots to figure out anything. If you really want to make life difficult you write self-modifying code, but I'm not sure that's possible anymore...
  As an aside, I've wondered how mobile developers protect against someone decompiling their stuff and using their API key. I guess the answer is "they can't."
21. Re:Read between the lines by AmiMoJo · 2014-01-04 16:52 · Score: 1
  
  I doubt the bank is worried about that kind of attack. They likely get thousands of phishing sites trying to trick the user into entering the security code themselves that are a much less risky form of fraud.
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Good job! by Anonymous Coward · 2014-01-04 05:18 · Score: -1

Good job! Good article about rev eng. Got my hacker juices flowing.
1. Re:Good job! by Anonymous Coward · 2014-01-04 08:08 · Score: 0
  
  Hopefully with an accompanying paper towel.
Do I care? by DavidClarkeHR · 2014-01-04 05:21 · Score: 1

I'm not particularly concerned, so long as I'm not on the hook for any lost funds. It would be nice to know that our banking institutions were competent, but I'm happy so long as dispute resolutions aren't arduous.

Speaking of which, I've disputed charges on my credit card twice, and my credit card provider has made it quite painless. If my bank was that forgiving, I'd probably use my chequing account more than my credit account.

--
- Nec Impar Pluribus, or so I'm told.
1. Re:Do I care? by Anonymous Coward · 2014-01-04 05:48 · Score: 0
  
  ...Speaking of which, I've disputed charges on my credit card twice, and my credit card provider has made it quite painless. If my bank was that forgiving, I'd probably use my chequing account more than my credit account.
  That's a lot better than Bank of Montreal Mastercard. I've been a customer for 30 years but when I disputed a (small) charge on my bill they would not reverse it. They delayed and hummed and hawed and wanted to send me a bunch of paperwork. They can f*ck themselves. I have other cards I can use.
2. Re:Do I care? by thebigmacd · 2014-01-04 06:04 · Score: 1
  
  You are generally on the hook for fraudulent credit card charges under $50, with any provider.
3. Re:Do I care? by DavidClarkeHR · 2014-01-04 07:11 · Score: 1
  
  $50 is the legal upper limit for consumer liability in the USA.
  
  Contrary to popular opinion, there is intelligent life outside of the USA. For example: many of the credit card companies operating in canada offer $0, 0% liability.
  
  --
  - Nec Impar Pluribus, or so I'm told.
4. Re:Do I care? by Anonymous Coward · 2014-01-04 09:42 · Score: 0
  
  It was more like $250 fraud charge from a major telco in Canada (Telus sucks) and I did not authorize the charge. I had to go to small-claims court to get it back. Needless to say, we don't use Mastercard CC anymore and we no longer deal with Bank of Montreal.
Tokens? by Dan+East · 2014-01-04 05:35 · Score: 4, Funny

Does this work on Chuck E Cheese tokens too? I need to feed my skee ball addiction.

--
Better known as 318230.
Usernames are unique keys. Try registering. by tepples · 2014-01-04 07:22 · Score: 3, Insightful

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.
1. Re:Usernames are unique keys. Try registering. by Anonymous Coward · 2014-01-04 09:42 · Score: 0
  
  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.
  Many banks implement that system, and it's stupid and annoying.
  If someone is able to MITM my browser's connection to the bank's website and spoof the bank's ssl certificate, do you think it's that difficult to log on as me and MITM the image?
2. Re:Usernames are unique keys. Try registering. by Anonymous Coward · 2014-01-04 10:03 · Score: 1
  
  Pretty sure that's not actually to prevent phishing: the MITM attack to do phishing that way is too obvious. My guess is that the actual reason is to prevent you from accidentally locking someone else's account because bank systems often require you to call to unlock an account after a very small number of incorrect password attempts.
  Also, it doesn't verify that a username exists: my bank will generate fake ones for non-existing usernames (tested by mashing on my keyboard to generate a username).
3. Re:Usernames are unique keys. Try registering. by beelsebob · 2014-01-04 13:58 · Score: 1
  
  The point being that it restricts the attack to MITM, simple phishing no longer works.
4. Re:Usernames are unique keys. Try registering. by damium · 2014-01-04 17:47 · Score: 1
  
  But if you are at the phishing site they can easily pass the information to your real bank and MITM the response back to you. I've written reverse proxy filters that do this kind of thing for some of the internal 3rd party services I manage at my work. This kind of thing stops the really easy to make phishing sites (such as form service based phishing or phishing from compromised web pages) but anyone who is paying even the slightest amount of attention will see that these aren't the real banking site to begin with.
5. Re: Usernames are unique keys. Try registering. by lynxie · 2014-01-05 01:48 · Score: 2
  
  You locked my iwaehfqwloduksuggekjh account????
6. Re:Usernames are unique keys. Try registering. by Muad'Dave · 2014-01-06 05:11 · Score: 1
  
  I'll bet if you clear cookies you will not get the intermediate image and must answer extra questions, after which the cookie gets set. Bank of America does this, too.
  
  --
  Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
The medium on which the secret is stored by tepples · 2014-01-04 07:23 · Score: 1

Perhaps the obfuscation is there to make it more difficult to extract the secret from the medium on which the secret is stored.
How can I get what you have? by tepples · 2014-01-04 07:28 · Score: 1

So how do you recommend that someone who currently lives in the United States go about qualifying to work in Canada?
1. Re:How can I get what you have? by Anonymous Coward · 2014-01-04 07:40 · Score: 0
  
  Temporary: http://www.cic.gc.ca/english/information/applications/work.asp
  Permanent: http://www.cic.gc.ca/english/immigrate/apply.asp
  It's not nearly as difficult as attempting the reverse. I don't think most Americans have the slightest idea just how stupid it has gotten, even if they went through the process themselves just a couple decades ago.
  But the point was that there is a pretty good bet that the AC with the Bank of Montreal card was Canadian (or at least, not American). BMO does apparently have some US operations nowadays, but tends to use "BMO" instead of "Bank of Montreal" there.
2. Re:How can I get what you have? by Anonymous Coward · 2014-01-04 09:59 · Score: 0
  
  The page where you're asked to indicate your language proficiency is slightly amusing, though I might be over-analyzing it by wondering whether it's a trick question...
  
  - Are you stronger in English, or French? That is your first official language.
  - If you also speak the other language, it is your second official language.
  - If you only speak either English or French, that is your first official language.
  For the second section answer "none". [ WTF?!? ]
  Select the answer that reflects your ability to read in your first Canadian official language.
  OK, so I'm probably being a pedantic INTP since there's almost certainly a second section a few form submissions later, but I can't help but wonder at this instant before submitting the form whether it's one of those questions like some sadistic college professors put on the final exam, like "Skip the remaining questions. Write "I read the instructions" on page 18 of the exam book, and enjoy watching your classmates sweat for the next 50 minutes."
3. Re:How can I get what you have? by Anonymous Coward · 2014-01-04 14:29 · Score: 0
  
  The page where you're asked to indicate your language proficiency is slightly amusing, though I might be over-analyzing it by wondering whether it's a trick question...
  
  - Are you stronger in English, or French? That is your first official language.
  - If you also speak the other language, it is your second official language.
  - If you only speak either English or French, that is your first official language.
  For the second section answer "none". [ WTF?!? ]
  Select the answer that reflects your ability to read in your first Canadian official language.
  OK, so I'm probably being a pedantic INTP since there's almost certainly a second section a few form submissions later, but I can't help but wonder at this instant before submitting the form whether it's one of those questions like some sadistic college professors put on the final exam, like "Skip the remaining questions. Write "I read the instructions" on page 18 of the exam book, and enjoy watching your classmates sweat for the next 50 minutes."
  As an INTP, you disgust me. That question is precise within the boundary of the political framework. Unlike the greatest states of america, most countries recognize that you can speak multiple languages.
OK, so first I need a medical exam by tepples · 2014-01-04 08:00 · Score: 1

This page states that there are no physicians anywhere in the State of Indiana who are qualified by Canada to perform the medical examination required of people entering Canada. This means I'd have to take a Greyhound motor coach to Chicago and back, somehow find a place to sleep, and figure out how to navigate Transit Chicago. (Or I'd have to go to driving school and buy a car.) What would be the best place for me to learn about these things? Would an employer in Ontario be willing to explain this, or should I seek help elsewhere?
Google Authenticator stores in cleartext..? by gnoshi · 2014-01-04 10:37 · Score: 1

The most interesting comment for me was this:

This is not a security vulnerability or even criticism by any stretch. The bank‘s app is (arguably) more secure than Google Authenticator (which keeps secrets around in plaintext), and this article should be seen as praise for the bank’s app, which does things the right way by (mostly) adhering to the TOTP standard, and protects its data as well as technically possible.
Yes, because any TOTP app must be able to read the secrets to generate the OTP, it must have any encryption keys internally, so it can never really be safe from cloning (unless it relies on a hardware encryption component which the phones don't have). Still, storing in plaintext makes grabbing the token data particularly easy.
This is not a security breach by MobyDisk · 2014-01-04 20:34 · Score: 3, Informative

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.