20

I was reading Breaking VISA PIN by L. Padilla. He stated that changing the PIN will change the stored data on the card. But, I tried on several cards and changing the the PIN does not affect the data stored on tracks 1 and 2.

How can I interpret that?

Is there any way to extract PIN from these data?

Here is some sample data:

Track1:
  PAN:6104XXXXXXXXXXXX
  Expiration date:1608
  service code:100
  Discretionary data: 91516084076901530
Track2:
  PAN: same as track1
  Expiration date:1608
  service code:100
  Discretionary data:9154177591894

Using another reader:

;6104XXXXXXXXXXXX=16081009154177591894?
MH Samadani
  • 319
  • 1
  • 2
  • 8
  • 1
    I can change my VISA PIN online. Would be quite the surprise if that changed the data on the card. – Cephalopod Jan 26 '16 at 14:29
  • My visa pin only ever works when the chip is used, not when the stripe is used. – PlasmaHH Jan 26 '16 at 16:39
  • @Cephalopod my wells fargo card' pin is also changable online. the question is already solved as that was an old problem which is solved after 2009. – MH Samadani Jan 26 '16 at 16:58

6 Answers6

24

In the past they may have encoded the PIN on the card, however hopefully (as your test indicates) they have stopped. It looks like the article that you cite is from 2009, which is rather out of date.

As to why they should not encode the PIN onto the card take a look at the NIST Special Publication 800-63-2, the Electronic Authentication Guideline. In the case of Multi-Factor authentication it should consist of a combination of "Something you know, something you have and something you are". For a card and PIN system you have something (the card) and know something (the PIN). If you encode the PIN onto the card then you only have something, which is single factor authentication and is not as secure.

If you are interested in the security of PINs in credit cards you can take a look at: https://www.pcisecuritystandards.org/documents/PCI_PIN_Security_Requirements.pdf. This is the PCI requirements for securing PINS.

As for the differences in the Discretionary Data these may come from several sources. From ISO/IEC 7813 the maximum record length of track 1 and 2 are different. The DD is used to fill the balance of characters.

For Discretionary Data the implementation is left up to the issuing company. As to what it might contain you may be able to find out by looking at the documentation from the issuing company (I rather doubt you will find anything but stranger things have happened). It may just be random padding to reach the proper length or it could contain additional data. See https://stackoverflow.com/questions/12239855/discretionary-data-from-magnetic-strip-credit-card-how-to-parse.

Community
  • 1
AstroDan
  • 2,226
  • 13
  • 24
  • 1
    seems right. but may I know your interpretation for these numbers: 4076901530 and 4177591894? – MH Samadani Jan 25 '16 at 14:50
  • Do you mean why they are different? – AstroDan Jan 25 '16 at 14:59
  • Why are they different and what are they? – MH Samadani Jan 25 '16 at 15:21
  • Take a look at http://stackoverflow.com/questions/12239855/discretionary-data-from-magnetic-strip-credit-card-how-to-parse. – AstroDan Jan 25 '16 at 15:22
  • 1
    Also from ISO/IEC 7813 the maximum record length of track 1 and 2 are different. The DD is used as the balance of characters. This means that the contained data is picked by the company, may be different between tracks and may even be random padding. https://en.wikipedia.org/wiki/ISO/IEC_7813 – AstroDan Jan 25 '16 at 15:25
  • in both 91516084076901530 and 16081009154177591894 I know that 915 is CVV2, 1608 is the exp date. Do you mean that other parts my be random? If not, what can we obtain from them? – MH Samadani Jan 25 '16 at 15:33
  • The rest may be random or it may be data. Because it is Discretionary Data the implementation is left up to the issuing company. Via ISO 7813 it is supposed to take up the balance of the available characters. As to what they might contain you may have luck looking at the documentation from the issuing company (I rather doubt you will find anything but stranger things have happened) – AstroDan Jan 25 '16 at 15:40
  • I would be happy if you would edit your response to reflect comment's information so I can mark it as accepted response. Thank you at all. – MH Samadani Jan 25 '16 at 15:45
19

The whole point of the pin is that it is not on the card, but rather in the bank's computers so that physical access to the card cannot give you that information. If it were on the card, it would just be a longer account number.

iAdjunct
  • 1,710
  • 10
  • 15
  • 2
    I know that. my question was the problem with Padilla's paper. – MH Samadani Jan 25 '16 at 14:20
  • 1
    "If it were on the card, it would just be a longer account number." Following this logic, the CVV should not be on the card either. – isarandi Jan 25 '16 at 14:49
  • 2
    @isarandi On my card - it's not. It's sent in separate envelope. – Agent_L Jan 25 '16 at 14:58
  • 4
    @isarandi CVV is used differently. It is used to prove the possession of the card when the card is not present, e.g. online payment. – MH Samadani Jan 25 '16 at 15:23
  • 7
    @isarandi The CVV is not in the magnetic data. This means someone who steals the card by taking the magnetic data won't have the CVV (unless they use a skimmer with a camera). – ceejayoz Jan 25 '16 at 16:17
  • @ceejayoz I tried more that 5 cards from different issuers. all of them had cvv2 stored in the tracks. proof is above, the cvv2 was 915 which is visible in tracks' data – MH Samadani Jan 25 '16 at 17:56
  • 4
    @MHSamadani Interesting. https://www.icba.org/files/Bancard/PDFs/MitigatingFraudRiskThroughCardDataVerification.pdf says "The CVV2 is different than the CVV contained on the magnetic stripe and is validated using a different calculation." Maybe that's just a US standard? – ceejayoz Jan 25 '16 at 17:59
