Indiana Bank gets Hacked…Who’s really to blame?

Filed under Hacking

<%image(20080609-1stSourceBank.jpg|75|53|1st Source Bank Hacked)%>

Interesting story that hit the wire last week about another bank security breach. This time 1st Source Bank of South Bend Indiana became the next victim of stolen debit card data. Not a ton of details have emerged yet but we do know the following:

1. A external monitoring service (an MSSP perhaps?) or hired security consultants (doing a pen test?) detected an unusual amount of data leaving one of the banks servers.

2. The bank notified law-enforcement authorities and hired outside forensic firms (aka: security incident response consultants) to analyze the breach.

3. Track 2 data was compromised. Track 2 data contains the cardholder account number, PIN, plus other discretionary data. Note that the ISO standard does not mention that the PIN has to be encrypted. Only Track 1 data requires it. This may make a replay attack (encoding a fake debit card and using it in ATM transactions with this information) possible.

4. The bank is reissuing all debit cards in it’s portfolio and is offering to pay for “Deluxe ID TheftBlock” – at $4.95 a month for one year for any customer who requests the service.

These quotes from the bank are classic:

The bank also is monitoring automated teller machine transactions “minute by minute” to stop unauthorized activity. But even if the efforts fail, account holders won’t suffer, Seitz said.

“We’re certainly not holding any of our customers financially responsible for any transactions related to this breach,” he said.

and….

“Actually, our customers have been very understanding,” he said. “Obviously, this is something that puts a little stress on that relationship.”

Really…are you kidding me? Also note that they have yet to publicly announce an official statement on their web site about the security breach. Actually, nowhere on their web site mentions anything about the breach (however, they mention lots of interesting stuff about a recent merger with another bank beginning on June 9th…so they are updating the web site regularly). Clearly this is an attempt to make this security breach out to be “no big deal” to the general public.

So who’s really to blame? The bank is of course! Personally, I would rather have my bank be honest and up front with me about a security breach instead of delayed announcements (nothing was sent to customers until two weeks after the breach) and talk about how customers will be “understanding”. Clearly there are major security and customer service issues at this bank. Current 1st Source customers should bail out ASAP!

One Comment

  1. Matt says:

    Without some serious bruteforcing compromised track data would not of lead to the PIN being revealed. Clear text PIN data should never be stored on the card. I am not aware of any standard that allows this.

    The ISO 7813 standard does not require a PIN to be encoded onto the card but it does allow an "Encrypted PIN" to be encoded onto the card. The "Encrypted PIN" is a 4 digit code that is generated by DES or 3DES encrypting the PIN with the banks PIN Verification Key (PVK). Then that string of cipher text is run through an algorithm that pulls out the four digits that comprise the Encrypted PIN block.

    Given this process an attacker would first need to bruteforce the banks PVK encryption keys. Next they would need to bruteforce the PIN to figure out which PIN matches up with which Encrypted PIN. Because the Encrypted PIN is a subset of the cipher text generated you can not simply decrypt the Encrypted PIN to get the original PIN. Think of it like a hashing function.

    Cheers,
    Matt

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*