BSidesSF 2026 - How the Vietnam War created single sign-on — and how it's evolved... (Connor Peshek)

Hey everyone. Conner here. Um this talk is called how the Vietnam War created single sign-on. A little bit of an introduction on me and who I am. I originally uh started out as a self-taught JavaScript engineer. Uh I ended up working at Kroger pretty early in my career. I helped them do ClickList, which was one of the first like grocery delivery pick-up services. Um little after that I left and uh made a startup with some friends. We ended up getting acquired by Cloudflare. Worked there for 3 and 1/2 years or so and now work at Authentic, which the general idea is just open-source self-hostable Okta. So, I work on a lot of the uh SAML logic

there and uh do regular demos as part of DevRel to show people how to integrate any new features we release every release. So, when I started working in SSO, I mean, in authentication period, I was just curious to dig in and kind of find out. I feel like any space can have really interesting history if you're willing to look deep enough, you know? And I was really surprised how quickly there was a lot of interesting stories. Um I mean, cryptography always has a really interesting past. So, I ended up making this talk, kind of walking through. And I'm going to start this talk a little bit pre-Vietnam and actually start in the kind of World

War II era of cryptography. So, at that time, there was only analog-based phones. Um and the only real device that could be used to obfuscate any voice communications was called the A-3 scrambler. So, it didn't have any encryption. It was really just uh frequency inversion. Any high-pitched frequencies were turned to low, any low to high. So, it made things kind of garbled, but it wasn't very good at uh like actually secretly telling anyone anything. It wasn't that hard to unscramble the message. It was just better than nothing. Um So, Bell Labs, the R&D department at AT&T, uh in the '70s said uh any basic high school boy could unscramble something like the A3 A3 scrambler and the signal

it made. So, you know, in the '40s they were pretty confident that uh anything on this device was probably going to be listened to by the Germans. So, there'd always be a kind of cost trade-off of do we actually want to send a message over this? It's quicker, but it's definitely probably going to be uh intercepted. But, was still used by like Churchill, FDR, high-level generals, things like that. Well, there's a point when a general gets a word from American code breakers that Japan's about to drop bombs on Pearl Harbor. He really wants to use A3 cuz it's time sensitive, but he's really afraid of them knowing that we know. He instead sends the message via coded radio

telegraph. And by the time it gets there, the bombs have already dropped. So, this is a huge problem. They decide at that point the US military goes right to Bell Labs and goes, "We we can't have this happen again, right? What can we do?" So, Bell Labs tells them, "We've been working on a project called the Green Hornet." Now, the Green Hornet is called that because this is still a time when radio shows are very popular, and there was a radio show called the Green Hornet. And the intro was this loud humming kind of noise, and if someone tried to listen and spy on the Green Hornet, that's what they would hear. So, that's how it got its original name.

There were some pretty notable people who worked on it. Uh the most notable being Alan Turing. And this was the first use of a vocoder. So, vocoders are able to take an analog signal, convert it to digital, and that at that point allows you to actually encrypt the message you're sending. So, it was very interesting. Uh it used vinyl records uh to actually encrypt and decrypt. You would have two copies of the same vinyl at each end, and they would play at the same time. And the sending one would encrypt the signal being sent, and then it would be decrypted on the other end from the other vinyl. And afterwards, the vinyls were destroyed. They're

one-time use, um very, very secure. Uh the government purchased it. They called it the SIGSALY, which stood for nothing. It was just gobbledygook. Uh they wanted to confuse people with the name. But, there is only 12 ever installed. Installed across the US and Europe. Uh FDR was nervous that Churchill would call him throughout the night, so he opted to put it in the Pentagon, not in his house. And Churchill had his installed in a department store in London, and disguised it as a bathroom. Swear to god. Uh it was so big, it was just hard to find anywhere to put it, you know? So, it was a huge success, though. Uh it replaced A-3 scrambler for any

