← Safe Mode Podcast
Safe Mode Podcast
Should you still trust your password manager?
00:36:40
In this episode, Greg explores the gap between pa…
Loading summary
Transcript62 lines
- [00:02]
A
Everybody always talks about password managers, but are there some security issues that we're not seeing? We'll talk about it on this episode of Safe Mode. Welcome to Safe Mode. I'm Greg Otto, editor in chief at cyberscoop. Every week we break down the most pressing security issues in technology, providing you the knowledge and the tools to stay ahead of the latest threats while also taking you behind the scenes of the biggest stories in cyber security.
- [00:26]
B
An attack is coming.
- [00:27]
A
It's about keeping us safe.
- [00:29]
C
He's just a disgruntled hacker. She's a super hacker. Stay al that. Stay safe.
- [00:33]
A
Stay safe. This is Safe Mode. Welcome to this week's episode of Safe Mode. I am your host, Greg Otto. In our interview segment this week we're going to be talking with Kenny Patterson, a professor at ETH Zurich. His team, along with another Swiss university put out a really interesting research paper on some never before seen faults in password managers. He joins us to talk about it and really get down into the nitty GR there. But first, Matt Kapko joining us this week. Matt, speaking of nitty gritty, we're right back to the cat and mouse game between attacker and defender. Google put out some really interesting research this week that looks at the ongoing brickstorm saga, I guess that you could call it.
- [01:23]
B
That's right, yeah. It keeps getting new names. So thanks for having me on, Greg. This is a suspected China state sponsored espionage campaign that we've been covering since last summer when it was first uncovered. It just keeps going from bad to, to me and others I've spoken with. The most concerning aspect of this campaign is that most of the activity remains unknown. This is not surprising and pretty common in nation state attacks. But this is another example of where we don't learn about the significant damage they've caused until well after the fact. The latest escalation here is, it's worrisome. Researchers at Google and Mandian said a cluster of China state hackers have been exploiting a zero day vulnerability in a Dell Technologies program for virtual machines since at least mid 2024.
- [02:14]
A
So this give us some more details with what you can on this piece of technology because it seems like again, this is one of those things where it's a back office IT thing that no one ever thinks about except the people that set it up to make sure enterprises are doing what they need to do technology wise. And then all of a sudden it becomes a part of the ATTCK profile.
- [02:40]
B
That's right. I mean virtual machines are prolific in enterprise deployments, government agencies as well, this is one of those programs that just runs in the background to basically reset those installations. So the problem here with this vulnerability, it's a. First of all, it's a maximum severity vulnerability. It involves a hard coded administrator password that they pulled from an Apache Tomcat. This allows unauthenticated remote attackers to gain full remote access. So this password's been in there? Haven't really thought about it. These Chinese threat groups have been exploiting this for at least 18 months. One of the groups that's been exploiting this overlaps with another threat group that we mostly know as Silk Typhoon.
- [03:29]
A
That's the group. Another Typhoon. Welcome back, guys.
- [03:32]
B
That's right. So this, this is the threat group that's been burrowing into critical infrastructure and government agency networks undetected since at least 2022. It's all part of a much bigger problem.
- [03:44]
A
So I know the last time that we did this there was a lot of outreach and a lot of notices pushed to basically be like, heads up, big issue here. What have we seen this time around?
- [03:58]
B
Yeah, it's been a little bit more quiet. CISA hasn't said in anything on this yet. They did tell me that they were going to have an update on this today. It's mostly come from Google, which actually sounded the alarm on this originally. Dell Technologies, they disclosed and released a patch for the vulnerability yesterday, but not sharing much more beyond that. Yeah, a lot of questions unanswered still and not many others chiming in.
- [04:26]
A
And it seems to always round back to this when we have you on the podcast. Edge devices. This is like. This is like, I would say exhibit A on why we say that edge devices and why we report on edge devices being a really weak point inside an enterprise.
- [04:50]
B
It's a real problem. Yeah, so much of our emphasis is on this because of that. I think one other area that just showcases how bad this is is these edge devices are again, it's another piece of equipment or technology that they're just. It's in use, but they're not really thinking about. These threat groups are typically going after victims that don't have EDR on their systems. It's difficult to put EDR on edge devices, if at all, so they really know what they're doing. But they're typically dwelling undetected in these networks for more than 400 days. That just gives you a sense of how difficult it is to spot this malicious activity. That's a long time to spy on targeted networks and steal sensitive data.
- [05:37]
A
And also there's an interesting detail in your story too, which gets the Casimiro cat and mouse part that I was talking about in that it seems like when Google released their initial information on Brickstorm, which was going after, I believe, VMware appliances, it seems like China was already in the process. I shouldn't say China. This group of Chinese state sponsored hackers was already in the process of coming out with a new version, basically iterating on top of what was already put out there. So it really goes to show how stuff moves so quickly in this space.
- [06:20]
B
Yeah, certainly. I mean, by the time they spotted it or very soon after, they had already moved on. So they were implanting Brickstorm malware into networks before this campaign was detected last summer. By September, the attackers had replaced that with Grim Bolt, which is just a more advanced version of Brickstorm. But Google really used some strong language about it. They said it's harder to detect, more difficult to reverse engineer all kinds of things in there that just make it more of a problem for those that they're going after.
- [06:53]
A
So on that harder to detect part, is there anything that Google or Dell or anything that has pushed, besides Dell pushing their patch that could help enterprises that are listening and going, I'm kind of worried about this.
- [07:07]
B
Yeah, that's difficult. I think not having a clear understanding of what's traversing your network is a problem that all enterprises struggle with. I think it's a lot of those common best practices. But we see this time and again they just, it's really difficult when somebody, somebody's logging in with a password. It looks legitimate. It's really, it's, it's hard for them to know whether that's malicious activity or not.
- [07:32]
A
But outside of this warning, were there IOCs or any other tools that have been released by Google to say, hey enterprises, here's what you can do to figure out if this is a problem for you.
- [07:45]
B
Yes, they have been releasing IOCs. They released some new IOCs yesterday specifically to this new malware, which is a backdoor that they're implanting.
- [07:55]
A
Okay. And I'm sure we have that information on the website. Anybody who's interested in this, check out Matt's story on cyberscoop.com Matt Kapko, appreciate you hopping aboard.
- [08:06]
B
Thanks for having me on, Greg.
- [08:08]
A
Now to our interview segment, talking with Professor Kenny Patterson from ETH Zurich. The password managers are part of cyber hygiene. They are very important. So we don't have to write them down, we don't have to just leave them vulnerable to being hacked. But look, even that technology has some security Issues. Two Swiss colleges put out a research paper recently and found some serious security vulnerabilities inside this technology. During testing, researchers were able to view and even make changes to stored passwords inside these managers. So we talked with the professor to really talk about, you know, what needs to be done to rectify the situation and really the thoughts around encryption and how it needs to be better built into these password managers. Check it out. Now we're peeling back the curtain on some apps that probably all of us use in the infosec world and even beyond. We're talking about digital password managers. And look, we often hear them or around this term zero knowledge encryption, when you get start to get into like the technical marketing speak behind these platforms. And it's really rooted in the idea that even if a server that stores all of these passwords is breached, you know, your password can remain unreadable. But a new paper from two Swiss universities suggests that for many of the world's leading password manager providers, that zero knowledge term might not be all that it seems. So joining us is Kenny Patterson, the Institute of Information Security at ETH Zurich, lead for the Applied Cryptography Group. He's a professor there. Kenny, really appreciate you hopping aboard and joining us.
- [10:02]
C
It's a pleasure to be here. Greg, thanks a lot for inviting me on.
- [10:06]
A
So your paper released in the last week looked at an analysis of leading password managers and uncovered a lot of distinct attacks that really haven't been thought of before. So I'll let you take it away. I would love to hear more about really the genesis of the project and how you decided to really focus your research on these particular password managers.
- [10:30]
C
Oh yeah, great. So the project actually is something we started way back, I think in 2024 or maybe early 2025. And it came out of some previous work we had done looking at cloud storage systems, things like Mega and nextcloud and so on. And you know, they are more like storing your music or your photos and they also offer this kind of end to end encryption or zero knowledge encryption guarantee. And we found a bunch of vulnerabilities there, particularly in this, what we call the malicious server setting. And this is the setting that the vendors themselves advertise, both for end to end encryption for cloud storage, but also for password managers. And you can think of password managers as kind of doing more or less the same thing, just the data is small units, passwords, credentials, credit card numbers instead of lots and lots of photographs or music files. So we kind of expected to find a much stronger, a much better picture from a security perspective, because after all, your passwords are so sensitive and maybe which MP3s you're storing on a server are not so sensitive. But what we discovered really kind of surprised us. So across the four password managers we looked at, we found 27 distinct vulnerabilities, all of them in this malicious server setting. But I just want to really strongly emphasize that this is the setting that the vendors themselves advertise that their products should be secure in. So they say things like, no one at our organization could read your passwords even if we wanted to, or even if we tried. Right. And so we thought that that made it legitimate to think about, well, what happens if the server does go malicious, if somebody compromises the server, if they have a breach, if they have a malicious insider, you know, maybe a rogue employee. And, you know, after all, you know, these. These companies are storing some of our most sensitive data, so they're certainly a target for attack. And some of them have been breached in the past. So the starting point was way back there in 2024. The original idea actually came from Matilda Bacchendal, who was a PhD student of mine at the time. She's now graduated and she's a professor herself now at UCI in Lugano in Switzerland. And she worked originally with Giovanni Torrisi, who was a master's student who came to us to do his master's thesis. And Matilda picked this as the topic. And then Matteo joined us, and of course I got involved as the professor, and together we worked to analyze these four different vendors.
- [13:09]
A
So the vendors here, Bitwarden, LastPass, Dashlane, and I'm sorry, I missed the fourth there. I'm interested to hear more about how you came to find them, because I would, I think, from reading your paper, it had a lot to do with the fact that these companies are pretty open. They put their code repositories online, so it gives you the ability to actually conduct this research. And that's not the same across all password managers out there.
- [13:38]
C
Right. So we actually started with Bitwarden precisely because they are open and, you know, anybody can just go and look at their code and see what they're doing. And they even, you know, they develop in an open source manner. And that's something that we really laud them for. We really appreciate that. It makes our job much, much easier. But the other ones are actually not so open and we had to engage in a certain amount of reverse engineering to figure out what was going on. The fourth vendor was one password, and we chose them partly because they actually have a very nice white paper that describes their security architecture that helped us along the way, but often there's a bit of a gap between what it says in a white paper and what the code is actually doing. So you still have to do quite a lot of legwork to kind of COVID that gap and make sure that ideas that you develop kind of on paper would actually work on practice. So for every one, for the first three vendors, we found 25 attacks in total. And then later we looked at one password, and for the first group of three, we actually developed like, proof of concept code for all of the attacks. So kind of simulating what the server would do, talking to an honest client, and then doing the malicious behavior that required for the attack to work. So openness was certainly a criterion for selection, but so was things like market share and also the kind of statements that they've made in public about their. Their view of what security they're providing to their customers. So, and I think it's like, it's really important to emphasize in this research, we're not saying that these companies are malicious or that their servers are breached in any way. We just wanted to take this assertion that they make that they are secure in that scenario and test it. Okay. So, like, actually breaching these servers is probably very difficult. They do take a lot of measures to prevent breaches and to detect breaches. LastPass in particular, have said that they've invested a lot over the last two, three years in their security infrastructure and their whole security posture because they actually were breached multiple times, twice, I think, and had other major security incidents. So, you know, I think it's really important that. I hope that your audience sees that we're not saying they're broken. We're saying that their claims don't match the reality.
- [15:49]
A
Right. So with that, I did want to get into. Before we really went into detail about some of the attacks that you dove into with the research. You've reached out to all these companies. The companies were not standoffish at all.
- [16:03]
B
They.
- [16:03]
A
They all reach. Not reached out, but definitely communicated with you. And it was. I don't want to say it was jovial, but they were professional in how they went about remedying these issues, correct?
- [16:15]
C
Absolutely. All four of them engaged with us in a constructive way. And that doesn't always happen when you do a disclosure. So I think that's really great and it shows some maturity in this space amongst the vendors. We've had other experience in other product domains where you disclose and then it's Silence, or you disclose and then you get a kind of like an aggressive response or whatever. But no, these companies were great to work with. But what I would say is, and they all pushed out blog posts talking about the work and how much they appreciated it and how they enjoyed the review process, how they benefit from it. So that's all really positive. But if you read very carefully their blog posts, they're all saying that, well, you know, there's nothing to see here at the same time as saying, we're fixing everything. So I encourage your listeners to check out some of their blog posts and analyze exactly what they say in response. One example of that, just to make it concrete, 1Password put a response saying, all of the attacks in this work were anticipated in our white paper. So we're already aware of these issues. That doesn't mean they're going to fix them. It means that they're aware of the issues. Right. So they basically said, you know, the root cause of a lot of these problems is the lack of something called public key authentication. Maybe we can get into the details of what that means, but like there's a technical thing that they don't do that they need to do. And basically 1Password and some of the other vendors are saying, well, that's just too hard. But if you can't do that thing, you cannot be secure in the malicious server setting. It's necessary for security in the malicious server setting. And 1Password in particular have recognized this a long time ago in their white paper and are essentially throwing up their hands and saying, too hard for us to solve. We're not going to do that. But at the same time persist in making the claim that they offer zero knowledge encryption? And so I find that a little bit contradictory. And I would really like to kind of push the vendors to be a bit more open about what security they really provide and what's really on their roadmap for the future.
- [18:17]
A
So your paper, along with all those blog posts are in our show notes, and anybody can dive into those. But you bring up the zero knowledge part, and that's something that I wanted to get into before we dive into some of the other technical aspects. Zero knowledge has a specifical technical meaning in protocols like this. And it seems like it's completely different from how it's used in the ads or the marketing. And I would love to know, you know, is this vendors intentionally misusing the technology or is there just lack of a better gold standards for consumers to follow? Like, is this just a term where it's like, yeah, let's put it on there. And that sounds good. And we can stand behind it most of the time, but when you get down to the nitty gritty technical details like paper shows it isn't all it's cracked up to be.
- [19:09]
C
It's a great question, Greg. I think even within these companies there's tension there over whether this term should be used or whether this term should be retired. So marketing does one thing and all the engineering teams do something else, let's say, or would prefer that something else was done. It's not really a question I can easily answer, except to say that as an academic cryptographer, there is this whole topic called zero knowledge, Zero knowledge proof systems, which are like really important these days in things like cryptocurrencies and anonymous credential systems. And it's a very hot area of research. There's no such thing as zero knowledge encryption in the world of research cryptography, let's say. So it is a marketing term and it kind of these days put it on more or less the same level as something like military grade encryption.
- [19:58]
A
Okay, that's a big no, no. Yeah, I'm not a fan of that term at all.
- [20:04]
C
But what's super interesting is that almost all of the companies who are working in this space have, have landed on this terminology. They're all using the same terminology as their kind of chosen terminology. So I wonder how that happened, how they all ended up in the same place. And I guess what they differentiate on is features, you know, the ability to share passwords with family members or loved ones, that kind of thing. So like, on February 14th, just four days ago, one of the vendors launched a new feature for Valentine's Day which was, you know, you could now share passwords with your, with your, with your, in your situationship. I think they even use that terminology,
- [20:40]
A
which is pretty cool.
- [20:42]
C
Very, you know, with the zeitgeist there. And so like, that's one of the big issues in security in general, not just restricted to password managers, is that it's a bit of a market for lemons. I don't know if you're familiar with that term, but like, you know, in the used car sales. Right, yeah. Consumers don't have very good ways of telling what's the best product out there, which one offers the best security. But largely speaking, the four things that we looked at all failed kind of spectacularly in the same kinds of ways. So there were a lot of commonality between the different attacks that we found against the different products.
- [21:16]
A
So, yeah, let's get into those attacks. One of your most startling findings involved Bitwarden's account recovery. You describe an attack where, as a user joins a group, the server can essentially swap out a digital safety key for a fake one. Why is it that the app just accepts this fake key without checking an id? And how does this give an attacker the ability to read the entire vault?
- [21:39]
C
Yeah, that's a. It's a really nice attack that we found, and it's kind of characteristic of this whole issue of the lack of public key authentication. So, you know, just to get a little bit technical for a moment, public key encryption enables me to get hold of, say, your public key and then encrypt to you so that only you can do the decryption using your private key. So there's this asymmetry between your public key, which as the name suggests, is public, and everybody can get hold of it, and then the private key that you need to do the decryption. So if I want to share a file with you or enter into key recovery, I might take my master key that's encrypting my vault, and then encrypt it to your public key so that you would now have a copy and only you should be able to decrypt. Right, but the problem is in these systems, there's no way for me as a user to check that the public key I'm using is actually your public key and not somebody else's public key. And so what a malicious server can do is when I request that feature, instead of sending me their, instead of sending me your public key, they'll send me a public key where they know the private key. Right? And a malicious server can do this. And I have no way of checking within the app itself that actually I'm getting the right public key, so I'll just blindly encrypt to the wrong public key. And now the master key that was encrypted is in the hands of the malicious server. And so now they can decrypt my vault. So it's really simple. I mean, it's like, you know, it's a 30 second explanation. And actually, when public key cryptography was invented in the 1970s, in the famous paper by Diffie and Hellman, they recognized this problem right at the very beginning, at the dawn of public key cryptography, they knew you needed to have some way of like certifying whose public key is whose. And this is what PKI is for. It's what digital certificates do for us. And it's also what in a System like say Signal messenger, we have these safety messages or safety numbers for. Right. Or we compare key fingerprints. So there's like a number of approaches that exist to solve this problem and the password manager companies have not used them.
- [23:43]
A
It is always just so fascinating to me about like, look, encryption is by far the most complicated thing that we cover when it comes to information security. And yet when you talk about things like this, it gets down to very, very simple problems. Like it really does. It really is fascinating. Another one that I thought was pretty fascinating was some of these password managers, you know, to make things look pretty and from a user experience perspective, they might fetch icons from websites that are saved. You found that a malicious server can trick the app into sending over a user's actual password instead of the website link that is used to grab these icons. How did such a simple label swapping mistake slip past? It feels like a decade of security audits. Because, look, your work, while fascinating, this is not the first time that something like this has happened for any of these companies. So while security audits happen time and time again, this one feels like, like I was just struck by what seems to be like a fav icon issue, which is like for any front end web developer, like something that is key, but I never thought that it would end up affecting the safety of a password.
- [25:01]
C
Yeah, it's actually one of my favorite attacks in the whole paper. Let me just say something about audits before I explain how the attack works. So a lot of these organizations have spent a lot of money on audits over the years. Auditors though, are always on a clock. And they're also maybe working within a restricted threat model. So may it's possible that none of the auditors were in a position to consider the malicious server as a possibility.
- [25:24]
A
That's a good point. Yeah. The audit is always the conditions that are presented at this point in time.
- [25:29]
C
Exactly. Then the second point there is that we have these incredible master students at eth. Giovanni Torrisi is the master's student concerned and you know, we give them six months. They're full time hacking around in these systems, trying to find things and they're very, very smart. So, so, you know, kudos to, to Giovanni and the rest of my team for, for finding these things. How does the attack actually work? It's, it's super simple. So items in the vault include things like passwords, but also, you know, the URL where the password should be used. And these two different objects are actually separately encrypted using the same key, same cryptographic key. And now we're talking about symmetric key encryption, the normal kind of encryption, rather than this fancy public key thing I was talking about earlier. So basically, when a user requests the. Let me get this the right way around. When a user requests the URL in encrypted form from the server, okay, what it's going to do is it's going to decrypt that URL. Sorry, decrypt the ciphertext, recover the URL, and then send the URL back to the server so the server can return the icon. Okay? That's the normal behavior. So you get a cybertext on the client, you decrypt it, it gives you the URL, and now you say, okay, please server, give me the icon for this URL. But what we can do in the attack is because these items are separately encrypted, instead of returning an encrypted URL, we can return an encrypted password because the same key is used and the metadata doesn't enable you to distinguish which one is which. And so now what will the client do? It will decrypt this object, recover what it thinks is a URL, and now send it back to the server, because that's the normal behavior, right? It doesn't know that it's got a password instead of a URL. It just blindly sends the thing back. Now, some of the clients actually do some format checking to make sure that it is a valid URL, but mostly. Okay, yeah. And that's it. So at the end of this attack, by just like swapping these two fields over, when the request comes, the server learns one of the passwords of the user for a particular website.
- [27:34]
A
Got it. Yeah. Wow, Fascinating stuff.
- [27:36]
B
Really simple.
- [27:37]
C
Really simple. And so like, what's the fix for this? Well, you should use different keys to encrypt different things, or you should include metadata, which is like integrity is like bound to the ciphertext so it can't be swapped around anymore. Or think of the vault more as a, a single object instead of a whole sequence of individual objects which are being encrypted and then encrypt the whole thing. That, that's slightly less convenient because now the user has to download the entire vault when they want to access a single item instead of going item by. But like there are, there are well known techniques in the kind of cryptographic world for solving these problems. These are not new, these are not unique problems, they're not new problems. So again, it's pretty surprising that more than one of the vendors had this specific issue.
- [28:22]
A
So another thing from the cloud security perspective that you write about in the paper is vault malleability. Instead of a password vault being like a single solid locked box, it's more like a collection of individually wrapped items. So why does this item level approach make it so easy for an attacker to cut and paste data from one part of the vault to another? I know this is something that you detailed and it was really interesting because I would think from a security perspective, I mean, I'm a novice compared to you and the researchers here, but I would think that this makes sense because you wouldn't want one big box full of passwords because God forbid an attacker does get in, suddenly they have 50 keys to every account that you could imagine. So you'd want to encrypt every key. But you have found that this item level approach has its own issues as well. So explain why this is also a problem that these companies need to be thinking through.
- [29:20]
C
So it's very closely related to the attack that we were just discussing. Basically, if you use the same key to encrypt every item separately, then you're going to be vulnerable to these swapping attacks, right? Because you know, the user or the client doing the decryption is kind of blind as to what actually is the type of data that I'm going to be getting back. So it's somehow intrinsic to using a single key to encrypt multiple different items, unless you're very, very careful. So the better approach is from a master key derive using like well understood cryptographic techniques, using something called a key derivation function, derive a new key for each item that you want to encrypt for each item of each type, say. And now you won't be able to do this swapping anymore, because if I try to decrypt, I'll end up using the wrong key and it shouldn't decrypt. Right. In combination, you need to use something called authenticated encryption, which means that the symmetric encryption you're using is not only providing confidentiality, but also integrity. So it becomes what's called non malleable. You can't play these games of moving things around or flipping bits or whatever. And this is like cryptography that's been around for, I don't know, 20, 25 years. This is not new stuff. This is bread and butter. It's, it's the same kinds of algorithms that are used in say, TLS these days.
- [30:46]
A
Okay, okay, so look, with, with any of these attacks, I'm, I'm wondering, like, look, this is research Obviously, as far as we know, this has not been seen in the wild. But you talk about this like, look, this has been around for 20 to 25 years. That that's lifetimes in this industry. So I'm wondering from your perspective, why haven't we seen this? Because, look, like you said, a lot of these have been so simple and a lot of the attacks that we see, whether it's something like a password manager or any other form of cloud infrastructure, I mean, we see simple attacks all the time. Why do you think that it's this one that really has gone undetected for decades?
- [31:36]
C
Well, one possibility is that the kind of standard model that people use for thinking about cloud services doesn't really include the possibility of the server being fully malicious. So people haven't kind of graduated to that level of threat model yet. The reason we went there is because we had all this experience from cloud storage, also from secure messaging system. So we did a lot of work analyzing things like WhatsApp and Signal and so on. And they are actually this kind of malicious server setting is standard by now. Right. We want to protect against the possibility of the WhatsApp server being compromised, let's say. So in our world of like cryptographic research, it's kind of standard. But I think maybe more with an industry focus, thinking of the possibility of your cloud service provider being fully malicious is more difficult to absorb and you know, but again, to go back to one of the early points I made, the vendors themselves said we are secure in that setting. Right. They made statements, you know, like, you know, we couldn't read your passwords even if we tried. Right. There's another interesting thing here as well, a little angle that's maybe worth emphasizing, which is that some of these products can be self hosted so you as an organization can run a Bitwarden server for yourself. And now your security is only good as your own security as an organization is.
- [33:00]
A
Right. I was going to say you might be introducing a whole new set of problems with self hosting.
- [33:04]
C
Exactly. And now what you're doing is you're concentrating all of this really sensitive data in one place inside your organization. You know, it's the old, the old, the old saying about why do, why do bank robbers rob banks? Well, it's because it's where the money is, or at least it's where the money used to be. I don't know if it's there anymore.
- [33:19]
B
Right.
- [33:21]
C
But like, you know, the kind of password managers in the self hosted setting, any organization that's doing that needs to Think, well, actually, are we good enough to protect this information ourselves or would be better off outsourcing that to an organization like bitwarden or a1Password who might do a better job than we can, given that, you know, they would then have a lot of resources to focus in on preventing breaches. Um, so that's like an interesting, an interesting angle to think about if you're a company using these kinds of products.
- [33:54]
A
So if I'm a company that wants to stand up a new password manager, you know, I want to do this from scratch and I'm. Now I've digested your research. What are some of the things that I need to demand before my product is released to the masses?
- [34:13]
C
I think in terms of like a brand new product rather than selecting an existing vendor, I would say there is actually a significant opportunity here for someone to come along and disrupt the market by offering truly end to end encryption in the malicious server setting and really deliver on this promise that you don't need to trust us not to look at your data. We can do it right, and here's why. And what's more, we can be subpoenaed by a security agency into providing the kind of access that would allow the data to be breached. What would you need to do in order to build that product? I think you have to really think from the beginning about how you're going to solve this public key authentication property, or the one that led to many of the attacks, or actually offer a much more kind of limited feature set. So for example, a lot of these vulnerabilities arise from the introduction of advanced features like sharing password recovery organizational structures within the password manager. So if you cut things right down and do a bare bones approach, then a lot of these issues are just not of concern anymore. But of course you want to offer a full set of features for your potential customers. So you do probably have to engage with this nitty gritty issue of how am I going to make sure that Alice can check that she's actually using Bob's key and not somebody else's key.
- [35:35]
A
Was wondering if we were going to hear from Alice and Bob during this conversation.
- [35:38]
C
Finally they made an entrance.
- [35:39]
A
Yeah, appreciate it. Fascinating paper. It's in our show notes, Professor. Really appreciate you hopping aboard to give us some insight into this paper and to what people need to think about as they decide what password manager they want to use.
- [35:56]
C
Thanks a lot, Greg. Pleasure talking to you. Thank you.
- [36:01]
A
Thanks for listening to Safe Mode, a weekly podcast on cybersecurity and digital privacy brought to you by Cybersecurity Scoop. If you enjoyed this episode, please leave a rating and a review and share it with your friends, your co workers, your sizzos, your CIS admins, your mom, your dad. Anybody that wants to know more about cyber security. To find out more information or to contact me, please look for all of our social media handles or visit cyberscoop.com thanks for listening. Check us out next week.