Doug Lhotka

Technical Storyteller

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.

Hacking Back is a Bad Idea

By

(c) DepositPhotos / @ Hansito

A bill was recently introduced in the US congress that would allow private organizations to ‘hack back’ when attacked. This is a Bad Idea™ that should be quickly put to rest – no good can come of it.

When we’re attacked, spoofed, phished, or just annoyed with junk phone calls, it’s human nature to want to return the favor.  Companies spend large and growing resources on cybersecurity that could better be spend building new and innovative products.  Unfortunately we don’t live in Utopia, and directions there don’t seem to be loaded into our GPS.  So we try to protect our organizations as best we can given resource constraints.   So should we divert a portion of that capability to hack back at attackers?  For private organizations, absolutely not.  Let me explain.

It goes back to the problem of attribution, which I’ve written about in the past.  Our adversaries are well versed in covering their tracks, planting misdirecting evidence, and throwing blame on innocent third parties.  Hacking back is far more likely to inadvertently hit a different victim of the hackers than the actual actors themselves.  Worse, we know the bad guys would use this as a new threat vector.  Rather than attacking company A directly, they’d hack those servers, and use them to hack company B.  When B retaliates against A, they do far more damage than the original hack.  If the two firms are direct competitors, then the only ones who really win in this situation are the bad guys and trial attorneys.  Oh, and on that last point – no legal counsel worth their salt is going to authorize a hack-back by a private entity, regardless of what the law says.

You’ll notice I’ve only talked about private organizations, which leaves law enforcement or national intelligence and defense.  I’m not going to address ethics of ‘stockpiling’ vulnerabilities, but there’s no question that those agencies and the military definitely possess offensive cyber-attack capabilities.  Should those be used on behalf of private organizations?  Only as much as is necessary for attribution and criminal prosecution – and even then, only with appropriate authorization and oversight.

Let’s talk about SSN

By

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, it’s long past time to do the hard work.