March 2023 – Observations Along the Road

Ah, 2023. You’ve started out wet and snowy. We needed the water, and you’ve provided it … except perhaps in the areas that feed the Colorado River basin. But being inside has afforded me the time to work on the highway pages. Loads of email from Joel Windmiller was another reason — you’ll find loads of new route adoption and route proposal maps, thanks to Joel. So here are your updates to start the new year:

This update covers January and February 2023. Before we dive into the updates to the California Highways site, an update on the California Highways: Route by Route podcast. Episodes are regularly posted around the middle of the month. You can keep up with the show at the podcast’s forever home at https://www.caroutebyroute.org , the show’s page on anchor.fm, or you can subscribe through your favorite podcaster or via the RSS feeds (CARxR, Anchor.FM) . The following episodes have been posted since the last update:

January | CA RxR 1.07: Highway Numbering: State Highways and Post Miles (featuring an interview with Andy Richardson, a Caltrans retiree and a Subject Matter Expert on GIS and the Post Mile system).
February | CARxR 1.08: Highway Numbering: U.S. Highways (Part I) (no interview; when arranged, that will be Part II)

Turning to the updates to the California Highways pages: Updates were made to the following highways, based on my reading of the (virtual) papers in January and February 2023 (which are posted to the roadgeeking category at the “Observations Along The Road” and to the California Highways Facebook group) as well as any backed up email changes. I also reviewed the the AAroads forum (Ꜳ). This resulted in changes on the following routes, with credit as indicated [my research^(ℱ), contributions of information or leads (via direct mail or ꜲRoads) from Bigmikelakers⁽²⁾, Peter Bryan⁽³⁾, Concrete Bob⁽⁴⁾, Duke87⁽⁵⁾, Tom Fearer⁽⁶⁾, Steve Riner⁽⁷⁾, Chris Sampang⁽⁸⁾, William Sanford⁽⁹⁾, Edward Weiss⁽¹⁰⁾, Joel Windmiller⁽¹¹⁾: Route 1^(ℱ,11,⁸⁾, Route 2⁽¹¹⁾, Route 4⁽⁹⁾, I-5^(ℱ,2,11), Route 9^(ℱ,11), I-10⁽¹¹⁾, Route 12⁽¹¹⁾, Route 14⁽¹¹⁾, I-15⁽¹¹⁾, Route 16⁽¹¹⁾, Route 17⁽¹¹⁾, Route 18⁽¹¹⁾, Route 20⁽¹¹⁾, Route 21^(ℱ,11), Route 24^(ℱ,11), Route 29⁽¹¹⁾, Route 30⁽¹¹⁾, Route 32⁽¹¹⁾, Route 36^(9,11), Route 37^(ℱ,11), Route 38⁽¹¹⁾, Route 39^(ℱ,11), Route 44⁽¹¹⁾, Route 47⁽¹¹⁾, Route 48⁽¹¹⁾, Route 49^(6,11), US 50^(ℱ,11), Route 51⁽¹¹⁾, Route 57^(11,10), Route 58^(ℱ,9), Route 61⁽¹¹⁾, Route 64^(ℱ,11), Route 65⁽¹¹⁾, US 66⁽¹¹⁾, Route 68⁽¹¹⁾, Route 70^(ℱ,9,11), US 70^(ℱ,7), Route 71⁽¹¹⁾, Route 77^(ℱ), Route 78⁽¹¹⁾, I-80^(ℱ,9,11), Route 82^(ℱ), Route 84⁽¹¹⁾, Route 85⁽¹¹⁾, Route 87^(ℱ), Route 88⁽¹¹⁾, Route 89⁽¹¹⁾, Route 90⁽¹¹⁾, Route 91^(ℱ), Route 92⁽¹¹⁾, Route 96⁽⁶⁾, Route 99⁽^ℱ,11), US 101^(ℱ,6,11), I-105⁽¹¹⁾, Route 108^(9,11), Route 113⁽⁴⁾, Route 114⁽¹¹⁾, Route 116⁽¹¹⁾, Route 120^(9,11), Route 121⁽¹¹⁾, Route 126⁽¹¹⁾, Route 128⁽¹¹⁾, Route 132⁽¹¹⁾, Route 138⁽¹¹⁾, Route 141⁽¹¹⁾, LRN 141⁽⁶⁾, Route 142⁽⁶⁾, Route 143⁽¹¹⁾, Route 145⁽¹¹⁾, Route 152⁽¹¹⁾, Route 159⁽⁶⁾, Route 160^(ℱ,11), Route 166⁽¹¹⁾, Route 170⁽¹¹⁾, Route 172⁽¹¹⁾, Route 178⁽¹¹⁾, Route 183⁽¹¹⁾, Route 193⁽¹¹⁾, US 199⁽¹¹⁾, I-210⁽¹¹⁾, Route 237⁽¹¹⁾, Route 245⁽¹¹⁾, Route 250⁽⁶⁾, Route 251⁽¹¹⁾, Route 275^(ℱ), I-280^(ℱ,5,11), Route 299^(9,11), FAI I-305^(ℱ), Route 371⁽³⁾, I-380⁽¹¹⁾, I-405^(2,11), Route 480^(ℱ), I-505⁽¹¹⁾, I-580⁽¹¹⁾, I-605⁽⁶⁾, I-680⁽¹¹⁾, I-710^(ℱ,11), I-880⁽¹¹⁾, I-980^(ℱ), County Sign Route J22⁽⁶⁾, County Sign Route S25^(ℱ). In particular, note the contributions of Joel Windmiller this cycle; Joel contributed loads of route adoption, route proposal, and route rescission maps to the pages.
(Source: private email through 3/5/2023, Highway headline posts through the February Headline post, AARoads through 2/25/2023)

Added links for maps and GIS resources to the main Maps page. Hat tips to Nathan Edgars II (in an email from 2008 that I just got to), as well as the January episode of California Route by Route. Updated the history of Sacramento with a 1958 planning map, courtesy of Joel Windmiller.

Reviewed the Pending Legislation page, based on the California Legislature site, for bills through 2023-02-24. As usual, I recommend to every Californian that they visit the legislative website regularly and see what their legis-critters are doing. As many people are unfamiliar with how the legislature operates (and why there are so many “non-substantive changes” and “gut and amend” bills), I’ve added the legislative calendar to the end of the Pending Legislation page. This is the start of a new legislative session, so at this point mostly bills are being introduced. Welcome to the 2023-2024 session, folks.

Reviewed the online agenda of the California Coastal Commission. There was no January meeting, and no items of interest from the February meeting.

I checked California Transportation Commission page for the results of the January 2023 meeting of the California Transportation Commission. As always, note that I tend not to track items that do not impact these pages — i.e., pavement rehabilitation or replacement, landscaping, drainage, culverts, roadside facilities, charging stations, or other things that do not impact the routing or history, unless they are really significant. As such, the following items were of interest:

I haven’t written a real blog post in a long time, but this one is floating around in my head and insisting to come out.

For the last few months, I’ve been following closely the breach that occurred at Lastpass. You may have heard about it. It’s been all over the technical news feeds, with lots of fear, uncertainty and distrust. It was of particular interest to me, as a long time Lastpass user. These articles make it sound like Lastpass is the most insecure password manager out there. They advise everyone that their “vaults have been stolen” (not making clear it was the encrypted vaults, and the purpose of encryption is to protect information if it does get stolen). They advise everyone to change every password. They advise people to run screaming away from Lastpass to other password managers.

Their tone strikes me as off. It reminds me of the days when everyone piled on Microsoft for what we later learned was probably no good reason, for Microsoft had been moving in the right direction. Their tone — to me — sounds like risk-adverse panic. They are scaring people away from this product because of a risk that really isn’t as bad as they make it out to be. There are times I wonder if there is an agenda behind those articles (and my mind even wonders at some times if a competing password manager wasn’t behind the attack — after all, you don’t have to do anything with the vaults to damage the market leader — the attack is sufficient).

I’ve read the latest blog post from Lastpass closely. I suggest that you do as well. Here’s what I take away from it.

First, this wasn’t a flaw in the product. The flaw — as it is so commonly — was on the human side. Social engineering was used to attack an employee’s home computer, and that employee hadn’t adequately patched their home computer. This is quite common, and to expect perfection in how people maintain their home machines is wrong. It also seems clear that this employee — and Lastpass itself — was targeted by an adversary. That tells me this wasn’t a typical “scoop up the data and sell it”. This was a targeted spearphishing attack, likely with some specific vaults in mind. That’s evident in how the attack went down, and the fact that the data exfiltrated hasn’t shown up elsewhere. For all we know, this was a government adversary targeting a specific individual they learned had a vault.

ETA: Could the breach have been stopped with a product patch? Possibly. But remember here that the attack was on a home computer, not a work machine managed by LogMeIn. On your home computer, do you install every patch on every third-party product? Most people don’t. There’s some hygiene and education to be done here, but it isn’t a product flaw.

The takeaways from this, for me, are:

The product is not inherently flawed. It uses a reasonable scheme to protect the vaults, and suffers from the same risks that any product that stores stuff in the cloud faces. The vaults are protected with a strength commensurate with the user chosen master password and iteration count.
The nature of the attack is something that could happen at any password manager product: targeting developers at home. That’s even true for open source products: open source products may still store user data in the cloud, and that data can be compromised.
Corporate training may be weak, but corporate training overall is weak, and people are often the weakest part in any company.
This was targeted attack. If you are a high-value target, I’d be worried. If you are the run of the mill user, I’d be much less worried. It is likely not worth the adversaries effort to attempt to decrypt your vault.

Second, should you change all your passwords? I think the clear answer here is “no”, not all. If you choose to change anything, you should make your determination based on what the password is protecting. Is it a bank or something vital, such as your domain configurations or DNS? Is it your social security account? Is it your email account? Change it. But you should be changing those passwords on a regular basis anyway, and enable MFA. But is the password for something like Slice or Lands End or Disqus. I wouldn’t worry. So they order a pizza on a credit card number they can’t see. You dispute the charge, unless they delivered it to you and you enjoyed it. The risk isn’t there. I’d venture you would only need to change about 20% of your passwords, if you have as many throwaway accounts as I do.

This, of course, is presuming you follow best practices. Create a unique account for each site; don’t rely on your Google or FB login. Have strong unique passwords for every site. Enable MFA where you can. These are all best practices you should know if you’ve been trained. You’re not that weak link, are you?

But do you need to change your passwords? The answer here is: it depends on you and your comfort level. They’ve already got the encrypted vaults. At minimum, you should change your vault master password to something long and strong (I recommend using xkpasswd or the pronounceable password generator and doing further conditioning), change the number of iterations to 600,000, and if you are using MFA, change the randomization seed. Details are in the Lastpass bulletin, and simply provide additional protection going forward. Should you be worried about what was stolen? I’d worry about adversaries using the non-encrypted information for phishing, so be extra careful with texts and emails (but then again, I believe that most of the data scraping attacks are collecting information for spearphishing, as it is easier to convince you to give me the data than to attempt to brute force it. See this XKCD). If you had a really weak master password and low iterations, change your key passwords and look for indications of attack. But remember: you’re likely not the target.

The takeaways here are:

You don’t need to change all your passwords
Change your vault passwords, iterations, and MFA seed on general principles.
If you had a weak master password, change key passwords protecting financial institutions, major accounts (email, FB), and DNS/domain related accounts.
Take a deep breath.

Third, do you need to run screaming away from Lastpass? Again, that depends on your comfort level. Although their latest communication was good and detailed, they sucked on communication up to this. I attribute that partially to timing, as they were being divested away from LogMeIn and that introduces a certain chaos in corporate communications. But they were also probably holding things close to the vest until they improved processes. Reading their longer term plans, I think they are significantly improving things and so their update product will be more secure. They are certainly retraining their development team. I particularly noted “Working to encrypt URL and URL-related fields in the vault BLOBs.” That’s a good thing.

Moving away from Lastpass has certain costs. There is the friction in moving the vaults (and moving your vault does nothing to protect you from this breach, as the general user information and encrypted vault data was already stolen). Arguably, it puts your data in more places to be stolen, as it doesn’t delete data from backups and such. There are also usability issues (Lastpass is an extremely easy to use product), and with the paid product, the features of the Family plan were excellent.

The takeaways here are:

Lastpass sucked at communication during the process, but has now finally given good details. They lost trust due to how they handled this, which is a lesson we all should learn from.
The improvements they have made, and are making, are good and increases confidence in their product.
They could do more: increased training of employees, increased emphasis on awareness, and increased practical exercises on recognizing phishing are key. Increased restrictions on what computers can connect to them, combined with techniques to ensure those computers are configured properly. Those may be coming, or perhaps they weren’t explicitly mentioned.
Every user should balance their risk tolerance with their likelihood as a target and the value of the information being protected. Be realistic, and understand the frictional costs in moving platforms.

Am I going to abandon Lastpass? Probably not. But I have changed master passwords, increased iterations, and updated MFA seeds. I’ve also changed passwords on critical accounts, and enabled MFA in more places (using an authenticator app instead of SMS when I can). I’m also keeping an eye out for any anomalous activity, but then again, I always do that.

Month: March 2023

🛣 Changes to the California Highway Website covering January-February 2023

🗯️ Thoughts on a Breach