Chaos Lever Podcast

 Ah, passwords—the not-so-secret keys to our digital world. In this episode, we dig into the fascinating (and flawed) history of passwords, from their Roman origins to their debut in 1960s computing, and the constant struggle between ease and security ever since. Why are we still relying on passwords that can be hacked in seconds? And what are the latest recommendations from the National Institute of Standards and Technology (NIST) to make our digital identities safer?

Join us as we cover: 

🔒 How passwords began, and why they’re so easily abused 
🔒 The hilarious and painful ways users circumvent complex password rules 
🔒 NIST's latest guidelines for making passwords simpler yet safer 
🔒 The growing importance of passkeys, MFA, and password managers 
🔒 Alternatives to passwords that may finally lead to better security for all 

If you’re tired of juggling endless passwords or getting locked out because you can’t remember your “favorite childhood pet,” this is the episode for you. 

Links: 
  • https://www.wired.com/2012/01/computer-password/
  • https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/
  • https://www.nytimes.com/1981/07/26/business/case-of-the-purloined-password.html 
  • https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub112.pdf 
  • https://neal.fun/password-game/ 
  • https://pages.nist.gov/800-63-4/sp800-63b.html#password 

What is Chaos Lever Podcast?

Chaos Lever examines emerging trends and new technology for the enterprise and beyond. Hosts Ned Bellavance and Chris Hayner examine the tech landscape through a skeptical lens based on over 40 combined years in the industry. Are we all doomed? Yes. Will the apocalypse be streamed on TikTok? Probably. Does Joni still love Chachi? Decidedly not.

[01:00:00.000]
Chris: The correct answer is they were actually hiding on Mars.

[01:00:03.840]
Ned: That would actually be interesting.

[01:00:07.520]
Chris: They weren't writing any new music, though.

[01:00:09.700]
Ned: They were struggling to breathe, really.

[01:00:13.670]
Chris: Which actually, if I were to do an album, I think that might be the title.

[01:00:28.850]
Ned: Hello, a legend human. And welcome to the Chaos Lover podcast. My name is Ned, and I'm definitely not a robot. I'm a real human person who has difficulty remembering 64 character passcodes and can't just store private keys in my head that are unreachable by outside influences. That's a strange thing that you would assume that I could do, all of those things. With me is Chris, who's also here. Hi.

[01:00:57.490]
Chris: What's your password?

[01:00:59.480]
Ned: Oh, good. I see you've read ahead. Really not going to make it mysterious for the people, are you?

[01:01:11.190]
Chris: What's a mysterious?

[01:01:13.040]
Ned: Oh, now you're just being in it.

[01:01:17.260]
Chris: Look, I found my word of the day calendar to be very ingreciating and avuncular.

[01:01:27.680]
Ned: Nobody knows what avuncular means. Nobody.

[01:01:31.570]
Chris: Longitudinal.

[01:01:33.540]
Ned: Longitudinal? No, I think what you meant was orthogonal.

[01:01:38.140]
Chris: Mirepoix.

[01:01:39.310]
Ned: Now you're just talking nonsense. What is that? Like stuff you put in a bowl to make the room smell good?

[01:01:48.370]
Chris: It's one of two things.

[01:01:50.180]
Ned: Okay.

[01:01:50.970]
Chris: One, I made it up. Or two, it's the standard mix of, I think it's peppers, onions, and mushrooms that you cut up to make a for a soup?

[01:02:02.040]
Ned: I don't think mushrooms are involved, but I think you're close. I think it's carrots, onions, and celery. Carrots.

[01:02:08.490]
Chris: That's like a mushroom in a number of important ways.

[01:02:11.910]
Ned: Like zero. Zero is important. Without it, we wouldn't have modern math. So yes, I guess in that regard, you are correct. Should we quickly move on to something else?

[01:02:24.190]
Chris: Yeah, unless you want to talk about how zero might not actually be a number. Oh.

[01:02:30.660]
Ned: Oh, no. No, let's not do that. Poor people listening. I'm so sorry. Today, we're going to talk about the evolution of passwords in the future of digital security, but mostly about passwords. Hey, that title would actually make a pretty decent password on its own. If you just type that whole thing in, I mean, it'd take a while, but it would be really strong.

[01:02:53.990]
Chris: I'd throw an exclamation point at the end.

