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.

Apple, Security, Threat Models and a Tightening Sandbox

June 6, 2017 By Doug

Apple and logo are registered trademarks of Apple, Inc

I watched Apple’s iOS and MacOS keynote with a lot of interest.  Security, privacy, encryption, and two-factor all got some attention, either in the updates or on the main stage – it’s really cool to see a company build a product strategy around those capabilities.

At the same time, they’re removing granular decisions about how that security is implemented.   This dumbing down and forcing people into a very narrow configuration is getting annoying, and is becoming pervasive across their product line.  So when does it become a security risk?  When Apple’s threat model doesn’t match yours.

Let me share a few examples – like what is and isn’t sync’d to the cloud.  I ran into an annoying “feature” when reconfiguring my home network over the weekend – if you sync anything to iCloud keychain (to use HomeKit for example), you sync everything (which is why I don’t use it for passwords).  For example, it’s no longer possible to have a different set of wifi networks on each device.

Another example of this is the fingerprint reader – you can use the fingerprint, or a pin/passcode, but not both.  Now on a phone that’s probably ok, but on a Mac?  It’d be nice to see an option to use a simple PIN and a fingerprint, but Apple’s decided that the risk of fingerprint forgery is small.  Is that your threat model?  Maybe, and maybe not.

We can control application data access on cellular data, but not on wi-fi?  Apple’s threat model is about data usage.  Mine’s about monitoring and tracking (and to be fair, data usage too).    Evidently two-factor will be forced for AppleID logins in iOS 11.  That’s generally good, but I can come up with situations when you’d want to turn it off.  Will it be allowed?  Not sure.

They’re now going to store and sync all your messages via iCloud, not just device to device.  Sure it’s encrypted, but what if I want some data left on one, but not on others?  Again, it’s not hard to come up with some use cases where you’d want more granular control (and yet they still don’t have a “delete all chat’s option”, go figure).

They push their streaming content hard, to the point that the TV app doesn’t work reliably in airplane mode (I’ve had a case open with executive relations for months on this one), which they don’t view as a risk.  I do – to Availability, and I’ve suffered through multiple flights without media as a result.  I’ve been sorely tempted to buy an Android tablet just to have movies when I’m delayed for four hours during a thunderstorm.

Hopefully Siri will get a brain transplant and not just a face lift as HomePod comes out, but the idea of an-always on speaker listening in my house is, well, creepy.  And one with a camera?  I was amused recently when I saw someone with a sticker over their laptop camera….right next to an Echo look.  No thank you.

Apple Pay person to person is interesting, and I’ll be very curious to see how they deal with fraud – or fake allegations thereof.  The QR code integration into the camera is interesting, and I can see fun ways to leverage it – like taking someone to a malware site by posting one on a sign next to a scenic overlook, and titling it ‘Photographic Tips’.

I could go on, but I think I’ve made my point.  Apple’s a remarkable company, and I use many of their products, but their view of users, threat models, and use cases is growing steadily narrower.   It’s still the most secure computing and mobile platform for consumers, but let’s not kid ourselves – there’s tradeoffs to be had.

Filed Under: Security Tagged With: apple, iCloud, privacy, threat model, user security

Let’s talk about SSN

January 10, 2016 By Doug

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.

Filed Under: Security Tagged With: corporations, data security, government, identity, personal, privacy, security policy, small business

  • « Previous Page
  • 1
  • 2
  • 3

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