Doug Lhotka

Technical Storyteller

  • Home
  • Cybersecurity
  • State of Security
  • Photography
  • 3D Modeling & Printing
  • About

Opinions and commentary are mine, and do not reflect those of my employer.

(C) Copyright 2019-2023
Doug Lhotka.
All Rights Reserved.
Use of text, images, or other content on this website in generative AI or other machine learning is prohibited.

SSN is not a secret (and never was)

September 11, 2017 By Doug

(c) Depositphotos / johnkwan

With the Equifax breach, there’s been a lot of commentary about it’s impact, and much of it has one important fact wrong:  SSN was never intended to be a secret.

I’ve written in more detail about this before, but in light of the recent breach, I thought I’d repost it again.  One update, before I get to the original post:  At this point, between Anthem, Equifax, and the others, we should all assume that SSN is no longer secret.  For consumers, that means a credit freeze (where you do establish a secret PIN to unlock the reports).  For businesses, I’ll just say this.  Enough.  Seriously, enough.  Across the board you need to stop using it to authenticate people.  Today.  Unfortunately I think they’re largely too lazy to do it without legislation.

Here’s the original post from January 10th, 2016:

The Social Security Number is the Achilles heel of modern information. It was never intended to be used for identification purposes – in fact, my original card has that printed in big bold red letters right across the front of it.

Well, that didn’t work out well. In college, SSN was our student number. Printed on our ID, posted outside the professor’s office with our grades, and on our transcripts. Medicare and Medicaid members have it printed on their cards. Insurance companies have adopted it and print it on their cards. Financial firms use it not only for tax purposes, but also some as account numbers. It was used in a hundred other ways. And everyone uses it to authenticate their customers, which is the worst of all.

But it’s not a secret!   For the majority of people, given their birthdate and location (did you put real ones on social media?), you can guess their SSN within a few tries. We use it because it’s easy, and the closest thing we have to a national ID number (note – I’m not advocating one).   Even in the face of massive data breaches – 80 million SSN’s in just one (that’s 1 in 5 SSN’s exposed) folks continue to use it. It’s easy, it’s convenient, everyone does it, people remember it – it works.

And it’s dumb.

Let me explain some terminology before continuing, and use an example to help folks understand. We’re going to login to our bank so we can do some online transactions in two steps.

  • We assert our identity – in other words we claim to be someone. That’s the login ID – or identification credential. ID is not a secret.
  • We prove our identity – authenticate our assertion, usually by password, or sometimes by two-factor authentication. Authentication uses a secret (the something you know, are, or have) to prove that you are who you claim to be.

SSN is an identifier – something we use to assert who we are. It’s not a secret, has never been a secret, and we can’t turn it into a secret.   It’s time to stop trying.

The problem is that SSN is being used as an authenticator – a secret that proves that I am who I say I am. It doesn’t matter if we use the last four, or the whole number. Using SSN to prove identity is like leaving the sticker with the combination on the back of the padlock.

So we’re in a mess, and there’s no real easy way out. But here’s some thoughts on ways to start.

First the IRS should implement a PIN system for SSN – for everyone. This PIN should be randomly generated to avoid people choosing birthdates or other easily discoverable information, and yes, resetting it probably should require a trip to the local social security office with documents that prove identity, including a government issued picture ID. Most states will already issue ID’s at no charge to folks that can’t afford them.  Yes, we’re in a bit of a circular situation here because bills and such are used to provide identity and residency, but it’s the best we’ve got. The SSN/PIN system should support two-factor authentication that’s used for things like filing a tax return.

Oh shoot, we’re into national ID territory. Given the recent track record of breaches within the US government, there’s legitimate concern about having all our eggs in one basket. What happens if the next data disclosure is the entire IRS taxpayer database?

So here’s the controversial proposal. Congress should pass legislation limiting the use of the SSN to the IRS only – prohibit commercial use as an identifier, and ban all use as an authenticator. Medicare and Medicaid would be required to move away from SSN (except for ACA compliance) and issue separate identity and authentication tokens to it’s members.

That means that your bank would still have it so they can file your 1099’s, but they’d be prohibited from using it for anything else – and they would not have your authentication information! TurboTax and the like would be able to use the SSN/PIN combination to file returns, but would not store PIN information (the IRS would provide a web service to validate authentication for known-good actors). Insurance companies would have SSN to forward coverage to the IRS for Affordable Care Act (Obamacare) compliance, but would be prohibited from using it for anything else. That means that your local doctor’s office would never need SSN at all – which is a major reduction in the points of failure.

