The Daily Parker

Politics, Weather, Photography, and the Dog

How to protect your data from being stolen

Sadly, you can't. But you can protect yourself from identity theft, as Bruce Schneier explains:

The reality is that your sensitive data has likely already been stolen, multiple times. Cybercriminals have your credit card information. They have your social security number and your mother's maiden name. They have your address and phone number. They obtained the data by hacking any one of the hundreds of companies you entrust with the data­ -- and you have no visibility into those companies' security practices, and no recourse when they lose your data.

Given this, your best option is to turn your efforts toward trying to make sure that your data isn't used against you. Enable two-factor authentication for all important accounts whenever possible. Don't reuse passwords for anything important -- ­and get a password manager to remember them all.

Do your best to disable the "secret questions" and other backup authentication mechanisms companies use when you forget your password­ -- those are invariably insecure. Watch your credit reports and your bank accounts for suspicious activity. Set up credit freezes with the major credit bureaus. Be wary of email and phone calls you get from people purporting to be from companies you do business with.

At the very least, download a password safe (like the one Schneier himself helped write) and make sure that you use a different, random password for everything.

Azure DNS failure causes widespread outage

Yesterday, Microsoft made an error making a nameserver delegation chage (where they switch computers for their internal address book), causing large swaths of Azure to lose track of itself:

Summary of impact: Between 19:43 and 22:35 UTC on 02 May 2019, customers may have experienced intermittent connectivity issues with Azure and other Microsoft services (including M365, Dynamics, DevOps, etc). Most services were recovered by 21:30 UTC with the remaining recovered by 22:35 UTC. 

Preliminary root cause: Engineers identified the underlying root cause as a nameserver delegation change affecting DNS resolution and resulting in downstream impact to Compute, Storage, App Service, AAD, and SQL Database services. During the migration of a legacy DNS system to Azure DNS, some domains for Microsoft services were incorrectly updated. No customer DNS records were impacted during this incident, and the availability of Azure DNS remained at 100% throughout the incident. The problem impacted only records for Microsoft services.

Mitigation: To mitigate, engineers corrected the nameserver delegation issue. Applications and services that accessed the incorrectly configured domains may have cached the incorrect information, leading to a longer restoration time until their cached information expired.

Next steps: Engineers will continue to investigate to establish the full root cause and prevent future occurrences. A detailed RCA will be provided within approximately 72 hours.

If you tried to get to the Daily Parker yesterday afternoon Chicago time, you might have gotten nothing, or gotten the whole blog. All I know is I spent half an hour tracking it down from my end before Microsoft copped to the problem.

That's not a criticism of Microsoft. In fact, they're a lot more transparent about problems like this than most other organizations. And having spent a lot of time trying to figure out why something has broken, half an hour doesn't seem like a lot of time.

So, bad for Microsoft that they tanked their entire universe with a misconfigured DNS server. Good for them that they fixed it completely in just over an hour.

Quick links

The day after a 3-day, 3-flight weekend doesn't usually make it into the top-10 productive days of my life. Like today for instance.

So here are some things I'm too lazy to write more about today:

Now, to write tomorrow's A-to-Z entry...

Two on data security

First, Bruce Schneier takes a look at Facebook's privacy shift:

There is ample reason to question Zuckerberg's pronouncement: The company has made -- and broken -- many privacy promises over the years. And if you read his 3,000-word post carefully, Zuckerberg says nothing about changing Facebook's surveillance capitalism business model. All the post discusses is making private chats more central to the company, which seems to be a play for increased market dominance and to counter the Chinese company WeChat.

We don't expect Facebook to abandon its advertising business model, relent in its push for monopolistic dominance, or fundamentally alter its social networking platforms. But the company can give users important privacy protections and controls without abandoning surveillance capitalism. While some of these changes will reduce profits in the short term, we hope Facebook's leadership realizes that they are in the best long-term interest of the company.

Facebook talks about community and bringing people together. These are admirable goals, and there's plenty of value (and profit) in having a sustainable platform for connecting people. But as long as the most important measure of success is short-term profit, doing things that help strengthen communities will fall by the wayside. Surveillance, which allows individually targeted advertising, will be prioritized over user privacy. Outrage, which drives engagement, will be prioritized over feelings of belonging. And corporate secrecy, which allows Facebook to evade both regulators and its users, will be prioritized over societal oversight. If Facebook now truly believes that these latter options are critical to its long-term success as a company, we welcome the changes that are forthcoming.

And Cory Doctorow describes a critical flaw in Switzerland's e-voting system:

[E]-voting is a terrible idea and the general consensus among security experts who don't work for e-voting vendors is that it shouldn't be attempted, but if you put out an RFP for magic beans, someone will always show up to sell you magic beans, whether or not magic beans exist.

