Skip to content ↓ | Skip to navigation ↓

One of the challenges with securing your credit card data is that once you engage in a transaction, you’ve given away the very thing you want to secure.

The entire principle of a credit card involves divulging data that has value to a third party (in exchange for goods). As a consumer, you have absolutely no way to track who has access to that data after it leaves your possession.

It’s a problem when you buy stuff online, when you pay for food at a restaurant, or when you make a political donation. This problem is somewhat mitigated by the requirements of the PCI Data Security Standard and the PCI Council.

All of these same issues exist with password authentication. Using a username and password to authenticate is a transaction where you turn over something of value in exchange for some goods. You have zero assurance about what happens to that data after you hand it over.

You might have some confidence that a large company with a strong brand wouldn’t blatantly mistreat your precious password, but frankly, that’s pure justification. Code is code, and people are people.

This article from Deloitte provides a good description of the risk.

How do passwords get hacked? Most organizations keep usernames and passwords in a master file… So far, so secure. However, master files are often stolen or leaked.

A hashed file is not immediately useful to a hacker, but various kinds of software and hardware, discussed in this Prediction, can decrypt the master file and at least some of the usernames and passwords. Decrypted files are then sold, shared or exploited by hackers.

The fact is that it doesn’t matter how strong your password is (well, it might, a little) because you have no guarantee how it’s treated and stored after the fact. What do I mean?

Here’s an example of Microsoft only looking at part of the password you enter, so even if you entered a very long password, it wasn’t being used. This is what I mean when I say you have no guarantee how your password is treated after you hand it over.

There are two solutions to this problem. The first is to drive transparency through the process. The use of user verifiable standards and open source authentication and identity mechanisms could solve this problem.

The use of a personal password vault is something you can do today to take a little control of your credentials and prevent a Facebook compromise from creating a personal financial crisis.

The second solution is to stop using passwords as the primary means of authentication. Solutions that employ multiple factors are starting to appear, but we’re a long way off from pervasive use.

 

Title image courtesy of ShutterStock

Hacking Point of Sale
  • Credit Cards SA

    Just make sure the website you purchase at has https and you should be fine.

    • Tim Erlin

      If only it were that simple! While SSL is intended to guarantee end-to-end encryption for a transaction, there are a number of ways in which it's flawed and can be either defeated by an attacker or simply mis-managed by a vendor.

      There have been some high profile certificate-based compromises lately, and of course, the data you send of SSL/TLS still get decrypted at some point on the other end. If you don't trust the entity in control of the connection, you're stuck.

      That's part of why I suggest using a password vault and different passwords for different sites. While it's not a perfect solution, it prevents some one compromise from immediately resulting in compromising other accounts.

      Checking for an encrypted connection is necessary, but not necessarily sufficient.

  • I’m not a fan of the analogy you make between passwords and credit cards. Credit card data, by design, is the same for every vendor you share it with. Passwords should be unique to the particular web site you are logging into. In reality people do sometimes share passwords across sites, but that is by their choice rather than necessity. So trusting a web site with your credentials to log in should only have impacts associated with that specific site and not every other site that accepts passwords, unlike the impacts of losing your credit card data.

    You refer to a “hashed [master] file”, but it is the individual password entries in an authentication database that are typically hashed and not the ‘file’ itself. While hashing is a cryptographic function, it is not considered encryption — an important technical distinction. Cracking doesn’t decrypt password hashes; it attempts to guess the original password and then hashes the guesses to compare to the stolen database entry. If the hashed guess and hashed password match then the attacker knows they guessed correctly. Some sites do choose to encrypt passwords rather than hash them, but this is fairly rare and is not considered a good security practice where it can be avoided.

    While it is true that a user may not know how a site manipulates or stores their password it concerns me that this leads to the statement “it doesn’t really matter how strong your password is (well, it might, a little)”. Password strength matters a lot in any situation where the password isn’t just stored in plaintext. People should always focus on creating a strong password even if they aren’t guaranteed it is properly protected. Transparency into how a site is protecting passwords is great, but let’s not stop trying to do our part until we have obtained that info.

    You probably didn’t mean to say we should stop caring about their password strength, but I’ve learned to be careful about providing advice that people can use to justify their desire for fewer security responsibilities.

  • Tim Erlin

    First, thanks for the feedback. I definitely appreciate it, and am happy to have the conversation. Let me respond to each paragraph.

    "Credit card data, by design, is the same for every vendor you share it with. Passwords should be unique to the particular web site you are logging into. "

    I was aiming to make this point exactly by recommending the use of a personal password vault. Whether by choice or not, it's incredibly common that people maintain the same password across multiple services. The reason that people choose to do this isn't complicated; they simply can't remember so many different passwords. A personal vault can remove that barrier and make is feasible to keep 25 or 50 completely different passwords, thus mitigating this issue.

    Now, you can actually do the same thing with credit card numbers these days. Check out this LifeHacker article on the topic: http://lifehacker.com/5831160/use-virtual-credit-

    Your criticisms about my explanations of encryption, hashing and decryption are all valid technical distinctions. I was aiming to keep it clear for a particular audience. My overall point, technical distinctions aside, is that as a consumer of a service, you have no insight into how a vendor is handling your credentials. There are some exceptions. For example, a site may use a third party authentication service or standard that provides some assurance, but you're still not guaranteed a high quality implementation. The end result, is that you really want to limit the damage of a compromised account by using different passwords for different services. The other point here is that *greater* transparency in credential handling would be beneficial. I'd make the same argument around transparency for credit card processing; more transparency on how data is handled and by whom is valuable.

    As for password strength, I might have been a little tongue and cheek, but I'll stand by the statement with modification: Password uniqueness is more important than password strength. If the service is actually encrypting passwords, then strength won't matter if the key I stolen or compromised. If the site is using basic hashes, then strength does matter, but it's actually length that matters more than overall complexity (ref: http://xkcd.com/936/), and this is only true if they do a good job with the implementation (see Microsoft's issue in the original post). If the site is using salted hashes, then strength, as in complexity, matters as well.

    Feel free to keep this conversation going, and thanks again for the feedback.

  • Scout

    You have beautifully explained the importance and updated news on the Payment Gateway Services. Keep up the nice posting as I have subscribed to your blog.

  • John

    Great info