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:

  Expiration date:1608
  service code:100
  Discretionary data: 91516084076901530
  PAN: same as track1
  Expiration date:1608
  service code:100
  Discretionary data:9154177591894

Using another reader:

  • 1
    I can change my VISA PIN online. Would be quite the surprise if that changed the data on the card.
    – Cephalopod
    Jan 26, 2016 at 14:29
  • My visa pin only ever works when the chip is used, not when the stripe is used.
    – PlasmaHH
    Jan 26, 2016 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. Jan 26, 2016 at 16:58

6 Answers 6


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.

  • 1
    seems right. but may I know your interpretation for these numbers: 4076901530 and 4177591894? Jan 25, 2016 at 14:50
  • Do you mean why they are different?
    – AstroDan
    Jan 25, 2016 at 14:59
  • Why are they different and what are they? Jan 25, 2016 at 15:21
  • Take a look at stackoverflow.com/questions/12239855/….
    – AstroDan
    Jan 25, 2016 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. en.wikipedia.org/wiki/ISO/IEC_7813
    – AstroDan
    Jan 25, 2016 at 15:25

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.

  • 2
    I know that. my question was the problem with Padilla's paper. Jan 25, 2016 at 14:20
  • 2
    @isarandi On my card - it's not. It's sent in separate envelope.
    – Agent_L
    Jan 25, 2016 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. Jan 25, 2016 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, 2016 at 16:17
  • 4
    @MHSamadani Interesting. icba.org/files/Bancard/PDFs/… 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, 2016 at 17:59

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.


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

  • 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? Jan 25, 2016 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, 2016 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, 2016 at 17:21
  • @supercat indeed - you may have noticed that the two references I gave were both exploits.
    – abligh
    Jan 26, 2016 at 9:45

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.

  • 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. Jan 25, 2016 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, 2016 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. Jan 26, 2016 at 17:01

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.

  • Do you mean there is no record of that on the server? Feb 13, 2016 at 3:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .