How wide was the Equifax data breach?

143 million US consumers were caught up in the data breach. I keep seeing it portrayed as 44% of the US population. But, the US population includes children.

Initially, it seemed to me the better metric was 11 million more than all of 2016 IRS tax filers. The problems with this latter comparison? Lots of people who file taxes might not have a credit history and some with credit histories might not file taxes in a specific year. Which brings up taxes for a specific year comparing against people who had a credit history across many years is sketchy.

Other statistics give me headaches too.

  • The US Census’ latest 2016 estimate is that there were 325M (million) people in the country. The original 44% statistic is based on that.
  • The US Census’ latest 2016 estimate is that there were 249M adults in the country. That brings the percentage up to 57%.
  • The Bureau of Labor Statistics says in July 2017 when the hack occurred, there were 160M members of the civilian noninstitutionalized population. That excludes inmates and members of the armed forces most of whom probably have credit histories.

So, I took the BLS 160M and looked up the excluded populations.

  • It looks like there were about 1.5M in the prisons.
  • And there is about 1.4M active military.

Combining these, it looks like about 88% of people in the “potentially have worked population” were affected.

I feel good with the 88% number.

Really, though, everyone probably has had their SSN and birthday exposed.  If you have ever attended a K-12 school, post-secondary education, gotten insurance, gone to a doctor, engaged in any way with a financial institution, or given your SSN to a government entity, then you should assume that your personal information is ready to be exposed at any time. Nor should you rely on being told. The state of Georgia exposed every voter’s SSN to subscribers of the voting list by accident and notified no one because they felt the CDs being returned meant no one could have the info. (Because the subscribers could not have copied the files off the discs.)

Overuse of SSNs

The overuse of the Social Security Number bothers me.

Healthcare providers use the SSN. They all want it, so they all have it in their files and databases. Given the push to move records to electronic form, they all have it recorded in databases. This makes them tempting targets for fraudsters. They have to use the strongest security practices to protect the data which also makes working with it more difficult which leads to shortcuts that make them more vulnerable.

From Bruce Schneier,

It’s not just Equifax. It might be one of the biggest, but there are 2,500 to 4,000 other data brokers that are collecting, storing, and selling information about you — almost all of them companies you’ve never heard of and have no business relationship with.

He goes on to talk about how companies are tracking our moves online and tying it to their profiles of our identity.

If my financial account (like a credit card number) is compromised, then the bank’s solution is to close the bad account and open a clean one for me. If my Social Security Number is compromised, then my solution is to closely monitor the opening of accounts using it. Getting a new SSN is very difficult because unlike a financial account, the number is my unique identifier.

Personally, I think the fine for a healthcare entity getting breached should be $100 per account. So, Anthem’s 2017 breach of 18,000 members would cost it $1,800,000. Anthem’s 2015 breach of 78.8 million would cost it $7.88 billion. (They got a fine of $115 million or about $1.50 per account.)

 

DOJ, Dreamhost, and DisruptJ20

The government has no interest in records relating to the 1.3 million IP addresses that are mentioned in DreamHost’s numerous press releases and opposition brief.

Basically, the Department of Justice served Dreamhost this warrant asking for

  1. the code backing the web site,
  2. the HTTP request and error logs,
  3. logs about backend connections to upload files to the server
  4. databases
  5. email account metadata and contents
  6. account information for the site owner

Dreamhost resisted the warrant as overly broad. The DOJ is backing off the HTTP logs and unpublished draft posts.

If the site is using certain WordPress plugins to track visitors, then it is possible that the IPs for visitors are in the database. Or if the DOJ looked at the public HTML and noticed a Google Analytics JavaScript, then they know they can issue a warrant to Google to get the visitor information. Would Google resist handing it over as hard as Dreamhost?

 

TED Talk: Trolling a Spammer

Back in the early days of spam, I did try replying to a few, but I never got anything like this.