[01:02:57.030]
Ned: Shut up. That's stupid, and I'll explain why secure. The humble password. Our default way of providing... Proving? Words. Proving our identity. One that is deeply flawed and should be abandoned as soon possible, but it won't. You know why it won't, Chris?

[01:03:19.760]
Chris: I'm guessing you're going to tell me.

[01:03:21.560]
Ned: I mean, one would hope so. Because it's easy. And easy will always triumph over secure. True. And since we're stuck with passwords, for now, I thought it might be interesting to review the latest recommendations that have come out of the National Institute for Standards and Technology, also known as NIST.

[01:03:43.560]
Chris: And that's We're all we're going to call it from here on out because it's way less syllabus.

[01:03:48.290]
Ned: It's actually a nice acronym. It's one I don't mind saying. Nist provides guidance for the US government when it comes to the technology standards that the government must adhere to. The systems that government employees interact with. Nist tells them, These are the standards. Now, that has a trickle-down effect on systems that government employees interact with that are from the private sector because they also have to adhere to this stuff. Since the US government is the largest employer in the country with almost 3 million employees, that's a lot of trickle-down. Unlike, trickle-down economics, which should more accurately be titled Rich People Collusion Economics.

[01:04:31.690]
Chris: I'm going to need you to stop saying the word trickle.

[01:04:35.480]
Ned: It's not moist, but it's close. It's moist, Jason. I wish the world could see the faces that you're making.

[01:04:45.040]
Chris: For the best, really.

[01:04:46.690]
Ned: But first, as is our want, our remit, one might say, we're going to spend a little time figuring out how the hell we got here. Why does the password exist? How did it persist? And what else could we be doing? Let's start with the birth of passwords.

[01:05:04.700]
Chris: Wait, this is a PG podcast, so be careful.

[01:05:07.430]
Ned: When two phrases love each other very much. Passwords, you'll be maybe shocked by this, but they predate the 1960s and computer nerds. I mean, it was computer nerds in 1960 that added passwords to computers. But the idea, the concept of a password, or also known as a watchword, as a proof of identity, goes back to at least the Roman times. There's an account from Polybius, Well done. Thank you. That talks about how a set of watchwords was disseminated through the Roman army and rotated on a daily basis. Pretty impressive stuff. The need to prove your identity, or at least your allegiance, was fairly important when it came to military affairs, so passwords continued to be used by military campaigns right up until the present day.

[01:06:11.930]
Chris: Yeah, and that's more or less the history of the word, right? It's a word that you need to know in order to pass.

[01:06:17.380]
Ned: Exactly. So if you were at the Castle moat and you wanted to get in through the drawbridge, they'd call for the password. And if you didn't know it, I guess they'd shoot fire arrows at you. I don't know medieval warfare actually worked.

[01:06:32.880]
Chris: I'm pretty sure they just decapitate you with a live alligator.

[01:06:38.610]
Ned: I love everything about that. I'm going to put that in the ChatGipody later. In terms of computing, The lure is that the first passwords were used at MIT on their CTSS mainframe. That was the compatible time sharing system. The system in question needed to support multiple users, and each user was given a time slice of the computer to run their jobs. Each user had a set of private files on the system, and they were given a password to log in, access their files, and run their jobs. Almost immediately, the system was compromised. No one checked.

[01:07:19.010]
Chris: It was the '60s. That's the only reason that it was almost immediately. Yeah.

[01:07:24.700]
Ned: According to Wired magazine, they the story of Alan Shur, who was a PhD researcher at MIT in 1962. He wanted to get more time to run his jobs. It was a scarce resource, but things were allocated by user. If he logged in as another user, he could use their time slice. But to do that, he'd need their password. After looking at the system for a little bit, he realized that you couldn't open the master password file directly, but you could send it as a print job if you submitted the job using a punch card. That's what he did. He submitted the print job as a punch card and retrieved the list a couple of days later once the job had been processed. He did own up to it 25 years later.

[01:08:21.100]
Chris: What a guy.

[01:08:22.650]
Ned: He also shared it with other people, so he didn't keep it all for himself, but that was really more to spread around the blame if he got caught. Yeah. Not only do we have the first use of passwords on a computer system in 1960, we also have the first abuse of passwords within two years of the system being in place. Humans are truly marvelous creatures, Chris. As computing took off in the '70s, passwords became a staple of multi-user operating systems. However, the accessibility and the number of users passwords, remained relatively low, so password security wasn't as much of a concern. There was no internet, and there was no such thing as remote access. Well, there was, but just barely. Generally speaking, if you wanted to log into a system, you had to be physically present at a terminal that was connected to that system, which meant you probably have already gone through several security checks just to exist there. Then those time sharing systems started to come online, and that all began to change. In 1980, there was a company called NCSS that sold time sharing for compute resources. See, cloud computing has been around since way before 2016, people.