really important fast communications that needed to happen. It was actually used to discuss the bombing of Hiroshima. And to this day, there's no known record of it ever being cracked. Um but due to the fact that it was big, it's over 50 tons, uh extremely expensive. The second that World War II ended, they stopped using it. They said, "We got to find some other solution, uh but great that this was here for when we needed it." Right? So, moving into the kind of post-World War II, moving up to Vietnam era, the AUTOSEVOCOM was built out. This was a really large network of encrypted military devices that could communicate across the world. Uh it was pretty expensive.

Uh, and there was some some big problems. So, the the main device on the autosevocom was called the KY3. And this is a picture of two KY3s on top of each other. You can see these things are huge. Uh, much smaller than the than the SIGSALY, but still really big. Um, and they were kind of like this big hodgepodge of a bunch of devices shoved together into a box. So, it had a vocoder shoved in there, had like a KG-13 for encryption, and all the encryption is working with physical keys. It's really um, really not time effective, very frustrating to use. The way that the protocol worked was single key encryption, uh, directly device to device. So, if a KY3A wanted

to call KY3B, it would in it would take the signal from analog to digital, encrypt it with phone B's key, send it over to phone B, they would decrypt, then use phone A's key, encrypt and send over. So, this meant that every phone had to hold the key of every other phone on the network, and this scales terribly, right? It's it's so expensive. It's better than nothing, but it's a it's a pretty big problem at the time. And kind of post autosevocom building out, uh, the Vietnam War starts really kicking off, um, and the US cannot figure out why it keeps losing battles at the rate it is. Uh, there's they can they figure there's

no classified documents or codes being leaked, uh, but the Vietnamese are still like aware of every move that's happening and countering it really efficiently. So, the NSA launches what's called Operation Purple Dragon. Uh, they are able to find out that the Vietnamese were just paying really close attention. So um there was a lot of things being said over radio that were over code, but we're not encrypted. So, they were just able to decipher this person called this person. We can see more supplies are being sent to this base. We know they're probably going to do this. And they were able to pretty efficiently counter everything going on. So, this ends up being actually the the operation

known for creating OpSec um and a lot of the protocols for OpSec. But, uh as that's all in the NSA, basically says the the biggest problem with what we have is that all of these communications, even if they're said in code, are still happening over open open lines, right? So, at that point it's decided the most important thing that needs to happen is encrypting phone communication and every phone being able to call every other phone encrypted. So, the head of R&D at the NSA decides, "What if we, instead of having all these keys stored directly at the phone, we have a central location on the network that has every key of every device. And that way, if you make a call, you

actually just authenticate with this central server, and then it can give you a session key." And that system's called the Bell Field. So, it worked exactly in that way. When before you actually made a call to somewhere, you would actually send a message encrypted with your key directly to the server. And due to the fact that that key is able to be decrypted, you know that it is a device in the network and it's authenticated to call any other device. It generates a unique session key, encrypts it with phone A and phone B's key, sends it down. They're now able to communicate with their own copy of the session key, and it's a one-time use

after that session key is destroyed. So, it was I mean, extremely well done, right? Um Uh they thought with this the old KY3s were I want to say 18,000 per device and they were like this system so efficient, it's going to be five grand a phone and they made the STU-1 which was like 30 grand 35 a phone. It was not any cheaper. It took years to get it cheaper. But the core thing is they made that system of making session keys, right? And with that I kind of want to stop and ask like let's define single sign on. What is the definition of single sign on? You can argue it's if you authenticate at one central location

you're automatically authenticated anywhere else that trust that location, right? And that is exactly what the Bell Field does for the first time ever in any device. Um at this same exact time there's someone named Jerome Saltzer. So this moves us a little bit into early 80s at MIT. Jerome Saltzer is a um professor who's also doing that word when they pay you consulting. He's also doing consulting for the NSA and there's a really big problem at MIT that a lot of their systems are still mainframe based, right? They have like the CTSS and they have Multics and it's really difficult for students to actually have access to computers. And they were trying to picture with