Suspicious emails: unclaimed insurance bonds, diamond-encrusted safe deposit boxes, close friends marooned in a foreign country. They pop up in our inboxes, and standard procedure is to delete on sight. But what happens when you reply? Follow along as writer and comedian James Veitch narrates a hilarious, weeks-long exchange with a spammer who offered to cut him in on a hot deal.

Phishing

Over a month ago, I received a creative phishing attempt. We use a relatively popular service which is mimicked fairly well. I typically receive notification emails from it by an administrative assistant. This came from another name. That was my only real clue that made me look closer. Since, I have received almost a dozen, each pretending to be a different product.

I noticed they all used different domain names for the payload link. But, they all use file.php?d=<value> or f.php?d=<value> to deliver the payload.

Computers are smarter than I am when it comes to patterns like this, so I created an email filter to look for the file names and set it loose. If I see another phishing attempt using another script name, then I will add it to the list. But, so far, I am pleased with how well it protects me from myself.

LastPass feature request

Ghost in the Shell Laughing Man shirt
Ghost in the Shell Laughing Man shirt

There is no enforced standard for passwords for a web site, so they can be all over the place for requirements. Nor do sites typically explain what are the exact standards before a failure. And then most will state the minimum and types of characters. But, too many leave out the maximum number of characters allowed so I end up experimenting to figure out something as strong as I can get. One of my favorite blogs is Password Requirements Shaming.

Web sites almost certainly record the password to a variable. Hopefully they then encrypt it and store the hash instead of recording the password as plain text. I use LastPass’ password generator to create something typically 40 characters [1] long and try it. Almost always that results in an error that my password is too long and the limit is actually something shorter. There are some frustrations with how sites handle these cases:

  1. It would be nice if more sites would look at the passwords with JavaScript and report if it is too long or too short or have bad characters or do not match both locations. Very rarely do they check that it is too long. Most just check that they match. Letting me know before I submit it, keeps me from wasting my time.
  2. In HTML, maxlength defines how many characters the input element will accept. I sometimes look at the HTML to select what password length to generate, but there is no guarantee that the maxlength is reflective of what will work. It fails to help so much I have gotten out of the habit.

Arbitrariness with password policies probably makes people tend to more insecure practices through simplification. This is The Paradox of Choice.

It occurred to me that LastPass developers could solve this problem for me. If LastPass knew the password requirements for a site, then it could preset the generator to the maximum length that will fit. When I go to create a password for a site, then it could work the first time instead of taking 2-5 tries to find something that finally works. Most users are lazy and would not change the preset, so passwords would tend to be the stronger. [2]

Admittedly, it usually works on the second try once I’ve nailed down the maximum number of characters allowed.

[1] Originally I would try 50 characters, but I eventually relaxed that down a bit. Occasionally, I go through brief periods where I just try 30 or 32.

[2] See Nudge: Improving Decisions About Health, Wealth, and Happiness for how organ donation rates work for how t his would work.

Email Changes

Ran across a site where if one changes the email address associated with the account, it sends the confirmation email to the new address.

Say, I am a Blackhat and used a phishing attack to get the password for the account. Having legitimately logged in, I then change the email address associated with it from victim@outlook.com to my blackhatalias@gmail.com. Sending the confirmation to blackhatalias rather than the victim ensures a compromised account will get altered. Strong security would want to prevent the change unless the owner of victim@outlook.com confirms the change.

Though, it does look like an email was sent to victim@outlook.com almost 3 hours after the confirmation saying:

Still scary. The blackhat has probably already made off with the data and done the damage.

I get the temptation to allow users to change their email address to a new one. It will prevent support phone calls because if they no longer have control of the old email account, users can simply change it to another address they do.

Of course, the site in question also does not have Two Factor Authentication. But, then it also is just a support forum. So, the ramifications of losing the account is impersonation at worst. They could ask or answer a question as me or change the profile to say something demeaning.

Verification Codes

