 If you're a longtime viewer of my videos, then you know that I am a very strong advocate of password managers. In fact, I think it's bordering on insanity to not be using them. But you won't see me recommending the kind of password managers that are shilled everywhere else like Dashlane or LastPass because those are proprietary cloud-based password managers, and you know what they say about the cloud. It's just some other guy's computer, often with very questionable security practices and when we're talking about a password manager where this guy isn't just securing your passwords, but thousands or millions of other people's passwords, it's a prime target. It's very likely to be attacked and it has a much larger attack surface than your very own offline open-source password manager like KeyPass or its many forks. Now, even though this is really secure software that I recommend forks of for storing your passwords, it's not like it's completely bulletproof. There are weaknesses that these programs have had over the years and certain things that you really need to be aware of, that you really need to take care of in order to securely store your passwords offline. So take this CVE, for example, right here, which isn't even really a CVE. It's not a real security vulnerability, but more on that later. A local attacker can make changes to the database security settings, including master password and second factor authentication within an authenticated KeyPass XC database session or to explain more simply, if you leave your KeyPass XC database logged in and you walk away from your computer, someone could walk up and they could change the password to your database, effectively locking you out of every single account that's stored in there. I mean, I guess in some cases you might be able to recover with a phone number or with an email or something like that, but crypto wallets. I mean, that stuff, if you know, if you are taking custody of your crypto and backing up your private keys that way, that stuff's going to be lost and potentially a lot of other sensitive information points in that database. Now, obviously, if someone has physical access to your computer or if they've exploited some flaw in your operating system in order to gain remote control of your computer, then we really shouldn't expect the password manager to keep your database secure while it's unlocked. Or hell, even if the database wasn't unlocked, right? You might have locked it and then walked away from your computer but left your computer logged in. An attacker could still delete that file or they could corrupt it in some other way to then prevent you from gaining access to your accounts. And this is explained in much greater detail on KeyPass XC's blog. And if you actually dive into the discussion on their GitHub, it seems like this CVE was opened in bad faith by, I don't know, some company that wanted to, I guess, bolster their name because a lot of security articles and news people will just pick up on CVEs and write articles about it without actually diving into it and understanding what the real underlying issue is or if there even is an underlying issue in the first place. But I guess it is still worth discussing. How can you avoid your database getting corrupted by a malicious actor and you losing access to your accounts? Well, you can very easily mitigate that by backing up your password database on a routine basis. That way, if it's deleted or corrupted in some way, you can just restore it from a backup and really just make sure your computers that you're using KeyPass XC on have a good security posture, keep the OS updated, use minimal well vetted software to reduce process sprawl and your attack surface and so on. Now, let's take a look at a real security vulnerability that got patched a few months ago. So this was a problem in KeyPass and not any of its forks. As far as I know, it wasn't a problem in KeyPass XC at the very least, but it was a flaw where a local attacker could read the password, the master password that you type in to unlock the database from memory. So again, in order to pull this off, it requires either physical access to the machine that you're running KeyPass on or it requires privileged remote access. This is a screenshot of what it looks like when you're running. Well, this is I think software that was made to specifically exploit it. But when you're looking at memory, you can see some leftover strings as the person is typing in the password or at least most of it, not the first character apparently. And then this is the proof of concept program that can scrape the, you know, basically scrape through the computer's memory to try to get the password. And this is an example of it running here. And then you can see it basically gives you the Cret master password from all of the various characters that were read from memory. And it even says down here, should you be worried, it depends on your threat model. If your computer is already infected by malware that's running in the background with the privileges of your user, this finding doesn't make your situation much worse because of course they could have keyloggers, they could have all kinds of other stuff in order to sniff the password if they've already taken over your system. But even something like this could be mitigated by using multi-factor authentication like a UB key to unlock your password database. That's going to help, you know, mitigate this type of attack because the attacker would need your UB key in addition to the master password in order to unlock your database. But even this, you know, pretty much non-issue, I mean, was enough for the devs to actually fix the problem in KeyPass 2.5.4 or 2.54. And if we take a look at the security issues tab of KeyPass.info almost every other security issue, if you can even call it that besides maybe the header authentication issue here that KeyPass had several years ago everything else ultimately falls into an issue with the operating system or something else that is outside of KeyPass, something outside of the password manager. Take this for example, so the automatic update vulnerability. So they explain here that KeyPass doesn't actually update automatically, okay, the end user has to manually update their system. There is an option, an optional option for KeyPass 2. Check and see if there is a new version available out there, but it doesn't download it and install it for you automatically. Again, that's on the end user to do. And there was again kind of a security issue where it was doing this check over HTTP and a man in the middle attack could be done on that, right? So someone could man in the middle that authentication or that check for a new version and say that there's a malicious newer version out there, right? Go down the KeyPass version 69 and if you as an end user Google that then more likely than not, especially if you're actually using Google you're probably going to end up on a malicious webpage where you download a Trojan version of KeyPass version 69. So you see when you're getting into the task of storing your own passwords you've really got to get serious about your overall digital security. You should really think when you're updating your software, right? Am I getting this software update from a reputable place? I mean really you should think of storing your passwords like storing your crypto or like other people store crypto if you don't know anything about that because usually when people who are a bit more tech savvy want to keep a large cryptocurrency holding safe they're going to take some extreme measures like air gapping their wallets so that they never end up connecting to the internet in the first place. It's pretty hard to hack something when it never connects to the internet. And the same thing would be a great idea for a password manager. Personally this is one of the things that I really really like about CubesOS because they have a domain or like a specific Cubes VM called the Vault that was specifically made for this. The Vault does not have internet access. It doesn't have any direct connection to the outside world. I'm pretty sure that like USB storage devices can't be connected to it at least not very easily. So even if one of your other VMs were to get compromised like the social media or this Discord you know this might get compromised. Maybe your work is going to get compromised because somebody's targeting you through your organization. It's not able to like if malware infects any of these VMs it's not able to affect the Vault at least not without escaping the Zen hypervisor. So that's something to think about. If you're questioning the security of your password manager like obviously with the cloud based stuff you know all you've got is trust me bro right. Trust whatever this company is saying as far as how they store your passwords but with self hosted self custody passwords you can take security as far as you want to take it. Much further than a lot of these third parties are if you want to and more likely than not you're going to learn a lot about digital security in the process.