[01:09:46.710]
Ned: They discovered in-What's old is new, and then old, and then new, and then old. It was cool, man, because you could just dial in and use some compute, because you probably didn't have that on your desktop or even in your company. But then computers got smallerer and you could have that in your company. A lot of these time shares companies went bankrupt.

[01:10:10.780]
Chris: What's old is new, is old as... Well, now they would be too big to fail.

[01:10:17.060]
Ned: Unfortunately. In 1980, NCSS discovered that their directory service had been hacked and their files, their directories, had been copied to systems outside of the company. Based on reporting from the New York Times, it seems that the incident was more of a prank by hackers than any actual ill intent. But the article goes on to cite internal technicians at NCSS who had written a program called Pilfer that could retrieve the password of any client by subverting security controls in the NCSS operating system.

[01:10:55.450]
Chris: Solid naming. I have to give them that.

[01:10:57.800]
Ned: It's hard to argue with it. One quote from the article stood out to me, and it seems broadly relevant for something from 40 years ago. The Vice President for Advanced Systems at NCSS, Harold Fineleb, said, You really don't know who is on the other end of the line. The only secure computer centers are those without telecommunications.

[01:11:21.860]
Chris: There's only so many times in an episode I can say what's old is new again.

[01:11:25.980]
Ned: I mean, he's close. More accurately, the only secure computer centers are those without power, melted to slag, and ejected into the coronal mass of the sun. But he's on to something. Now that systems were accessible remotely, Virtual security had to match physical security. It was no longer enough to verify people as they walked in the door. You now had to verify those people that were coming in over phone lines. Virtual doors, if you will. And thus began the arms race of complexity. Passwords didn't need to be very long or strong or even ready to get their freak shit on back in the 1980s. But suddenly, someone could start guessing passwords at random from a remote terminal. If your password was Joshua, as in the 1983 classic war games, you were cooked, as the kids say.

[01:12:26.320]
Chris: At the very beginning, something that they didn't even have limits to the amount of tries.

[01:12:34.420]
Ned: Yeah. Seems like an important thing you might want to implement at some point.

[01:12:40.300]
Chris: You got to imagine somebody looked at those logs and was like, well, Eric tried to log in last night 754,000 times, but he logged in fine, so I guess it's good.

[01:12:52.400]
Ned: I like that you think they kept logs because that's adorable.

[01:12:56.710]
Chris: An immediate flow in my plan.

[01:13:00.460]
Ned: The natural solution was not to abandon passwords, but to make them more complex. And thus, we have the first set of recommendations issued by NIST in 1985, called out in the Federal Information Processing Standards, number 112, or FIPS, as the kids say. Well, the kids don't say that. Angry security people say that.

[01:13:25.020]
Chris: That feels better.

[01:13:26.390]
Ned: Yeah. If you're FIPS, I forget what the current FIPS is, like 170 something, you can be like, FIPS 180 compliant, and then you can work with government agencies and stuff. Now, can I just say there's something delightful about reading scanned documents from the 1980s? I found this original public application, and we don't have physical documents anymore. It's all like, shitty Microsoft Word templates with no character at all.

[01:13:54.380]
Chris: And inconsistent formatting.

[01:13:57.800]
Ned: Fips 112 has fucking style. It's got logos, beautiful symbols, a wonderful shade of green that just makes you feel secure. I mean, I could put this thing under my pillow and I would sleep like a goddamn rock.

[01:14:13.120]
Chris: It's an interesting strategy. I should give that a try. I don't think I've had any sleep for 96 hours.

[01:14:19.330]
Ned: Hey, go get a copy of FIPS 112 and boom, out like a light. It opens with a bit of shade, and I just appreciate this. This standard recognizes that passwords are not the only method of personal authentication, nor does it endorse the use of passwords as the best method. However, it recognizes that passwords are widely used in computer systems and networks for these purposes. Just right out of the gate, they're like, Passwords suck, but we're stuck with them.

[01:14:54.760]
Chris: You dumb fucks are going to do this, whether we like it or not. So fine.