7

No PIN is stored on the magstripe. There are essentially 2 types of PIN strategies commonly used in card payments: Offline and Online PIN.

Offline PIN requires the PIN value be stored securely within the chip in a tamper-proof module. During verification, the cardholder-entered PIN value is sent to the module for verification.

Online PIN scenarios send the PIN in the authorization request to the financial institution's host for verification against the secured PIN value in their database.

If you are able to accomplish changing a PIN on a chip card, using scripts, then you are likely changing the offline PIN in the chip. There is no visibility to PINs in the magstripe.

ryd3r
  • 387
  • 3
  • 7
6

To add to the other two answers, the data on the magnetic stripe is stored using IEC_7813 encoding. According to Wikipedia the Discretionary Data may include the PIN. It normally does not.

My recollection of the way it used to work was roughly as follows, which both has a degree of security and permits off-line PIN changes.

  • The bank stores in respect of each card the 'Bank PIN', which is the initial card PIN as sent to the user.
  • The PIN on the magnetic stripe is set to 0000 (or a known random number)
  • When a PIN is entered into an ATM, the entered PIN and the PIN on the magnetic stripe are added together, and the answer taken modulo 10,000, and the result transmitted to the bank, and compared with the 'Bank PIN'
  • When you change the PIN on the card, all that happens is stored offset changes.

I believe the code on the magnetic stripe may be called the PVV (or 'PIN offset'). See e.g. here and here for an older reference, from the second of which (end of section 3.1):

Finally, to permit the cardholders to change their PINs, an offset is added which is stored in the mainframe database along with the account number. When an ATM verifies an entered PIN, it simply subtracts the offset from the card before checking the value against the decimalised result of the encryption.

See here (see note below) for a modern reference:

PINCP: PIN Control Parameters (PINPARM). 6 digits:

If FC = 01 the two first digits represent the algorithm used to calculate PIN, where 00-09 mean private algorithm, 10-19 mean DEA and values 20 to 99 are reserved for future use by ISO/TC 68. Next 4 digits are PIN offset, a complementary value of PIN so customers can change their PIN, or PVV.

If FC = 02 the first digit represents the algorithm used to calculate PIN, where 0 means private algorithm, 1 means DEA and values 2 to 9 are reserved for future use by ISO/TC 68. The second digit represents a key for the algorithm. Next 4 digits are PIN offset, a complementary value of PIN so customers can change their PIN, or PVV.

If this field is not used a FS will be in place.

(the above was done from memory, then searched with Google, and only then did I realise the article actually appears to be the same as the one you referenced).

abligh
  • 2,026
  • 11
  • 12
  • so what is the interpretation for these numbers: 4076901530 and 4177591894? do you mean PVV is still in these data? is so why it is not changing? – MH Samadani Jan 25 '16 at 14:48
  • I suspect the answer is that the Discretionary Data does not *always* contain the PIN / PINCP. As the author says "One of the most common PIN algorithms is the VISA PIN Verification Value (PVV)" - this implies it is not the only algorithm. – abligh Jan 25 '16 at 15:55
  • Storing a PIN-difference value on a card doesn't seem very secure; if someone had physical access to a card before and after the PIN was changed, and found out what the old PIN was, they'd know the new one. Is there any need to allow customers to change PINs without needing to communicate with the database? – supercat Jan 25 '16 at 17:21
  • @supercat indeed - you may have noticed that the two references I gave were both exploits. – abligh Jan 26 '16 at 09:45
2

The PIN is stored only in the chip (probably in hashed form), not on the magstripe. Magstripe contains only the visible embossed information, so magstripe readers are equivalent to imprint readers, not to chip-and-PIN readers.

Note that the cited paper was written in 2002; it's possible that older standards were different.

Toby Speight
  • 1,214
  • 9
  • 17
  • written in 2002 and updated in 2009. but you are right, this attack is not possible know because the encrypted pin is not stored in the magstripe anymore. – MH Samadani Jan 25 '16 at 17:53
  • 1
    With only 10,000 possible values, hashing of any kind that can be accomplished in an amount of time that is acceptable at the checkout is rather pointless. (Consider a 1 second work factor. Checking all values then takes about 2 hours 45 minutes, at most, and can be trivially parallellized.) Better to ensure that the data cannot be illegitimately read or written. – user Jan 26 '16 at 12:42
  • @Michael that is right. the code provided by padilla works that way. by the way, afer 2009 there is no point doing that as no valueable data is store on the card. – MH Samadani Jan 26 '16 at 17:01
2

You can change your service code on the magnetic stripe that is possible, so you could turn a prepaid electronic use only into cash out on the atm.

ADMIN
  • 21
  • 1