For an application like ccsrch, having this data available would be very handy to reduce false positives when scanning a large file system (scanning a large server produces a huge number of possible hits), but for what I would call fairly misguided reasons, the official registrar of these numbers (the ABA) doesn’t make this data publicly available. As a result many people have pulled together what data they could find and made it freely available.

So I’ll add my name to that list.

I’ve pulled data from many public sources (sorry, I didn’t keep very good notes as to the sources) and cleaned it up to a reasonable point. All told, I’ve probably spent 40 hours or more cleaning this data up and getting it to a usable state. It contains over 60,000 entries, including major credit cards (Visa, MasterCard, Amex, Discover) as well as a few merchant entries.

Each record contains the following:

• IIN
• Type (Mastercard, Visa, Visa Credit, etc.)
• Name (Issuer name)
• Length

Data Quality

It’s not perfect. It’s from public sources so there may be errors, and there are some duplicates from cases where I wasn’t able to determine who the IIN actually belongs to. I’ve also updated for name changes and mergers where possible, but I’m sure I’ve missed a few and there are some where the assets where split, so I don’t know who the correct owner actually is (Washing Mutual being the leading example of this).

In general, I leaned to the side of caution – so if I didn’t know for sure, I left the duplicate in.

If you need absolutely correct data – contact the ABA, they are the only source that can give you the completely accurate listing. If you need to have a decent idea if a number is valid for most cases – I would say that this data is good enough.

Warranty

Just to make it really, really, really clear: There is no guarantee that this data is accurate, that it won’t cause to lose your job, cause your house to burn down, or cause Rebecca Black’s Friday to get stuck in your head (yup, you’re welcome ).

Copyright

Based on my understanding of US copyright law, it is my understanding that this data is not subject to copyright as it is a compilation of facts and doesn’t constitute an original expression. Thus, to the best of my knowledge, this data is in the public domain.

Download

Here (zipped CSV)

Once I saw the file name, a sinking feeling set in and the answer became clear:

%LocalAppData%\Google\Chrome\User Data\Default\Sync Data\SyncData.sqlite3

So it turns out that it’s Chrome’s sync feature that was saving my information, but why?

It turns out that auto-fill data is synced with your Google account (if you’re signed in and have the feature enable, of course), and all of the computers you’re signed into – and by default, without the benefit of encryption. This file may contain any number of things, from mine I was able to extract the following:

• Full name
• Wife’s full name
• Date of birth
• Wife’s date of birth
• Social Security Number
• Multiple credit card numbers
• Multiple CVVs
• Bank account & routing number

Not to mention quite a few websites I’ve been to, various addresses, employer’s name and other various useful tidbits. All would be quite useful for identity theft or highly targeted spear phishing.

Now am I saying that syncing auto-fill is bad? No, not at all. It’s a very useful time saver, but what takes it from a useful feature to security issue is the fact that by default, this data isn’t encrypted!

What are the risks?

There are three significant risks I see here:

1). Disclosure to less trusted systems:

In my case, I trust my laptop to be secure; between full-disk encryption (via TrueCrypt) and other precautions, I know that I don’t have too much to worry about. On the other hard, my Work PC is on a corporate domain, and at least a couple dozen people have permissions sufficient to access my personal files – thus I don’t trust anything too valuable on it.

Now because of the fact that this feature is insecure by default, that data is exposed to a less trusted system.

It can also go the other way: a number of auto-fill entries on my personal laptop were from forms on internal-only applications that only my Work PC would be able to access. So this means that anything sensitive could be leaked to home networks which are typically less secure than corporate environments. If you routinely handle PCI, HIPAA, or other restricted information – this type of leak could be a major issue.

2). Spear Phishing:

Let’s imagine a scenario:

You work for a defense contractor and I work for a foreign intelligence agency. Through some targeted attacks I manage to penetrate your home network, but have been unable to make it into your corporate network. I grab the sync database file from your home PC and extract one of your credit card numbers. I look up the IIN and find out what bank the card is from. Once I have this, I build a PDF with the latest 0day exploit, and send it with a convincing subject line:

“Important Information about your Bank of America credit card ending in 7850″

Normally you’d dismiss it as spam, but the last four digits are right – so you open it, just in case. The exploit kicks in. I’m in, you’re done.

This is just a simple and quite contrived example, but you get the idea.

3). Google Data Mining:

This is the most paranoid and least likely, but given Google’s issues in controlling their people – I’d say not impossible (see here, here, and here).

Just for a moment, think about the fact that Google has the following:

• Your account data (name, email, etc.)
• Your auto-fill history (see the list of items I found above)
• Tons of data from their other services
• At least parts of your browsing history, if not much of it
• Engineers that truly enjoy data mining

Most other companies I wouldn’t worry about; but knowing the people that Google hires, and the skill they have in manipulating data – you know that some engineer is using his 20% time to do this (or at least is wishing he could).

If nothing else, I know if I worked at Google – playing with this data would be tons of fun.

Want to see your data?

To see what Chrome has saved about you, download SQLite Browser, and open the file I mentioned above. Go to the “Browse Data” tab, and select the “metas” table. What you’re looking for is in the “non_unique_name” column (among other places). You should see something like this:

The entries starting with “autofill_entry” are the ones you are interested in, but you’ll likely find some of the other records interesting as well. If you see the word “encrypted” then your data is already encrypted, and you don’t have to worry about this.

Is this a vulnerability in Chrome?

