Fail Secure


Fail Secure – Is typically used to describe door locks. When the power is on: the door remains unlocked, if power goes out: the lock ‘Fails Secure’ and remains locked when the power is off.


Payment System should also Fail Secure

One of the things that some developers do is log data in exception cases; Hell, I’ve also seen the log everything-you-might-never-know-when-you-need-it mentality. (with some scary looking DB Schemas) (I’ve even seen payment systems in the past that logged raw request and raw responses by default for all transactions, and also logged un-parseable messages in an exception file, all of which included binary representations of the underlying message format – yes it was binary, and sometimes even EBCDIC – but opposed to some popular beliefs – this isn’t encryption, and contains data elements that are prohibited to retain, applications like these will most likely be listed on Visa’s vulnerable payment application list. (A list of vulnerable payment applications is updated quarterly and is available on Visa Online at

There are many valid reasons for doing this: why did the exception occur, is it repeatable, is it a software bug, an invalid message that can’t be parsed properly? etcetera. This is all good and fine in test and development environments, but this is particularly a concern when dealing with payment systems that are involved in processing, storing and retaining cardholder data and with this same type of exception logic in production system in the real world.

There may even be business reasons and good intentions to do so: under an exception the cardholder may have been charged (especially a debit transaction) and if the database or storage system was down, or a response message may not be parseable, the payment system may not have any record of this transaction. The cardholder may try again or with another card – and then end up with double-charging the cardholder. But if the raw data is retained – then one can troubleshoot, and re-create the appropriate transaction, or any returns or reversal and handle the exception cases.

Payment System should also Fail Secure – On an exception scenario – make sure that you are not logging or retaining prohibited data. PCI/PABP does have provisions to allow for troubleshooting these types of problems, but the procedures and controls around enabling detailed troubleshooting must very strict and require minimal data, and have similar controls around it to include initiation, authorization, access control, montiroing, secure storage and secure disposal of when it is no longer required. The process should also not be enabled by default. Config files, database config tables, etc that are used to enabled detailed troubleshooting – should be monitored (File Integrity, DB content checks) to make sure that this functionality is off when not needed.

Payment systems contain cardholder information and must be handled differently then other applications. Make sure that you and and payment systems developers understand this as well.

Don’t store the truncated cardnumber with a non-salted hash of the cardnumber

If an attacker acquires the database or database records AND you store a truncated cardnumber and an non-salted hashed accountnumber (which is a pci compliant approach, BTW) it take ~3 minutes per card to acquire the plaintext value and generated ~ 9MB file

Hashed account numbers are typically stored to assist in the lookup of card’s in the database, the quering application would calculate a hash on the accountnumber and query that hash to find the related transactions without using the account number.

Let’s use the following test card as an example:


This would be stored or displayed as:


I wrote a small program that iterates through the missing digits, calculating the checksum (Luhn), and then calculating the MD5, SHA1 and SHA-256 hashes and stores it in a file, This program took approx 3 minutes to run per truncated card:

You would typically see a data record that would look like this:

Masked Account Number

Hashed Account Number(*)

Encrytped Card Number(**)

(*) #SHA1 hash of 4111111111111111
(**) 3des of 4111111111111111 with “” as the key

With my program:

dbergert@debian:~$ bin/bruteforce.bsh 411111______1111

.. takes ~ 3 minutes to run

dbergert@debian:~$ grep “68BFB396F35AF3876FC509665B3DC23A0930AAB1” bruteforce.txt

4111111111111111,5910F4EA0062A0E29AFD3DCCC741E3CE, 68BFB396F35AF3876FC509665B3DC23A0930AAB1,9BBEF1947 6623CA56C17DA75FD57734DBF82530686043A6E491C6D71BEF E8F6E

I guess the key lesson to use salted hashes, and just because you can show the first six and last four, if you don’t have a business need, only show the first for card type and last four. (which would only add required time to this process…)

*** Please don’t email me for the code, you are not getting it.

Update: Just for fun I calcuatlated how long it would take to bruteforce if you only stored the first digit and last four. i.e. — 4____________1111

You are looking at it taking a single processor 347 days, with a file that is is 1.47 terabytes in size, but remember that this only needs to be calculated once and that the timing can further be reduced by using well known BIN’s,

From reducing what numbers are displayed from 10 to 5, changes the timing from 3 minutes to 347 days.

I wonder when we will see longer account numbers.

jPOS’s ProtectedLogListener


A recent blog post at further shows the focus on payment applications with PBAP and these requirements:

PABP requirement (#1) Do not retain full magnetic stripe, card validation code or value(CAV2,CID,CVC2,CVV2), or PIN block data. PCI requirement (#3.2) Do not store sensitive authentication data subsequent to authorization (even if encrypted) this includes: Full magnetic stripe(Track Data), Card Validation code, and PIN or encrypted PIN block PCI requirement (#3.3) Mask PAN when displayed. (first 6 and last 4 digits are the maximum that can be displayed)

jPOS has its own logging subsystem that is typically used with q2. A typical logging configuration has a 00_logger.xml in the deploy directory of a jPOS application looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<logger name="Q2" class="org.jpos.q2.qbean.LoggerAdaptor">
<log-listener class="org.jpos.util.SimpleLogListener" />
<log-listener class="org.jpos.util.RotateLogListener">
<property name="file" value="log/q2.log" />
<property name="window" value="86400" />
<property name="copies" value="30" />
<property name="maxsize" value="1000000" />

In order to comply with PABP and PCI requirements listed above,

you can use a ProtectedLogListener configuration that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<logger name="Q2" class="org.jpos.q2.qbean.LoggerAdaptor">
<log-listener class="org.jpos.util.ProtectedLogListener">
<property name="protect" value="2 35" />
<property name="wipe" value="52 45" />
 <log-listener class="org.jpos.util.RotateLogListener">
 <property name="file" value="log/q2.log" />
<property name="window" value="86400" />
 <property name="copies" value="30" />
<property name="maxsize" value="1000000" />

Note: the protect and wipe properties:


“40000101010001” is converted to “400001____0001”
“40000101010001=020128375” is converted to “400001____0001=0201_____”
“123” is converted to “___”

Wipe: Prevents the field from being logged.

The fields in ISO-8583 that you will likely want to protect and wipe are:

Field 2 – Primary Account Number (PAN)
Field 35 – Track data (account number and magnetic stripe)
Field 52 – PIN Data / Encrypted PIN Block
Field 45 – Track 1 Data

You will also likely want to monitor with your file integrity monitoring software the 00_logger.xml file to detect any authorized changes, as well as apply restrictive permissions on who has access to the 00_logger.xml file.

jPOS-EE ui (eeweb3) changes for PABP requirement 3.1

Section 3.1 of the Visa Payment Application Best Practices (PABP) states:

Test the application to verify that unique user names and complex passwords are required for all administrative access and for all access to cardholder data, in accordance with PCI DSS requirement 8.1, 8.2, and 8.5all.

I am in the process of modifying the jPOS-ee ui (eeweb3) to support these requirements, as well as to have them be set as configurable values to implement your organization security polices. We use some of the jPOS-ee eeweb3 module in some of our payment solutions, notably our OLS.Switch

The development and testing in ongoing, but I wanted to give a brief synopsis of the changes that mostly leverage the used of User properties and SysConfig properties:

  • Flag to set a user account Status: Active || Inactive

  • Ability to force a user to require a password change on their next login
  • Password minimum length, Password change interval
  • Password Complexity options (based on required use of # of character classes (Upper, Lower, Numeric, Special, or required # of each type))
  • Password History (configurable number of passwords to check)
  • Account Lockout (and configurable duration)

After I’m done coding and testing I’ll provide the code to to merge into jpos-ee svn codebase.