The belief that companies can be trusted with this power [to fix security defects while preventing people from disclosing them] defies all logic, but it persists. Someone found Swiss Post's embrace of the idea too odious to bear, and they leaked the source code that Swiss Post had shared under its nondisclosure terms, and then an international team of some of the world's top security experts (including some of our favorites, like Matthew Green) set about analyzing that code, and (as every security expert who doesn't work for an e-voting company has predicted since the beginning of time), they found an incredibly powerful bug that would allow a single untrusted party at Swiss Post to undetectably alter the election results.

You might be thinking, "Well, what is the big deal? If you don't trust the people administering an election, you can't trust the election's outcome, right?" Not really: we design election systems so that multiple, uncoordinated people all act as checks and balances on each other. To suborn a well-run election takes massive coordination at many polling- and counting-places, as well as independent scrutineers from different political parties, as well as outside observers, etc.

And even other insecure e-voting systems like the ones in the USA are not this bad: they decentralized, and would-be vote-riggers would have to compromise many systems, all around the nation, in each poll that they wanted to alter. But Swiss Post's defect allows a single party to alter all the polling data, and subvert all the audit systems. As Matthew Green told Motherboard: "I don’t think this was deliberate. However, if I set out to design a backdoor that allowed someone to compromise the election, it would look exactly like this."

Switzerland is going ahead with the election anyway, because that's what people do when they're called out on stupidity.

Weekend reading list

Just a few things I'm reading that you also might want to read:

And finally, it's getting close to April and the Blogging A-to-Z Challenge. Stay tuned.

The last moments of winter

Today actually had a lot of news, not all of which I've read yet:

And now, good night to February.

Lunchtime reading

I had these lined up to read at lunchtime:

Meanwhile, for only the second time in four weeks, we can see sun outside the office windows:

Messing with the wrong guy

A telephone scam artist is going to prison after picking precisely the wrong victim:

Keniel Thomas, 29, from Jamaica, pleaded guilty in October to interstate communication with the intent to extort, federal authorities said.

He was sentenced to 71 months in prison last week by U.S. District Court Judge Beryl A. Howell in Washington, D.C., and will be deported after he has served his term, officials said.

Thomas made his first call to [William] Webster, 94, on June 9, 2014, identifying himself as David Morgan. He said that he was the head of the Mega Millions lottery and that Webster was the winner of $15.5 million and a 2014 Mercedes Benz, according to court documents.

Little did Thomas know that he was targeting the man who had served as director of the FBI and then the CIA under Presidents Jimmy Carter and Ronald Reagan.

Usually Webster just ignores these idiots, but apparently Thomas behaved particularly egregiously, even threatening Webster's wife. So basically Thomas will spend almost 6 years in prison because he's a stupid schmuck.

Still, it's nice to send one of those bastards to jail.

My next side-trip from London

...will be to Bletchley Park:

The National Museum of Computing is a must-see if you are ever in the UK. It was a short 30ish minute train ride up from London. We spent the whole afternoon there.

There is a rebuild of the Colossus, the the world's first electronic computer. It had a single purpose: to help decipher the Lorenz-encrypted (Tunny) messages between Hitler and his generals during World War II. The Colossus Gallery housing the rebuild of Colossus tells that remarkable story.

We saw the Turing-Welchman Bombe machine, an electro-mechanical device used to break Enigma-enciphered messages about enemy military operations during the Second World War. They offer guided tours (recommended as the volunteers have encyclopedic knowledge) and we were able to encrypt a message with the German Enigma (there's a 90 second video I made, here) and decrypt it with the Bombe, which is effectively 12 Engimas working in parallel, backwards.

I wanted to understand the computing power these systems had then, and now. Check out the website where you can learn about the OctaPi - a Raspberry Pi array of eight Pis working together to brute-force Engima. You can make your own here!

Yes, there's a Raspberry Pi Enigma-cracker. If only we'd had one in 1940...

Transitioning to a new environment in 15 easy steps

As readers have inferred, I've started a new position (more later), and with that I've got to set up a new work computer. I say "computer," but it's actually a MacBook Pro. All of my everything lives in the Microsoft universe. This has caused a slight problem trying to get access to my new company's source code in GitHub.

See, I've used Password Safe for years to manage all my passwords. By "all" I mean that I follow the standard industry practice of never re-using passwords, and generating strong passwords for each asset. This includes my GitHub account.

Today I finally got my existing GitHub account authorized to access the company's repositories. So all I have to do is log in to my GitHub account, and...wait...crap.

So how do I get my GitHub password? Here are the steps I tried:

  1. My safe file is on OneDrive, so I can get it off my phone and email it to my work address. No problem there.
  2. But PWSafe is a Windows application. There isn't a Mac version available through the same vendor.
  3. There is a Mac version through a different vendor—for $15. OK, let me rule out all the free options first.
  4. Aha! I have a virtual machine sitting in Microsoft Azure that I can spin up. It has access to OneDrive and it has a local copy of PWSafe already installed.
  5. Log into the Microsoft Azure portal.
  6. Spin up VM.
  7. Google how to connect to it from a Mac. (Microsoft has a client available through the iTunes store.)
  8. Go to the App Store on my Mac.
  9. Find the RDP client.
  10. Attempt to install the RDP client.
  11. Dammit. I have to set up a new Apple ID because my personal Apple ID is—you guessed it—in the safe.
  12. Set up a new Apple ID for work.
  13. Actually install the RDP client this time.
  14. Realize that the password for the VM is—you guessed it—in the safe.
  15. Shut down the VM for now.
  16. Jot down a note to add my GitHub account to LastPass so I can get into it from work.
  17. Jot down another note to add my VM credentials to LastPass.
  18. Get more tea.
  19. Blog about this.

Oh well. I have plenty to do this afternoon that doesn't involve writing software.