this new thing like Unix coming out like what if there's a way that we could set up a big network where you could just walk up to any machine in campus, you could log in and be authenticated to connect to any other device on this network. It wouldn't matter what hardware you used. It wouldn't need to like be locked to a single mainframe's compute. You could uh have something that kind of reflects what you'd consider pretty close to current day internet, right? It's really impressive. So, while he's consulting, he sees the Bell Field and is like, this is literally exactly it. Like, this would be the single sign-on system to using computers, but it's classified. He has no way of

telling anyone about it. He just has to know and kind of suffer, and he gets a lucky break. Uh there is a NSA member who goes to a conference, and at this conference, he gives like a vague description of the Bell Field. He doesn't give all the exact details, but there's enough there that if you knew what you were doing, you could piece something together, you know? So, he takes this proceed and he goes to Needham and Schroeder, and he goes, "Research this. I swear this will be like good, all right?" Um and they do, they invent the the Needham-Schroeder protocol. And um I'm going to jump to that for a second. The Needham-Schroeder protocol,

uh Kerberos is the first implementation of that protocol, and it is a clone of the Bell Field system from the Vietnam war phone systems. So, it works basically the same way. Uh there's a slight difference that Kerberos has a uh ticket granting server that um that Bell Field did not have, but it's still you authenticate with the authenticating server. After you've done that, the TGS gives you a ticket granting ticket, and now you have access to every service on the network, right? Um but I do want to make sure I take a second to highlight Project Athena. This is probably um one of the most interesting things to look up in like the history of computer

science. Uh it was insane. I mean, the difference of a student before would have walked in, they would have waited in line to access a mainframe, and it would be like a dummy terminal that was directly wired to a mainframe. Uh the mainframe set up to go like round-robin compute system. So, each terminal gets a couple seconds of processing before the next one does. It's like a a way of kind of splitting it up and making it look like you have a bunch of parallel compute happening when you don't. Um and it's like you go from that to these students walked in, signed in on any computer, accessed uh they had Zephyr, which was basically like an AOL Instant Messenger

clone. They had message boards. Uh they had the equivalent of like Google Docs. Like all of their files were stored remotely and they could pull them up and edit them. I mean, it was huge. Uh it was also one of the first major uses of Unix. X Windows 4 Linux was was created for this project. One of the first ever DNS servers, Project Athena, was made for this project. So, it's huge to the history of computer science. So, after this created though, uh there is a focus to getting the internet happening, having more uh devices that are made I mean, previously it was very difficult to get a lot of things working together cuz there wasn't

um standards made on how different uh devices should communicate, right? This is kind of the big thing coming into the '90s that we try to figure out. The first attempt at this is uh companies like Microsoft, Sun Microsystems, IBM uh coming together and making a standard for data transfer called XML, which we all love XML. Um so, but once that's made, we kind of end up running into uh a similar problem again. I mean, Kerberos made a lot of sense for a single sign-on system in local networks. Uh but like, you know, it used UDP, it didn't uh have HTTP HTTP support. Um and kind of moving into the internet, we needed like a different

single sign-on protocol that was going to fit these rules better, you know? So, with uh the creation of some of these protocols in XML. People the creators of XML in their infinite wisdom decide we should use SAML. Uh which is just really the first single sign-on system made for like the actual internet in mind. Right? Um obviously it makes a lot of sense. It's XML-based because that was the only protocol that existed at the time. Um or the only uh data standard, right? Uh as an overview of how SAML works, uh you have a IDP which in this case works very similar to like uh uh Bellfield's like central key server. Um and then you have a service provider

which is just any application giving uh a service to someone. Um you predefine between each other the rules of where will the signatures be on the SAML? Is it going to be encrypted or not? Where are your uh URLs that I need to send my SAML tickets to? And what are our rules? Are we using post? We're using redirect? Things like that. So, um it's still pretty popular in a lot of of corporate environments. Um I personally use it quite a bit still. Uh but this is really the main reason SAML's made, right? But not long after the internet starts, we have the browser wars um that everyone is at least somewhat aware of. Uh I think it's an extremely

