Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
For any nonsense or banter that doesn't fit anywhere else. LoL! omg! ROFL! 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
ATM security question...
Posted by: istari
Date: October 02, 2008 08:24PM

Where I live, banks have recently forced us users to adopt an extra 3 letters for the security codes we use in ATM's (we previously had a 4 digit code). Now, at first this seems a good idea, as you jump from 10.000 [=10^4] possible codes to 17.576.000 [=(10^4)*(26^3)] possible combinations. However, a closer inspection tells me this really isn't such a great idea, so I'm asking all of you for a second (and third, fourth, etc) opinion...

Now, bank employees say this is a measure to make it more difficult for people going to ATM's with a laptop and cracking the codes of stolen cards. However, there are several reasons why I think this is only a big hassle:

- Firstly, you don't have to input all the code at once: first you put your previous 4 digit code (at which point you are already allowed to make some operations not involving cash, such as checking your account balance), and only when you want to make an extraction you are asked to input the 3 letter code. So, in my view, an attacker could start by breaking the 4 digit code, and only after that worry about the 3 letters... So we're down from 17.576.000 to 27.576 [=(10^4) + (26^3)] maximum tries to get the full code!

- Secondly, when you're asked your 3 letter code you don't have to choose 3 from the 26 possible letters each time, but only 3 from 10 groups of 3 random letters each, and you don't have to specify which of the three letters in a group is the one you want. So on average you would get the correct 3 letters in 10^3 tries instead of 26^3, which means that now the total number of tries needed to crack the code is 1.100 [=(10^4)+(10^3)]... Only 10% higher than it was before this.

- Finally, and this may be a misconception of mine, ATM security isn't based on strong passwords, but on physical access to the card: after 3 incorrect tries the ATM is blocked with your card inside, so if someone is able to bypass that and make 1.000 tries with the same card, you're already doomed even if you take that up to 1.000.000. Am I wrong to assume this?

Anyways, I wanted to ask all of you your opinion, as this is driving nuts all of us security guys here. So what do you think? Do your banks have similar measures? What kind of codes do you use?

Oh, and I forgot to mention this before: this measure only applies to ATM's, because we have different codes to access the bank's web page, and to pay in stores...

Options: ReplyQuote
Re: ATM security question...
Posted by: tx
Date: October 03, 2008 02:47AM

afaik, most ATM attacks are 2 part:
1) A card reader to grab the data off of the magnetic stripe
2) A small camera or false keypad to record the PIN

In those cases, I can't really see the additional step providing any level of protection. I'm curious though as to how the 3 character pass works, do you have the same 3 letter password every time you access the ATM, and then you're given 9 fake choices as well?
For the record, here (US), with my bank, I'm given a choice of PIN numbers between 4 numeric characters (i think) and 8.

Regarding the "physical access to the card" bit: Personally, I don't think that "ATM Security" is based on the card or the PIN. As far as I can tell, it's based on security cameras and a bit of "run faster than the guy next to you". AFAIK, the main targets for ATM attacks aren't bank ATMs, but independently owned and operated (the COCOTs of our day :P ) ATM that have little foot traffic around them and marginal, if any, monitoring being done.

-tx @ lowtech-labs.org

Options: ReplyQuote
Re: ATM security question...
Posted by: Malkav
Date: October 03, 2008 03:16AM

i entirely second tx.

this is not gonna add any security to the actual system. skimming will still work, pinpads overlays will still be pinpad overlays, and due to the nature of the smartcard, not allowing offline attacks without the knowledge of the k (bank secret), bruteforce was already out of question. (of course, if you happen to have the k of a bank, you can fuck anyone. but why would i care of your puny little account, when i can generate at will any card for any account, including the bank's private trade account, and locked assets account)

the only worthwhile security measure to me is tamper evident strip readers and pinpad, to protect the innocents from skimming. of course, if the tech himself decides to skim you, whatever be the PoS terminal, you're fucked.

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: ATM security question...
Posted by: thrill
Date: October 03, 2008 12:00PM

not to mention the fact that there are attacks that just look for the card number, any other information is inconsequential to the attacker since there are an extremely large portion of merchants that as long as you can hand them a card and they can swipe it, they don't care what name is on the card or what name comes through the terminal to the receipt. No 3 digit security code, no signature verification (which in a way it doesn't work anyway because if you manufacture your own card you can sign whatever you want as well).

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: ATM security question...
Posted by: istari
Date: October 04, 2008 11:15AM

