[SecurityRatty] tag: pins

Three Plead Guilty in $2 Million Citibank ATM Caper

Wed, 05 Nov 2008 22:00:00 +0000

Three Ukrainian immigrants admit plundering Citibank customers using account numbers and PINs stolen from 7-Eleven cash machines. But Cardtronics, the company that owns the ATMs, hasn't been so forthcoming.

Access vendor GridSure uses patterns to remember PINs

Tue, 28 Oct 2008 21:00:00 +0000

A British startup has developed an authentication system that requires users to remember a pattern on a grid of numbers rather than a PIN (personal identification number).

Credit Card Protections Abroad

Fri, 10 Oct 2008 06:59:08 +0000

When you pay by credit card in a restaurant, have you ever wondered what they do with your card when they take it from you to collect payment? Although you may trust the restaurant, there’s still the possibility the waiters can write your credit card and verification number down and sell the info later.

Apparently in the UK and other European areas, this is not the case. Ira Winkler at the RSA blog recently wrote about an experience traveling and noticing other credit card customs and security -

If you are at a restaurant and pay with a credit card, they bring over a system and swipe your card in front of you. Additionally, all the credit card readers I came in contact with assumed that credit cards were smart cards with readable chips. This adds another level of security, and PINs were required as well. When I was in The Netherlands a few months ago, I couldn’t even use my American credit card on the ticket machines for their train system.

With all of the credit card fraud going on, I wonder when the US will finally get its act together and follow the European credit card security measures.

Read the full article here.

Trojan can grab extra personal banking data

Thu, 25 Sep 2008 20:00:00 +0000

A Trojan horse program now available to a growing number of fraudsters can add data entry fields to legitimate online banking sites and entice consumers to give up sensitive information such as bank card numbers and PINs (personal identification numbers).

Too many passwords or not enough brain power?

Sun, 07 Sep 2008 20:00:00 +0000

Our brains are littered with passwords and alphanumeric combinations that span all levels of necessary corporate and personal security - from bank accounts and PINs, to work-related e-mail and network log-ons, to e-commerce and social networking sites.

Clothes don't make this man: Sweatshirt helps nail Citibank card scammer

Wed, 02 Jul 2008 20:00:00 +0000

A bank-card scammer using stolen Citibank account numbers and PINs netted hundreds of thousands of dollars, but was caught because he always wore the same distinctive sweatshirt when making the illegal withdrawals.

.. and now - PIN stealing..

Thu, 19 Jun 2008 06:38:00 +0000

Once the bad guys figured out how easy it was to sniff unencrypted ATM and card authorization traffic to steal track data, and after making a killing with stolen card numbers, they began setting their sights on bank PINs. PIN numbers - thanks to ANSI's TG3 - are encrypted with a half decent algorithm (and they are looking to strengthen that even more now). Which means that sniffing the traffic will only give you an encrypted number - something which would require a decryption key. A number of security controls like requiring dual control and split knowledge for key components, strict physical security requirements and Tamper Resistant Security Modules help in securing the keys. Assuming one cannot gain access to the encryption keys, this leaves only two scenarios for an attacker to gain access to the unencrypted PINs:
1. Before the PIN is encrypted by the Tamper Resistant Security Module (an ATM in the case of bank customers). Most criminals have been using fake PIN PADs and a number of techniques like jamming cards etc steal PINs blissfully unaware that they are on camera most of the time. Nice video ? here.

2. After the PIN reaches the issuer and is decrypted. This is the scarier situation -as the attacker would have access to a database of unencrypted PIN numbers / PIN offsets coming in from all around the globe. PCI supposedly requires that issuers be compliant and not store unencrypted PANs or PINs - but no validation is required (unless they are a VisaNet processor).

Well - Kevin Poulsen at Wired wrote today about how an alleged ATM crime spree has been blamed on a Citibank hack. Though Citibank has denied the hack as the cause of the fraudulent withdrawals - all signs seem to point towards it so far.
(This definitely is not new - While testing an issuer's security I'd stumbled upon ATM log entry files - complete with PAN, PIN, full name, address, zip code and atm location - back in the day when RFP just released whisker. )

This is probably just the beginning of a new wave. Issuers really need to pull up their socks and begin to treat cardmember data with the same respect that PCI Co is requiring merchants and processors to do. - and while I'm wishing horses - can ANSI or someone start working on some standards for requiring all track data to be encrypted in transit?

1st Source Bank reissues all debit cards in response to breach

Thu, 05 Jun 2008 05:09:56 +0000

Technorati Tag: Security Breach

