By Raz Rafaeli, CEO of Secret Double Octopus
The “club” of companies or banks that haven’t had their data raided by hackers is becoming more and more exclusive, as more and more hackers breach databases that give them access to credit cards, transactions, customer history – anything and everything they can make a quick buck off of. Many of those credit card numbers and associated information (user names and addresses) end up on the Dark Web, where there are actually so many purloined cards and identities available, that you can buy one for under $15.
Aiming to reduce the number of breaches, if not eliminate them altogether, the Payment Card Industry Security Standards Council (PCI) has released version 3.2 of its Data Security Standard (DSS), which officially takes effect next February (currently they are “best practices”). All companies that want to ensure that they remain as members in good standing with PCI will be expected to revise their security systems and adopt the new rules.
Among the changes from the previous versions of the standards: greater protection of the customer PAN (primary account number), using TLS (Transport Layer Security) instead of SSL (Secure Sockets Layer) protocols to protect communication, and changing control processes to incorporate verification of other PCI DSS requirements that are impacted by a change in the system, such as network diagrams, endpoint controls, and the inclusion of new systems. A full assessment of the security situation must be done quarterly, and penetration testing on segmentation controls must occur at least every six months. And, management must clarify who in the organization is responsible for data safety – and ensure that those who are responsible know that they will be held accountable, as will top management, if data is stolen.
One of the biggest changes is the increased use of MFA (multi-factor authentication) to authorize transactions. All employees who work with customer data in any context now will have to use MFA to access that data. In previous versions of DSS, that was required only for employees who accessed the CDE (cardholder data environment) remotely; for access via local servers (looking up data on the internal company database), a username/password (the most popular form of local user authentication) was sufficient.
Now it isn’t – a second factor is needed too, but chances are that the main method of authentication will remain a username/password combination. PCI has no problem with that; in fact, an official guidance document issued by PCI that discusses adopting MFA lists four common authentication scenarios (such as connecting to a local network and from there using a password token to access a remote network). In each of the cases, PCI discusses what needs to improve in order for the transaction to be compliant with DSS 3.2 – and in each, passwords are the primary authentication method to be used.
We would debate the wisdom of relying on username/password combinations for authentication; after all, that is what has gotten so many companies in trouble in the first place. Some of the biggest hacks in recent years – like the Target hack, a major black eye for credit card processors – were initiated and executed by hackers who managed to get hold of user credentials (username/password) to raid servers – bringing the price of purloined credit card information on the Dark Net down even further, thanks to the flood of credit card data stolen.
Although DSS does not recommend any specific authentication method – and two will do – companies should consider their choices long and hard, because not all authentication methods are going to fulfill the requirements – or keep data safe. Companies would do well to examine the experiences of firms in other industries that require authentication to access data or services.
If not passwords, what other methods of authentication should companies be considering? Authentication, in general, is defined as a method in which the person connecting can prove they are whom they claim to be. That proof is based on one of three “states of being” – something you know, something you have, and something you are. Usernames and passwords clearly fit into the first category; but the problem, as we’ve seen, is that “something you know” can be pried out of you by hackers.
What about “something you have?” That could include various devices, hardware tokens, or the like. In mobile authentication, for example, users who log into a web service often will get a text message with a one-time code (token) they need to type into their phones and send via SMS to prove that they are in possession of the device used to connect to the service, the idea being that the person possessing the device (“something you have”) is the legitimate user; otherwise they would have reported the device stolen and canceled their service. “Something you are,” the third method, is best exemplified by the use of biometrics, such as thumbprints or fingerprints, an authentication method found, for example, on iPhones.
In the latter two methods, the problem of stolen passwords is obviated, since they aren’t used. But some security experts, have also criticized the use of SMS to authenticate a device; besides, that authentication method is not necessarily relevant in a bank or payment setting. Even biometrics, according to NIST (the US National Institute for Standards and Technology), isn’t necessarily strong enough to stand on its own – or as a primary – authentication system. And as far as NIST is concerned, usernames and passwords are far worse authentication methods from a security point of view. The NIST guidelines have created some concern in the mobile industry, as all of the usual methods used to authenticate users have been pegged as weak, or very weak, by the agency.
What, then? One solution that mobile firms have found success with – and could satisfy DSS requirements – involves using password-less authentication via randomized code that uses multiple channels to authenticate a connection. In this scenario, a device would connect with a server, generating a random code from a large set of possibilities that the remote server would acknowledge (as it would have prior knowledge of its existence). The chances of hackers honing in on the right code at the right time would be quite low – and if the code were sent in a super-secure manner, such as with very strong encryption, or split up among multiple channels – or both – hackers would have zero chance of ascertaining the code. Backed up by a second authentication factor, such as a biometric thumbprint, the system would be almost foolproof. It works for mobile – and can work for payments, too.
No matter what combinations they choose, companies need to look very carefully at the methods available, and how secure they really are. In a sense, the new DSS is providing firms with a much-needed push to get away from authentication systems that have proven to be very vulnerable in the past. As with so many other things in life, it’s often habit and a state of torpor that keeps us in place, doing the same old thing – even if it doesn’t work. With a “shock to the system,” PCI DSS 3.2 now wakes the industry up – and has the potential to make anyone who uses or works with credit cards safer—if done correctly.