Credit bureaus are going to have a challenge. They will need to develop some sort of identification system themselves. The good news is that most of it is in place – when you get a credit freeze, they issue you a secret authentication token. You use that to unlock credit when you want someone to be able to get a copy of your report. We should grant them antitrust immunity so they can jointly develop a Credit Identification Number system to replace SSN for their use, and then issue that – and an authentication code – to everyone in the database, and retire SSN from use.

It’s a lot of work, it’s not cheap to do, and there’s a ton of details and nuances (like not allowing easy-to-guess security questions as part of an authentication reset system) that have to be worked out.    But with at least 1 in 5 SSN’s is already exposed [Edited – essentially all SSN’s as of 9/2017], it’s long past time to do the hard work.

Filed Under: Security Tagged With: data breach, equifax, personal, security, social security number, ssn

Equifax Breach – Have you frozen your credit yet?

September 7, 2017 By Doug

I don’t usually do breaking news, but this one could be significant.  Equifax, the US credit reporting agency is saying that up to 143 million records could have been disclosed.  This happened on July 29th, and was just disclosed today.

They state that core credit report databases were not breached (which would be a massive problem), but that PII, including social security numbers were likely exposed.  They’re executing the typical ‘one year of credit monitoring’ playbook that I wrote about in June and my advice still stands:  get a freeze instead.

If you haven’t frozen your credit – and your kids – now would be an excellent time to do it:  instructions here.

Filed Under: Security Tagged With: credit freeze, credit monitoring, data breach, equifax, security

The Problem of Android

August 28, 2017 By Doug

(c) Depositphotos / @abidal

I’m an Apple guy, and have a love-hate relationship with their recent product strategy, and the tight control they keep over the ecosystem.  The downside is that we’re stuck with some bad decisions (like building apps that expect to be online all the time), but the upside is that everyone gets access to updates at the same time – Apple has the most up-to-date user base of any major computing platform.  Android, not so much.

Android took the opposite approach – open code base, licensed to manufacturers to customize, and then further customized by carriers.  The advantage to that is lower cost and wider adoption, but it comes at a significant price for security.  When Google releases a new version of Android, only their own devices immediately receive the patch.  Everyone else has to wait for 1) the manufacturer to test, certify, and release the patch, and then 2) the carrier to do the same.   That assumes of course, that both actually bother to do the work to make updates available.  The net is that the vast majority of Android devices are running known-insecure versions of the OS.

I’m seeing a broad movement among businesses to tighten controls over mobile OS versions, and to apply the same policies to both corporate owned and BYOD devices:  If you’re not N or N-1, you can’t use your device.  That means that those old iPhone 4’s get retired too, by the way.

So what to do?  Well, some would say ‘jailbreak’ and install your own code.  There may be something to that, but you run into serious risks there too.  Most jailbreaking tools are from the shady side of the internet, so you never really know what you get.  Most companies block jailbroken devices from business use (all really should).  It’s also technically beyond most users, so let’s leave that off the table.

The next option is to only purchase devices that get updates directly from Google.  That limits choices significantly, but as a side benefit, you don’t get the pre-installed spyware that comes with many of the dirt cheap android phones – that’s how those companies subsidize the phone.  Buyer beware.    This is a hard choice for businesses because it largely erases one of the advantages of Android over iOS (cost), but it’s one I’m seeing a number of organizations do.  For individuals who buy Android devices, it’s the one I’d recommend.

Next is to buy cheap devices, and simply dispose of them when the OS expires.  That’s all well and good, but it’s expensive, time consuming, and you have a window of vulnerability during the transition.  Of course, banning Android completely is an option too, and I do see some of that happening.

But the most common approach I see these days is some form of risk limiting via containerization, or other restrictions on what the devices are allowed to do.  Containers can be bypassed (e.g. compromise the underlying device with a keylogger), but do provide reasonable protection for moderate risk content.  Organizations should leverage their data classification projects to determine what information is suitable for mobile device access, and potentially change that based on how current the OS is.

I know this challenge is top of mind for Google’s Android team, and they’re starting to look at separating the Carrier bloatware layer from the underlying OS as well as other measures to speed up manufacturer release.  I hope they succeed – we need an alternative to keep Apple on their toes.  In parallel, consumers shouldn’t buy devices without clear statements of patch release timelines from vendors and carriers.  Until all that happens, and we have a better option, Android users beware.

Filed Under: Security Tagged With: android, apple, google, ios, mobile, patch, phone, security, update

  • « Previous Page
  • 1
  • …
  • 12
  • 13
  • 14
  • 15
  • 16
  • …
  • 24
  • Next Page »

Cybersecurity

Photography

3D Modeling & Printing

Recent Posts

  • Cabin Ruins in Montana
  • Grand Canyon HDR
  • Grand Canyon First View
  • Grand (foggy) Prismatic Spring
  • Sunny Day at Grotto Geyser