interesting story as well. You know, in the mid-90s Netscape dominated the browser market pretty hard. Uh Sun Microsystems was starting to push Java, supposed to be the language that runs everywhere including the browser. And uh Microsoft saw this and like panicked because if people spend all day using software in the browser, it doesn't matter what operating system you're on. So, they immediately realized we have to do something and like we have to control the browser or destroy it, right? There's no other option. Um So, Microsoft goes to war. Uh they bundle Internet Explorer for free with Windows. They start going to other ISPs and basically saying drop Netscape or else like you don't get to sell us, but

if you do drop them, we're going to push you really hard in our software. Um they had a system they called embrace, extend, extinguish, which they would adopt a standard, extend it so far that no one else could not use their version of it, and then destroy the competition with that. Which is a very monopolistic practice. Um When they did this, one of the features they made was the XML HTTP request, right? So, previously all browsers were just static documents. There is no no uh interactivity, right? You if anything changed, you want to see a change on your browser, you're hitting refresh or or going to a link. Um Well, they they added this uh in

order to kind of extend the spec past what other people were doing and ended up birthing modern web apps, which is kind of the thing they were afraid of in the first place, right? Um but as this took off, people very quickly were like XML is terrible for this. Uh there's this thing called JSON where uh we can actually just use JavaScript objects. Uh this is way easier than XML. I do not want to parse an XML document. And pretty quickly XML is abandoned. Um Microsoft eventually sued by Sun Microsystems uh because they broke the Java the the Java spec in the browser. Uh and then they're also sued by Netscape. Um The overall of this is actually very

sadly that Microsoft got in very little to no trouble for this. Uh it was pretty terrible. Um, but the point being we're now in a world where we have modern web apps. Everyone's using JSON instead of uh instead of using XML. And uh at that point everyone is not very interested in SAML uh on one of the core concepts that no one wants to use XML. Uh, so around this time OpenID is created. Uh, but OpenID is very different um OpenID Connect uh is different than the original OpenID. Uh, the original OpenID was actually this whole system where uh people on blogging systems could verify who they are, right? A lot of blogs at the time

would just let you put in any name and comment. And people would just show up and be like, "I'm Bill Gates and what you're saying is dumb." Right? And it's just like really annoying. It was very spammy. So uh the system for the original OpenID was actually the system where you would put in a URL and they could kind of ping out to see if you're if you have a session at this URL. And if you have a session, we can assume that you are the owner of this URL and that means you are who you say you are. So it it originally started as a system to verify people uh across blogs. Um, but it also

uh wanted to take on some bigger challenges basically that uh authorization was terrible around this time. If you remember going on Facebook and if you wanted to sync your contacts, they would literally be like, "Give us your Gmail email and password. We're just going to use it and not do anything bad and we're not going to save it in plain text." Um, and no one wants that. So not long after uh some of the people working on OpenID were like, "Well, what can we do about this authorization problem right?" Um, and that's eventually kind of how we moved into having OAuth and OpenID Connect. Uh, this is uh a protocol I think a lot more

people are familiar with over Kerberos and SAML. Um, but it's very similar still in a lot of the core practices, right? You're going to set up a trust beforehand. You're going to move to the proper URLs with the proper configuration, uh, verify your identity and get a token. Um, and I think I am perfectly hitting the 25-minute mark right now. So. Thank you.

Uh, if anyone wants to connect on LinkedIn, uh, please please go ahead and do. And I would like to turn this into a, uh, YouTube video. So, if you have any interest in checking that out, go ahead. The channel is nothing right now, but there will be content. I promise. Yeah, sure. Yeah. Do we have time for some Q&A? Uh, you can either raise your hand or submit your question on Slido. Feel free to get a conversation started.

I'll ask a question. Connor, do you know of, uh, James Burke? This is very James Burke-esque. I Is Oh, I forgot to pay. The QR is disabled. Yeah. Well, if anyone would like to connect, come, uh, come talk to me, you know, I would love to. But, uh, no, I uh Connections, very much a, uh, great historical recap of modern-day technology. So, as you research this paper, what was the one or this presentation, what was the one thing that surprised you the most as far as the linkage between the technologies? Uh, I definitely think the um the most direct interesting thing was was seeing how, uh, Kerberos was connected, um, to the the to the Vietnam protocol. Um,