Date Reported:
5/30/08

Organization:
1st Source Bank

Contractor/Consultant/Branch:
None

Victims:
Customers

Number Affected:
Unknown

Types of Data:
Debit card information including Track 2 data contained on magnetic stripes and some PIN numbers

Breach Description:
"South Bend, Ind.-based 1st Source Bank is reissuing its entire portfolio of debit cards after a hacker or hackers broke into a bank server containing debit card data. No fraud has been discovered as a result of the intrusion"

Reference URL:
Digital Transactions News
WSBT TV News
South Bend Tribune
The Journal Gazette

Report Credit:
WSBT TV News

Response:
From the online sources cited above:

South Bend, Ind.-based 1st Source Bank is reissuing its entire portfolio of debit cards after a hacker or hackers broke into a bank server containing debit card data.
[Evan] I wonder how many debit cards are in its "entire portfolio". I'm guessing that the number is in the tens of thousands.

a hacker broke into the system from the outside and compromised the system.

No fraud has been discovered as a result of the intrusion

The $4.5-billion-asset bank with 79 branches in northern Indiana and southern Michigan began alerting customers last month after an outside monitoring service it uses noticed on May 12 an unusual flow of data from a bank server containing debit card data, says James Seitz, senior vice president of consumer and electronic banking. "We immediately saw that and shut it down," says Seitz.
[Evan] It appears as though the bank employs a managed security services provider for intrusion detection monitoring and alerting (and possibly more). Using a third-party provider as a part of information security strategy is probably a good idea for organizations that do not have, cannot afford, or do not want to build in-house expertise. Managing third-party service agreements can sometimes be quite a challenge.

The bank notified law-enforcement authorities and hired outside forensic firms to analyze the breach.

"The server that holds our debit card information they were in there and they transferred information out. But we can't really tell if it was 10, 20, or 30 percent of our card holders," said Seitz.

They did, however, get Track 2 data contained on magnetic stripes, including account numbers, according to Seitz, as well as PINs in at least some cases. "They got some PIN numbers, but a very small percentage compared to the debit card base that we have," says Seitz.

Exactly how the hackers tapped the server isn’t publicly known.
[Evan] This will be determined as part of the forensic investigation, but publicly this may never be known. We can only speculate. The information that was compromised is very sensitive and should have never been accessible from the "outside". Who knows if the server was actually compromised directly or through another avenue of attack. See, I am speculating. Thankfully, the bank had detective controls in place.

1st Source Bank is sending out letters reminding their customers to check their recent bank account activity.
[Evan] As people should anyway.

"Out of an overabundance of care, we’re reissuing new debit cards to all our customers"
[Evan] We could argue "overabundance".

the bank is reissuing all cards, which are MasterCard-branded, as a precaution

1st Source also is offering customers free credit-report monitoring for a year.

He adds that he couldn’t comment about the state of the bank’s compliance with the Payment Card Industry data-security standard, or PCI.
[Evan] The Visa U.S.A. Cardholder Information Security Program (CISP) "List of Compliant Service Providers - All" is here (a little different, but good information nonetheless).

"We are working with law enforcement to find these bad guys, and we didn't want to tip them off," said James Seitz
[Evan] Chances are that the "bad guys" already know what the have.

"Our number one priority is our customers. We shut everything down right away and hired the best people we could get our hands on to see what happened here and to make sure it doesn't happen again," said Seitz.

1st Source began working with law enforcement and called in a forensic computer specialist team from the Washington, D.C., area to shut down the breach immediately and to help determine who was behind it.
[Evan] 1st Source should be commended for not hesitating to bring in outside help.

It has taken a while to get all the information out about the breach, Seitz said, since the bank had to spend time going through all of its laptops and computer systems.

"You've got to understand what you have," he said.
[Evan] A high-priority task for information security governance is to understand what you have. During an incident response is not a good time to figure out what you have.

Though the breach is something rather new for 1st Source, Seitz said these types of breaches seem to be hitting businesses in general more and more this day and age.

"Certainly, it's never happened to us before," Seitz said. "But it's becoming more prevalent. Daily, banks are going through this."
[Evan] Breaches are as prevalent or more prevalent than they have ever been. I agree with Mr. Seitz. Recognizing this fact, what excuses do organizations have for not investing in and properly managing information security programs? I am not saying that 1st Source does not, I am writing in general terms.

Bank officials have yet to tally the cost of mailings to customers, creating new debit cards, consultants’ fees, paying for identity theft protection and employee overtime related to the security breach. Seitz called it a "considerable cost."

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