Well, thanks everybody for throwing some light on this... I suspected this measure was no good, but I needed to check nonetheless ;-)

@tx - The 3 letter code works like this: suppose your personal code is ABC (once you set it, this code will be yours until you change it yourself), and you want to make an extraction. After you input the amount of money you want, the screen shows something like:

0 - HGU | ENB - 5

1 - NAD | VXS - 6

2 - OPQ | CIN - 7

3 - TYR | QMV - 8

4 - MHW | ZDT - 9

So you have to input 1, 5, 7 (in that order) and only then does the machine give you the money you asked before going back to the main menu. Oh, and if you want to make another extraction, you'll have to go over all of this again, even if you never took out the card from the machine...

Options: ReplyQuote
Re: ATM security question...
Posted by: DoctorDan
Date: October 04, 2008 01:23PM

Are the groups of 3 letters randomized?

Options: ReplyQuote
Re: ATM security question...
Posted by: istari
Date: October 07, 2008 08:20PM

Yes, they are... If you're asking because that would make my 10^3 estimation wrong, I meant that in average: in the worst case you can fail forever, and then truly be the most unlucky person ever!

I'm currently in the process of running a few simulations to determine how hard it really is to crack this system. If anyone is interested I can post the results here when I'm done...

Options: ReplyQuote
Re: ATM security question...
Posted by: DoctorDan
Date: October 07, 2008 10:15PM

Post it for sure, research and knowledge is crucial!

Options: ReplyQuote
Re: ATM security question...
Date: October 08, 2008 11:21AM

If this is an issue in US ATMs we don't have to worry about it, pretty soon the ATMs will all be saying 'insufficient funds' for everyone =o(

Options: ReplyQuote
Re: ATM security question...
Posted by: thrill
Date: October 08, 2008 11:53AM

Heh.. this is funny.. using that method for allowing people from their bank account, and taking the recent news about gmail goggles.. maybe they made the change to prevent drunk people at casinos from getting any more of their money out.. :)

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: ATM security question...
Posted by: istari
Date: October 08, 2008 09:56PM

@CrYpTiC_MauleR - This concerns ATM's not in the US but in Argentina. Your comment is still a good point tho :-(

Anyway, here goes a summary of the simulations I made. In a nutshell, they confirm my suspicions about the uselessness of this measure. Just as background, I'm assuming the attacker has no limit in the number of tries he/she can make to crack a code, and that trying may take a very small amount of time (i.e. the attack is automated), so several thousand tries may be possible in a reasonably short period. This assumption is supported by the fact that, apparently, brute force attacks have been seen in the wild on the 4-digit code I mentioned earlier (this information was provided by bank employees). I am also assuming all the secret codes to be cracked are chosen at random: any information concerning the owner of the card (initials, birth date, etc) might result in a faster (heuristic) attack.

This is obviously not a white paper, just my findings regarding this matter. I don't think I will go any further in this work, as no one at the bank seems to care about the complete failure of their newly implemented security measure. I also don't have any more information as to how the attacks to the ATM's were performed, so this may not be a correct simulation (although it is to the extent that I can imagine how an attack would unfold). Anyway, if you don't feel like reading the whole thing, just skip to the conclusions at the end and throw your thoughts on the subject.



I split the simulations in 3 stages, corresponding to the actual stages an attacker would have to go through in order to fully crack someone's password (that is, the 4 numbers and the 3 letters).

1) Cracking the four digit secret code (which provides access to basic functionality in the ATM).

2) Obtaining access to the full functionality of the ATM (that is, finding a valid set of 3 groups of 3 letters each).

3) Completely cracking the 3 letters of the security code.