One would hope that verification codes would be extremely random. More randomness makes it harder for a malicious entity (person or computer) to guess the code. Less randomness makes it easier. With all the Two-Factor Authentication (2FA) out there, we hope there is enough randomness in these methods to make them unguessable by someone attempting to get into our accounts. But, like all security technology, the hackers get better and protections get easier to break over time.

There is a current temptation to record the codes my generators provide to see if there is a pattern. At least in the back of my head it “feels” like there might be one. My intuitions sometimes turn out true (confirmation bias) and usually do not (reality). If little ole me can see the pattern, then I am sure smarter people than I have seen it as well and maybe even have a way to anticipate the codes.

Scary Password Policy

Doing a training thing for work next week. The training coordinator sent an email to 25 of us about how to access the learning portal. The username is email and password is a single word with an exclamation point. My first instinct was get in ASAP and change the password since so many other people have access to my password.

Only.

There is no link. I click and click and clink. I cannot find it.

Finally, I look at the source code and notice features in it that reveal this portal is running on WordPress. So, I added “wp-admin/profile.php” to the URL and get a 404. I added it to the domain and bingo, I was at my own profile. So, I used the WordPress password feature to generate a strong password and change it.

I wonder how many people have taken training from these people and bothered to change the password?

Phishy Corporate Communications

Received an email that looked phishy:

Greetings,

Please read this important e-mail carefully.

Recently you registered, transferred or modified the contact information for the following domain name:

ezrasf.com

In order to ensure your domain name remain active, you must now click the following link and follow the instructions provided.

http://verify.domain.com/registrant/?verification_id=999999&key=BFrrpxGDbb&rid=999999

Sincerely,

Domain Registrar

The web page listed my name and email address, so the riskiness of clicking it seemed low, but ALL KLAXONS were going off in my head about this being phishing. I also received another email threatening to suspend my domain if I did verify it.

The email headers really confirmed for me this was phishing:

Received: from mx.registrarmail.net (mx.registrarmail.net [216.40.35.248])
	by myemail-mx26.g.emailprovider.com (Postfix) with ESMTP id 999AA999999DDD
	for <myemail@mydomain.com>; Mon, 28 Mar 2016 05:43:25 -0700 (PDT)
Received: from cron01.endurance.prod.tucows.net (unknown [64.99.53.70])
	by mx1.registrarmail.net (Postfix) with SMTP id B5999999E51
	for <myemail@mydomain.com>; Mon, 28 Mar 2016 12:43:24 +0000 (UTC)
Received: by cron01.endurance.prod.tucows.net (sSMTP sendmail emulation); Mon, 28 Mar 2016 08:43:24 -0400
X-MP-Host-Origin: front04.endurance.prod.tucows.net
Message-Id: <999999.0.28Mar2016084324-osrs-registrant_verification-999999@endurance.registrarmail.net>
Date: Mon, 28 Mar 2016 08:43:24 -0400 (EDT)
X-OSRS-Id: osrs-registrant_verification-999999
From: "Domain Registrar" <support@registrar.com>
To: <myemail@mydomain.com>
Subject: Important: Please validate your domain name

The original sender is tucows.net? There’s no way a real company would be using such a site to send these emails. After all, that’s some lonely script kiddie in their mom’s basement BS. This had to be phishing.

One last check. I did a dig on verify.domain.com and compare that to the www for the company. Two very different IP spaces, but crucially the nameservers have “dyn” in the name which red flagged that it was one of those dynamic DNS services so it could be anything anywhere. Definitely not legitimate.

So I go to the registrar’s site to report this phishing and look at my domain’s record to see if anything really had changed. It had not, but I noticed there was a phone number I’ve not used since 2003, so I update the record. There is a notice that they need me to verify the information. I go looking for it and see… another copy of the phishing email at the time I updated the record. At this point, I suspect maybe I am completely wrong. Since the risk seems low, I do click the link and verify button and go back to the registrar’s site to see if the warning about needing to verify my information cleared. It did. Dammit!

Turns out the phishy email is actually ICANN not the registrar.