Customer Reactions:
"My main worry is that my money is going to be gone tomorrow when I got to my account," said Jeremy Reinke, a 1st Source Bank customer.

"Is my money still in my account, and can they correct this so it doesn't happen again?" asked Chris Stump, another customer who hadn't heard about the May 12 security breach. "I guess in some ways I would have liked to know by now."

Commentary:
Judging from the customer comments I have read, people are concerned about the breach, but not angry with 1st Source Bank. I think this is because they perceive the bank's response to be open and genuine. The bank did employ proper controls to identify this breach early on and provided notice to customers in a timely manner. The fact that the bank took additional steps like re-issuing cards and providing credit monitoring only adds to the favorable perception.

I am still interested in knowing more detail around how an unauthorized outside entity was able to access this sensitive information in the first place.

Past Breaches:
Unknown

End user security psychology, part II: Can knowledge-based authentication be effective?

Wed, 02 Apr 2008 07:11:25 +0000

Another post on Finextra discusses some recent research out of New Zealand that determined that the longer an authentication process drags on -- the more gantlets a user needs to run before being let in a site's front door -- the less secure those users perceive the site is.

Implementations of knowledge-based authentication (KBA) -- asking "secret", out-of-wallet questions that presumably only the end user knows the answers to -- on the Web have been on the rise in the past few years, particularly in online financial services, as part of efforts to fulfill FFIEC guidelines for additional risk mitigation measures that address the inadequacies of single-factor authentication. The concept of layered authentication -- the riskier the transaction, the more stringent the authentication measures -- is related to this, and KBA can be readily (and simplistically) adapted to layered authentication by simply increasing the number of secret questions that the system asks.

Of course, as a standalone method of authenticating users at login, asking out-of-wallet questions in addition to username and password doesn't rise to the level of strong (two-factor) authentication, since they're all variations on "what you know". So from a security standpoint it's difficult for KBA to really provide identity assurance. But isn't ease of use and peace of mind for end users that's driving financial institutions to implement KBA? (Let's put aside for a moment any cynicism about KBA being a cheap alternative for the FI.)

Apparently, though, there's a point at which users' confidence that the bank is protecting their assets tips over into suspicion that the bank's security isn't up to snuff or even that a fraudster is pumping them for personal information. And then there's the annoyance factor: the inconvenience in terms of the time and effort to remember all of the PINs, passwords, and answers and jump through those hoops. It's as if the typical Internet banking customer is a tender orchid needing just the right conditions to flourish.

The only problem is that in most cases this isn't true. Buck up and spend the cash on a real two-factor authentication system, mandate its use, and customers will adapt -- even thrive. There are enough different methods of two-factor our there that the difficult decision should not be whether to implement two-factor, but which form factor to choose.

ATM Communication - How Secure ?

Fri, 21 Mar 2008 09:34:00 +0000

A while ago, I attended a class on PIN and Key Management for Payment Networks. ANSI has laid out strict guidelines (in their ANSI X9 TG-3 standards checklist, ANSI documents X9.8 and X9.24) for how a customer's PIN should be kept secure: how they should be stored on the card (store only the difference/offset of the encrypted PIN value and the natural PIN), what the minimum encryption requirements are (Triple DES), what the specifications of the devices that encrypt/decrypt the PIN are (Tamper Resistant Security Modules), how PINs should be exchanged between various Financial Institutions (exchange keys between two FIs out-of-band AND under the principles of dual control and then encrypt the keys, how should compromised - no - even "suspect" compromised PINs and Keys that encrypt the PINs be treated (securely delete the key, recreate a new key under the principles of dual control and split knowledge and re-encrypt *every* key or PIN that has been encrypted under it! and re-issue cards containing PIN offsets for PINs encrypted under the new encryption key, if applicable) etc.

It was simply awesome. To know that the Financial Institutions do their due diligence is a huge confidence booster. The fact that these guidelines are just that - guidelines, and haven't been strictly enforced by governing bodies is not my biggest concern. Neither is the fact that there are a number of papers out there that talk about the insecurities in PIN translation.

The following, however, is:

The folks at redspin (Brian Hayes, Matt Marshall) analysed ATM traffic and wrote a paper on insecurities in ATM communications.

What you see above is the raw data message format that leaves the atm connected to a network. Cleartext communication. Notice the account number and expiration date. Totally vulnerable to man-in-the-middle attacks. The response message that is supposed to come from the FI, looks something like this:

I'm not going to say what one needs to do at this point. Read up message format ISO 8583. It is scary.