STAGE 1 - THEORY: The first stage consists in cracking a 4 digit code that is presented to the user right after he/she inserts the card in the ATM. If the attacker chooses the four numbers to try each time at random, the probability of getting the right four numbers (in the correct order) is 1/10000. That is, the attacker should crack the code on average after 10000 tries. However, if the attacker goes trough the numbers sequentially, the 10.000 tries become the worst-case scenario (i.e. trying every single possible code), and on average the number of tries before getting the correct code would be 5000

STAGE 1 - SIMULATION: There's no point in simulating the sequential attack if the secret code is chosen at random, so in this stage I only simulated the randomized attack. I made 5 runs, in each of which a program tried to crack 10000 random codes, and counted the number of tries before getting the right code each time. This amounts to 50000 cracked codes, and the average number of tries needed to crack each code was 10004, in accordance with the predictions above. As a side note, one could get extremely lucky (4 times out of 50000 the code was cracked in the first try) or extremely unlucky (one code took 112168 tries). However, over half the codes were cracked in under 7000 tries. Here goes a graph of the results (each bar corresponds to a range of 1000 tries):



STAGE 2 - THEORY: The second stage consists in getting access to the full functionality of the ATM. This does not necessarily mean to know the three letters that form the rest of the security code, as one only needs to find a valid set of three groups of three letters, each one containing one of the letters in the secret code. There are 10 groups to choose from, so the probability to get the right one is 1/1000.

STAGE 2 - SIMULATION: On one hand, I made a program that randomly generates a secret 3 letter code, and based upon it generates random sets of 10 groups of 3 letters each. These are made such that in every one of them there's a single subset of 3 groups each one containing a letter from the secret code. On the other hand, I made another program that randomly chooses 3 of the groups in each set generated, and checks if they contain the secret code. Again, I ran these programs 50000 times, and found that on average the number of tries needed to get a valid set of three groups of letters was 1006. Again there were 50 cases in which the minimum of 1 try was needed, one case in which the maximum of 10841 tries was needed, and over half of the codes were cracked in under 700 tries. The graph of this data is obviously very similar to the one of the previous stage (now each bar corresponds to a range of 100 tries):



STAGE 3 - THEORY: This stage consists in repeating the process in stage 2 until the three letter code becomes completely known. This is possible because each time you get a valid set of 3 groups of 3 letters each, each group contains 1 letter in the code and 2 random letters. Comparing the groups obtained in several different attacks to the same 3 letter code (i.e. the same card), one can discard the random letters until only the three letters in the actual secret code remain. The probability of one of the random letters repeating itself in n groups goes like (1/24)^n, and there are only 6 letters to discard, so one can assume only a few sets of 3 valid groups will be enough to fully compromise the secret code.

STAGE 3 - SIMULATION: The simulation consists in repeating stage two and comparing all the results as many times as is needed to end up with the 3 letters in the actual secret code. Note that the process is done randomly, which is not the most efficient way to do it (but it is the one an automated attack would choose). This was probably the most interesting simulation, as the theoretical predictions of the two stages before this one are rather simple, but on the other hand in this case we only have an asymptotic behaviour. The results for 50000 runs were that on average it takes 2.45256 correct solutions of stage 2 to get the whole 3 letters of the security code. This means more than half the codes were completely cracked with only two tries, and over 95% were cracked with less than three tries. Only in 2 of the 50000 cases were 7 tries needed to get the whole code. The graph of this data is:





As you can see, the new security measures (stages 2 and 3), seem to fail at making a brute force attack to the security code impractical: if an attacker is currently able to try an average of 10000 times to crack the four digit code (first stage), then he/she will probably be able to go through the three stages above and crack the whole code, as this would only take an average of 12000 to 13000 tries. What's more, the attacker needn't go through all the stages for every single card:

- After stage 1, he/she can check the account balance, and maybe desist trying to crack the code if the loot is not big enough, or even wait until money is deposited in the account to proceed with the next stages.

- After stage 2, the attacker doesn't know the 3 letter code for the card, but is already able to make an extraction, and take as much money from the account as the ATM allows him/her to.

- After stage 3, the attacker has the full security code for the account, and he/she may clear the account, hijack it, change the security codes for other services (such as internet payment and commercial use), etc.