but I also want to make sure that I didn't maybe misunderstand the question, I guess. Like, uh, are you saying looking at all the protocols overall what was the God. Yeah, it was just a there was just an aha moment where you said, "Wow, that's where that came from." Yeah, I mean that definitely definitely that as I I didn't expect that to come from like a phone system during the Vietnam War, you know. What other questions do we have? Yeah.

Yeah, I mean it's cuz that is like a a hard um it getting things in in the time frame, too, right? It is like it it's one of those things that makes a lot of sense when you look at the shift, but it's it's also it isn't just that because when you follow that evolution from OpenID up to OpenID Connect, like there is he So, if you if you actually go back on the on the Wayback Machine to the original OpenID page, it's like um it was uh uh Brad Fitzpatrick, I think it was, who who made OpenID, where he literally says, "Like, we looked at SAML and we don't want this because of the way it's

set up. It it's close to solving our problem, but not directly, right?" And one of the reasons was like it's just not modern anymore, right? Um but it is also like when you look at the original problem he was trying to solve, uh he was the creator of LiveJournal. So, his core thing was really "I just want people to be able to answer on message boards and prove who they are, and we don't need this super complicated setup of like, you know, setting up a uh like a a trust with the IDP." Like the cuz the original OpenID didn't really work that way. It was more of like a ping. Like we kind of just ping

out and see if you're authenticated, and if it is, okay, we trust it, right? And it was kind of like it kind of built off of that. After that happened, they started building that out. They're like, well, I mean, that you know, SAML is still using XML, no one's using this and it made sense to evolve that way and that's a lot of the reason I think I see more people use it now, right? It's like people don't really like SAML and XML and this is just it feels modern, you know? Um but but you are right at the core of it, there kind of was like a separate problem to solve that it made

sense to evolve to solve that problem. Yeah. Cool, we got some questions that came in on Slido. So, the first one is do you know how users authenticated with Bellfield? Um well, technically, the fact that you I mean, it's almost kind of like WebAuthn. Like the fact that your key is there and then it was decrypted successfully on the other end kind of is your all like we're not like saying that John made the call cuz it's John's key, but it's more like phone A is allowed to move through this network. So, it's authenticated by the fact that the key is legitimate, you know? And another question. We have two more questions. Yeah. What do you think is

going to replace OIDC? That's a good question. I know that there's I think there's OIDC like 2.1 coming. Um I think I think we need to see a problem that is relevant enough to change things. Like I I can't think of anything yet where it's like OIDC just doesn't fix this thing well enough, you know? Um so, I think we kind of have to see something change enough to to really see a reason for it, you know? Very cool. And I'm not clear on this uh next question. So, if uh the person who asked it feels like or feels comfortable clarifying, that's fine as well. Um have you reviewed the other crypto challenges on https mysterytwister.org?

Also, have you analyzed the weaknesses in these systems? Uh not massively. I mean, so I do like I said, I do um write uh a lot of the logic at our at our company for the SAML integrations. We do like SAML source and SAML provider integrations. So, I've gotten much more intimate, probably mostly with SAML, uh than any other protocol. And like I have noticed like a lot of IDPs don't like truly kind of neglect SAML. They don't always look very in there there a lot of their integrations aren't to spec, aren't um like well set up uh and cause a lot of bugs. So, I just know for a fact that like a lot of systems just have to be

kind of insecure cuz they just weren't set up properly to spec, right? Um so, I'm aware of some attacks in there, but I'm not going to pretend like I'm like this SAML expert who knows every attack and could, you know, hack any IDP, right? Very cool, very cool. Any other questions? We've got about 2 minutes. We can have time for one more question. If not, thank you all for your very thoughtful questions. Thank you. Thank you. To our presenter, thank you so much.