[01:15:01.750]
Ned: I am so sad to tell them that we have barely moved the bar in four decades. The document goes on to outline 10 factors for passwords, including composition, length, lifetime, entry, storage, and transmission. There's a few more, but I'm not just going to read the document to you. I want you to have the pleasure of reading it yourself. But there are some pertinent highlights. According For this, for this to NIST, passwords must be at least four characters in length and support 10 to the fourth possible combinations at a minimum. The policy should be adjusted based on the sensitivity of the data in the system. Now, They settle on eight characters as an acceptable length for most purposes. But the reason they included four, a minimum of four, was because sometimes they were also talking about pins. Usually, your pin is four characters. Next, the password should be changed at least once a year and as often as is practically possible. Compromised passwords should be changed within one day. That's seemingly sensible advice. Passwords should be composed of a minimum of 10 characters to accommodate pinpads that only have the numbers zero through nine on it.

[01:16:26.300]
Ned: This is not how long they should be. It's just the number of characters you have to choose from. The recommended character set is the 95 character ASCII-based graphical set. That's the characters you can actually see, not like the control characters. That includes letters, numbers, and most of the special characters. And finally, the maximum number of password entry attempts is up to the security officer. Like you said, Chris, they recognize that someone just entering passwords an infinite number of times is probably something that you shouldn't allow, but they don't set a limit on what is an acceptable number.

[01:17:07.260]
Chris: I think most people ended up with five.

[01:17:10.940]
Ned: Yeah. Somewhere in that neighborhood, yeah. They also provide an appendix with recommendations for systems that are of different security levels. I looked at the highest security level, the high protection requirements. Those recommended eight character passwords using that full 95 character set generated by an automated system, not picked by a human, with a lifetime of one month for the password. I think what's interesting in that is really that they recommended that it be generated by an automated system and not chosen by a person because a person is going to choose a shitty password like Joshua or something along those lines, whereas a machine is just going to give you a random string of eight characters.

[01:17:58.070]
Chris: It won't end up just being the word password.

[01:18:01.160]
Ned: Not usually, which ironically is eight characters. Now, those recommendations might have been fine in 1985, but an eight-character password today can be cracked in less time than it takes for me to say this sentence. That would be by a Raspberry Pi Model B.

[01:18:19.090]
Chris: That's the lame one, I think. I actually haven't been keeping up.

[01:18:22.920]
Ned: There was a Model A, but we're not even going to talk about that. Nist continues to update their password policies as computers computing power increases and users become theoretically more sophisticated, and attackers, they absolutely do.

[01:18:38.350]
Chris: Don't forget about downloadable scriptlets. Those exist and help even if you're only theoretically sophisticated.

[01:18:46.880]
Ned: I'll touch on that in a moment. We started this arms race, and then it really accelerated because the internet ruins everything. Part 12, The Ruination. If time-sharing computers in the 1980s already had problems, things were poised to get a lot worse when the modern internet rolled out. Not the modem Internet, though that was part of it, the modern Internet. That's due to what I see as four main problems. Chris, you may have some additional problems you want to throw in there. But the four I came up with are access from anywhere, a total lack of federation, increased computing power, and the distribution of lists.

[01:19:27.360]
Chris: This is your list of problems with the Internet?

[01:19:29.860]
Ned: Passwords, but Internet, too, yes.

[01:19:34.010]
Chris: Because the most important one is probably the people on it.

[01:19:38.060]
Ned: I didn't include that. You're the problem. I know. Access from anywhere. With those time sharing systems, you still needed a modem to dial into the service, which was not a common thing for most people to have in the '80s or even in the '90s. You also needed to know the phone to dial into, which was not necessarily public knowledge, and you were limited to connecting to a single system at a time. You dialed to a system directly, it connected you, and then you could try to crack it. The Internet introduced publicly available services with a log on dialog that anyone could access and internet broadband where you weren't limited to accessing a single service at a time, which meant that now anyone could access thousands of websites from anywhere all at the same time. I mean, that is also an aspect that's critical to the success of the internet, but it widened the attack surface tremendously. For web services that required authentication, the simplest thing to do was to implement a username and password system. The thing is, the web services weren't using some federated identity provider, which meant that every stupid website had its own directory service of users that they managed individually.

[01:21:09.990]
Chris: And usually stupidly.