All in all, it seems this measure was a good idea to begin with (4 digits + 3 letters in a single password account for over 175 million possible combinations), but was so poorly implemented the whole thing is now pointless. In my opinion, it would be a lot safer to go back to the 4 digit code and implement a 1 second hardware delay for every time someone tries to input a security code. This way, cracking the 4 digit code would take over 1 hour on average, so it'd be quite impractical for almost all the ATM's out there...

Options: ReplyQuote
Re: ATM security question...
Posted by: Malkav
Date: October 09, 2008 04:06AM

i for one, bows to our new simulating overlord.

istari : i don't know what's your age or academic background. but you are hired. now.

disregard the confirmation of a useless cost addition and lose of usability of the product, (which we already forecasted by guesswork, and is now proven) you've shown an amazing skill in demonstrating.

my turn now.

cost of development ? i see well enough a small team of devs on this one. let's say 5 devs, a senior, two regular, and two rookies (he, you've got to start). they cost each $1200, $800 and $400 a day for a total of $3600/day (ignoring dev infrastructure cost, of course) such a project, with the usual problems coming, Q&A and preflight would take between 6 month and a year, so here we go with nine. so 274.5 mean days, at 3.6K/day puts us at $988200. *just to pay the devs*
double this cost for administrative overhead, and add a half for a small production team. and here your are $2.5M for strictly no security added *and* end user frustration.

this of course, doesn't take into account multiple added cost, such as slowed alternative dev work, production overhead, Q&A time spent, hot air production (meetings anyone ?) so this figure is obviously a low one.

i'd be so happy to hear some comments from the original designer of this utter crap, and money/time sink :)

----------------------------------------------------------------------------------------------------------------

Those that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
--Benjamin Franklin

Options: ReplyQuote
Re: ATM security question...
Posted by: thrill
Date: October 09, 2008 11:46AM

Don't forget the 250k/year VP of Engineering, because we all know devs can't work without one of those pushing them to perfection.

--thrill

---

It is not the degrees you hold, but the mind you possess. - thrill

Options: ReplyQuote
Re: ATM security question...
Posted by: istari
Date: October 09, 2008 08:38PM

@Malkav - I'm just starting my twenties, and I'm a Physics student in my third year of university... So I'm somewhat used to running experiments and simulations, only not in the field of information security or IT (more in the line of physical systems and such). My current location is usually a huge deterrent for job offers tho ;-)

Anyway, I can't even imagine how much money was wasted with this new measure. Just to give everyone an idea: on top of the development costs Malkav mentions, bank employees told me (when I went to question them about all this) that they have set up a 24/7 Q & A phone line to handle the ~100 queries per hour that they're getting from confused users! How much can that cost? Add the money to the amount of user-time they're wasting, and they should be put to jail for excessive stupidity...

If only they had made a quick analysis of the added security they were introducing, they would have probably decided to do a better implementation, or not do it at all. If they listened to all the people who are now saying this is useless, they could at least go back to how it was before and cut down some maintenance costs... But they're so stubborn they just won't! So sad...

EDIT - One thing I forgot to say before: C++ source code for the simulations is freely available to anyone interested. It's really not a big deal, and it's quite messy, but if anyone wants it they can have it...



Edited 1 time(s). Last edit at 10/09/2008 08:40PM by istari.

Options: ReplyQuote
Re: ATM security question...
Posted by: tx
Date: October 09, 2008 08:48PM

istari Wrote:
-------------------------------------------------------
> bank employees told me (when I
> went to question them about all this) that they
> have set up a 24/7 Q & A phone line to handle the
> ~100 queries per hour that they're getting from
> confused users! How much can that cost?

Depends on if it's staffed by representatives with incomprehensibly thick Indian accents who are somehow named "Mary" :P

-tx @ lowtech-labs.org

Options: ReplyQuote
Re: ATM security question...
Posted by: istari
Date: October 09, 2008 08:54PM

Haha, we don't have that "Mary" problem here ;-) It's usually people with Caribbean accents tho, and it works best when you ask them for directions and they can't tell the difference between two cities 3000 km apart...



Edited 2 time(s). Last edit at 10/09/2008 08:55PM by istari.

Options: ReplyQuote


Sorry, only registered users may post in this forum.