No, not at all – though it was a mistake. They should encrypt everything by default, and not provide an option to do otherwise. There’s no reason to expose users to a potential security risk when there’s a simple fix. Security isn’t something users should have to opt-in to; and unless there’s a very good reason, they shouldn’t have a way to opt-out.

Google should understand security and the value of the data they hold; they should be more responsible for the data (and faith) people give them.

How do I fix it?

Simple, from the “wrench” menu, select Options -> Personal Stuff -> Sign In -> Advanced… and then under “Encrypted data types” select “Encrypt all synced data” – and that’s it. After a couple of minutes the entries that were visible before will now just display the word “encrypted.”

You can also go a step further, and get rid of this data by disabling auto-fill to ensure that potentially sensitive information isn’t being persisted when it shouldn’t be.

There’s been an amazing resistance to SOPA, from the boycott of GoDaddy to public statements from celebrities such as Adam Savage – the public outcry against this horrid piece of legislation has been quite inspiring. But how often will you be able to get so many people to stand up and take action before they start to lose interest? How many times can you raise the troops before the numbers start to dwindle; how long before the celebrities start fearing they’ll be branded in the media as extremist or crazy? How many times can you raise the call of breaking the internet and freedom of speech before the public gets bored and goes to read about the latest Hollywood divorce instead?

Here’s how I see it going:

1. Strip many of the worst parts of SOPA and get it through congress. By removing these offending pieces, those backing SOPA will try to make themselves look responsive to the community, and it’ll be played as a victory for the community in the media. All in all, if you aren’t paying attention it’ll look like a victory for the people.
2. Next year, introduce a bill to modify SOPA to change the wording here are there, edging it just a little closer to the original. If done carefully, it’ll be easy to dismiss those that try to stir up another outcry as over-reacting or even paranoid.
3. In a few years after a series of modifications, we have SOPA, just as broad and dangerous as originally intended – and the vast majority of people who fought SOPA would have no idea.

If you have a financial motivation to get something like this passed, they key to success would be patience. Chip away slowly at DMCA Safe Harbor protections, at what requires a judge instead of an administrative action, at transparency so that any action ends up happening behind closed doors. In enough time you’ve established a law that gives the US Federal Government a massive amount of control of the internet, without oversight – all in a way designed to get offending web sites off the internet as quickly as possible. To say it would be ripe for abuse would be a massive understatement.

Am I being paranoid? I honestly hope so – I really hope that there aren’t people out there looking to limit the freedoms we cherish for their own profit, but the fact that SOPA was introduced in the first place makes that hard to believe.

Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)

So based on this requirement I assumed that the code to do this would be common and widely available; much to my surprise there are rather few samples that do this, and of those I found they only showed the last four (which when you are handling a lot of credit cards, searching for an account by the last four isn’t all that helpful) and were often rather fragile.

So I whipped this up, hopefully it’ll be useful to others.

public static string MaskCreditCard(string value)
{
  const string PATTERN = @"\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|" +
    @"6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|" +
    @"[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})\b";
 
  var replace = Regex.Replace(value, PATTERN, new MatchEvaluator(match =>
  {
    var num = match.ToString();
    return num.Substring(0, 6) + new string('*', num.Length - 10) +
      num.Substring(num.Length - 4);
  }));
 
  return replace;
}

The regex pattern is from Regular-Expressions.info and should detect most major cards.

To properly test the services, I had to make a compromise: temporarily modify the application to expose a SOAP endpoint. While this changes the state of the application and thus reduces the validity of the tests, it does provide a reasonable way of testing the web services to ensure that they are behaving as intended.

The recently released SoapUI Pro 4 adds new security testing tools that makes this a viable (and attractive option). To get this working, there are a few small changes that need to be made to the solution:

First, you’ll need to add a reference to “Microsoft.ServiceModel.DomainServices.Hosting.EndPoints” which is part of the RIA Services Toolkit; this allows you to expose different End Points for the service such as SOAP and OData.

Next, you’ll want to add the following configSections entry to your Web.config:

<configuration>
 <configSections>
   <sectionGroup name="system.serviceModel">
     <section name="domainServices"
      type="System.ServiceModel.DomainServices.Hosting.DomainServicesSection,
      System.ServiceModel.DomainServices.Hosting,
      Version=4.0.0.0,
      Culture=neutral,
      PublicKeyToken=31bf3856ad364e35" />
   </sectionGroup>
 </configSections>
 ...

Finally, to expose the SOAP end point:

<configuration>
 ...
 <system.serviceModel>
  ...
  <domainServices>
   <endpoints>
    <add name="Soap"
     type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
     Microsoft.ServiceModel.DomainServices.Hosting,
     Version=4.0.0.0,
     Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
   </endpoints>
  </domainServices>
  ...

Finally, just follow the instructions for SoapUI to setup your tests, and you can feel (just a little) more confident in your application. Passing with flying colors obviously doesn’t mean your application is bulletproof, but it helps to confirm that web service code is solid.

Now, while this does provide some insight into your application and should help find common issues, it’s not a replacement for a professional assessment by a qualified auditor. If you are handling credit cards or other highly targeted information, please consult a security specialist before a public deployment.

Thanks to services like StackExchange and its numerous clones, it seems the days of standalone forums are numbered; when combined with the increasing strength of WordPress as a full-blown CMS, this move actually makes a lot of sense.

I’m excited both as a user and developer – this opens many new doors from both perspectives, and will certainly increase adoption of the software, as integration with the current version is a bit tricky.

Congratulations to the entire team on this release; it really is a major milestone for the project!