[01:21:12.130]
Ned: Absolutely. Something else happening in Why? Every site you logged into required you to create an account with a username and a password. Chances are that you simply used the exact same username and password for every site. Which means Because if one site has shitty security and accidentally leaks their password database, which they have been storing in clear text for some God forsaken reason, now your password is compromised everywhere. There's no easy way for you to change it everywhere. Fun. Even if your password wasn't hacked, increases in computing power made it economical to run brute force attacks against websites. As long as If your website doesn't rate limit you or block your IP address, you can just try as many combo as you want until it times out. Then try a different username, Rince and Repeat. Sure, you'll probably fail 99% of the time, but 1% of the time you'll succeed. Now you have someone's password that they probably used on every website on the internet. That's the script thing that you were talking about a little bit.

[01:22:26.720]
Chris: Kind of.

[01:22:27.850]
Ned: But wait, there's more because there were also password lists circulating the internet for aspiring young hackers and script kitties to employ. Some of them were stolen from actual services, while others were simply common passwords like password and password1 exclamation point.

[01:22:44.500]
Chris: That's way, way more secure.

[01:22:46.960]
Ned: So much more secure. The problem that we run into is that we already trained non-IT folks to adopt usernames and passwords. So despite the fact that passwords suck, we're stuck with them. So how do we make them better? And before we get into that, is there anything you wanted to add to the problems with passwords on the modern Internet?

[01:23:15.610]
Chris: No. I mean, I think you've got the gist of it. The biggest problem, we go back to the sites having their own databases for where the passwords are stored means that those passwords are going to get relieved of the owner's care, shall we say?

[01:23:32.800]
Ned: Indeed.

[01:23:34.180]
Chris: We've talked about this a bunch of times. I mean, what was it? A few weeks ago, I looked up my own address and it had been involved in 35 breaches, which is actually feels like a low number.

[01:23:44.780]
Ned: Yeah, I was going to say, I would expect it to be higher?

[01:23:48.080]
Chris: That's what happens when you have 35 unique password repositories. Yep.

[01:23:56.240]
Ned: At least one of them is not going to be well protected. Right. Well, before we talk about how we can improve the internet, let's talk about improving the humble password. If we go back to NIST's guidelines from 1985, they had 10 factors that governed passwords. Each of those factors is a chance to improve security. Before we go buck wild and make everyone use 64-character alpha-numeric passwords that rotate every 60 minutes, I want to throw in a little caveat. Security has to balance usability with protection. If you make the system unusable or too onerous, people will simply find a way to circumvent it. Case in point was the tendency at the corporate level to force users to have complex passwords that have to be changed every 30 or 60 days. What do the users do? They write down the password.

[01:24:53.490]
Chris: You were asking me, weren't you?

[01:24:55.040]
Ned: Sure.

[01:24:56.360]
Chris: I saw something shiny in the corner, and I needed to see what it was going to do.

[01:25:00.160]
Ned: Fair. They'd write down the password on a Post-it because it's too hard to remember a complex password.

[01:25:06.090]
Chris: It's okay, though, because that Post-it is super well hidden.

[01:25:10.010]
Ned: I mean, it's definitely not under your keyboard.

[01:25:12.120]
Chris: Not even... What?

[01:25:15.870]
Ned: When it comes time to change the password, they change it to something else and then immediately change it back to the password they already know, or they toggle between two passwords. What is security's response to this? Don't allow them to reuse their last 10 passwords. The user's response, just quickly cycle through 10 passwords to get back to the original and keep using it. Security's response, prevent users from changing passwords more than once a day. User's response, make each successive password similar to the previous one by maybe adding the number of the month to it to make it easier to remember.

[01:25:53.700]
Chris: Or just add a number and that number keeps going up.

[01:25:57.470]
Ned: That too. Security's response, block the use of similar passwords. Ad infinitum. Security keeps making it harder for users to do their job, and users keep finding workarounds to get their shit done. Oh, and the number of legit users that get locked out due to the increasing password restrictions just keeps going up. Ask me how I know as a former help desk person. If you want to see this madness taken to the extreme, I recommend trying the password game that you can find at neal. Fun/password. It is delightful. At one point, it asks you to make sure that the atomic weights of the elements in your password add up to 200. Also, you need to know chess. I personally made it to level 24 before I just gave up. I don't know how many levels there are. I didn't check. But if you want to burn about an hour, go to NIST's updated recommendations try to address the necessary balance between protection and usability. That's what I want to turn to now before we talk about solutions that are not passwords. Hint, there are many and they're all better. Nist's new password recommendations. Those updated recommendations can be found in SP 800-63b, section 3.1.1.2. Got that?

[01:27:30.180]
Ned: There will be a quiz later.

[01:27:31.790]
Chris: I already knew that one.

[01:27:33.660]
Ned: I know you did. The documents use the words shall for what systems must do and should for what NIST recommends as best practice. For clarity, I'm going to adopt that same language. Password.

[01:27:50.010]
Chris: Are you going to say the words shall and should in bold text?

[01:27:53.570]
Ned: In the actual document, they're in all caps, bold text and highlighted with blue. Hard to miss. Again, even though it's not a physical document, I have to admire their style. Well done. Passwords now be... Passwords now shall be at least eight characters and should be at least 15. That's a far cry from 4-8. They should also support being up to 64 characters in length, which, damn. But it seems not too onerous if you're using a password manager.

[01:28:32.570]
Chris: Totally doable. Yeah.

[01:28:34.640]
Ned: The composition of passwords should accept all printing characters in ASCII and Unicode, including spaces. It's weird that spaces haven't been allowed in the past. Seems like that would have made using a phrase a lot easier.

[01:28:51.640]
Chris: You know why spaces weren't allowed in the past?

[01:28:54.530]
Ned: Because database coders are lazy? That's the one. And they weren't taking the string and salting it before it went in.

[01:29:06.980]
Chris: Also, input sanitization is for lamos.

[01:29:10.580]
Ned: Also, NIST says that passwords should not require any additional composition rules. Now, that's a little vague. What that means is that it shouldn't require specific combinations of characters, including a number, a capital, or any special characters. Now, that might seem counterintuitive. Shouldn't more complex password combinations be better? Here's what they had to say about that. Research has shown that users respond in very predictable ways to the requirements imposed by composition rules. Say, for instance, you chose Horses shoes as your password.

[01:29:58.340]
Chris: How did you know?

[01:30:00.850]
Ned: I looked under your keyboard. But you're told you need to add a number and a symbol and a capital letter. The vast majority of users will simply capitalize the first letter and add a one and an exclamation point to the end since they share a key. That doesn't make the password much more secure, and it begins the arms race a new of trying to prevent certain patterns and users getting increasingly frustrated. I'm sure you've experienced this when it's like, you can't end it with a exclamation point now. You can't begin it with a capital, and it just goes on from there. It's like that password game. Nist goes on to say that passwords should not be required to change periodically. They started with a year. I think at some point they dropped it down to every 90 days in the early 2000s. They They've now said, You don't, don't do that. Don't make users change their password. A change shall only be forced if there is evidence that the password was compromised. Otherwise, leave it be. That also lines up with research. Changing your password on a regular basis doesn't actually enhance security and frustrates end users.

[01:31:24.760]
Ned: What about password hints and retrieval? Nist has some feelings on that. Hints shall not be accessible to an unauthenticated client, so no more password hints at the Windows login screen. If you're not authenticated, I'm not going to help you guess what the password is. Wild that we thought that was a good idea.

[01:31:48.630]
Chris: Convenience versus security.

[01:31:50.600]
Ned: Services shall not ask for or store knowledge-based answers or security questions when someone is choosing a password. I love this. Why do they say that? Well, the NIST document doesn't actually explain why they don't want that, but if I could hazard a guess, and Chris, let me know if you agree. Knowledge-based answers don't do much to protect users since a moderately determined hacker can probably find all the information to every question unless you choose to lie, which most people don't. Also, a lot of users, including me, forget what answer they gave and just end up getting locked out anyway. Your favorite place in the world? Apparently, at one point, I thought it would be hilarious to say Millie ways. I was insufferable in my 20s, Chris. And now, Do you know what Millie Waze is? You gave me a look. It's the restaurant at the end of the universe. I'll see myself out. Lastly, When a password is being selected, the verifier should compare it to a block list of commonly used passwords, with the caveat that they should compare the entire password and not just a portion. If the password is rejected, they have to say why.

[01:33:17.620]
Ned: That doesn't mean simply repeating back the password requirements. Services actually must tell you what about your password doesn't pass muster.

[01:33:29.580]
Chris: That though, is going to take 10 lines of code.

[01:33:34.720]
Ned: I know.

[01:33:35.370]
Chris: So frustrating. Who's got time for that, Ned?

[01:33:37.700]
Ned: Seriously, we're too busy adding AI to everything.

[01:33:42.660]
Chris: Ai, one exclamation point. That's the one.

[01:33:45.800]
Ned: There is more to the document, but I think those are the juiciest bits, and several of them run counter to accepted knowledge regarding password security, especially not requiring complex character combines and not forcing the regular rotation of passwords. The security world has known for years that both of those are mostly pointless, but now they have a document they can point to and be like, Hey, Greg, stop it.

[01:34:15.800]
Chris: Not only do we now have that document, this document has been in draft for at least six years.

[01:34:22.060]
Ned: That's true. But it's getting real close to being super official, Chris. That's what's important. That's That's the new NIST guidelines. I like them. They're good. Passwords are still awful. So what's beyond passwords? How can we make this situation better? Now, I've got a few things that I want to mention, but I suspect... Aha, this episode has already run long, so I'm going to be brief and put a pin in some of them for future episodes. Federation. Every website brings its own identity provider, and it's a goddamn nightmare. It's a nightmare for management, and it's a nightmare for security. If you're building a web app today, do not implement your own identity solution for the love of all that's wholly. Allow for federation with other identity providers like Okta, EntraID, Google, etc. But not Facebook, because fuck them.

[01:35:14.720]
Chris: This falls very much into the bucket of, don't write your own encryption.

[01:35:19.460]
Ned: Don't create your own identity provider. Pass keys in FIDO, FIDO 2. How about we don't use passwords at all?

[01:35:29.110]
Chris: What? Passwords? I know.

[01:35:31.630]
Ned: Pass keys are cryptographic keys used for authentication, and they're generated by your local system. The private key used to generate them never leaves your device, and each authentication leverages a one-time response that is not reusable. Some websites have started adopting this, and all modern browsers support it. I like it. Docusign actually uses pass keys. It's the The only one I've seen reliable use them, but it's nice because I don't have to pull out my authenticator app anymore.

[01:36:05.830]
Chris: That does save you seconds.

[01:36:09.480]
Ned: Seconds. Precious seconds. Password managers. These are a necessity for the moment. They are still painful, and pass keys are way better. But until we move into the era of passwordless, please adopt one if you haven't. The downside is that no one outside of tech actually uses them. I mean, not really. I tried to get my wife to use one, and she got so frustrated by the experience, she gave up and went back to using the password feature on Chrome. I don't blame her. She's fairly tech-savvy, but the process is-It's just a password manager.

[01:36:42.980]
Chris: It's just a password manager.

[01:36:45.400]
Ned: When you try to use it on a mobile device, it is clunky. It is frustrating at times. It's frustrating for me, and I think I'm tech savvy, at least on alternate Mondays. The experience could be better is what I'm saying. We have to meet people where they are. Finally, MFA. Adding a second factor to your password makes a world of difference, and it's the interim approach that most websites are taking. Nist also requires at least a second factor for systems that have a certain level of security classification. While we at Chaos Lever know that SMS is terrible and insecure, it's also better than nothing. Ubekey if you can, Google Authenticator if you can't, and SMS if you must. Google Cloud, Microsoft Azure, and AWS are all in the process of forcing everyone to use MFA, which is about five years late and not soon enough. In closing, passwords were always terrible. Almost as soon as they were added to the first NCSS system, they were purloined and abused. It's been a game of Whac-a-mole ever since. The Internet has only exacerbated the situation for all of us. The new NIST standards help add a little sanity to password policies, but the ultimate solution is to just move on to something else.

[01:38:17.020]
Ned: And don't even fucking Web3 at me, or I will Karate chopped your car-toid. Carotid. Carotid? My God. That, too.

[01:38:25.390]
Chris: Is that in the mirepoix?

[01:38:27.110]
Ned: It might be. Hey, thanks for listening or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friend. You accomplished something today. Now you can sit on the couch, fire up your password manager, and slowly rotate the passwords on all the websites that you barely use. You've earned it. You can find more about the show by visiting our LinkedIn page, just search Chaos Lever, or go to our website, chaoslever. Com, where you'll find show notes, blog posts, and general Tom Follry. We'll be back next week to see what fresh hell is upon us. Ta-ta for now.

[01:39:13.740]
Chris: I think my passwords are pretty secure.

[01:39:16.730]
Ned: They are avuncular.