Reading the current password from memory = keylogger, I'm not worried about that. Reading every password I have or have ever had, including (I assume) encrypted notes and such? = keylogger on steroids.
You can't reset my online banking operation password by email.
You can't reset my crypto wallet passwords by email.
If you can read all of these from memory without me ever having interacted with the password, you can take all my money and then what do I do?
Malware that exists purely transiently in my system is a lot more likely to be successful and remain undetected, than malware that persists.
But passwords aren't just about you, they're about the server they're also stored on too. Without a password manager, how do you propose remembering unique fully random passwords for dozens to hundreds of services over the course of decades? And they must still be easy enough to enter that most people will actually use it. And also be trivial to change at will, for when (not if) the password database is compromised. And in fact you directly bring up the problem of that being worse for services you use extremely infrequently. So if you use it frequently the keylogger gains it anyway, and if you don't use it frequently then what's your usable system again? Also, are not the most important things you want taken the least also the ones that tend to be used the most frequently? And with access to your email and in fact all communication services used on that system you don't see how an attacker wouldn't just be able to "I forgot my password" for many if not most services?
>Reading the current password from memory = keylogger, I'm not worried about that.
You're not worried about your system being rooted? I'd say you have an awfully different set of priorities when it comes to security then most of the world even beyond HN.
Security is a battle of convenience. If your threat model is state actors, then it may well be worth the inconvenience to have your data secured in several different locations, running Tails OS on everything, scrapping your smartphone, and so on.
Totally leaving aside the argument you were in - multiple single points of failure are bad, and very different than the opposite of a single point of failure.
Having a SPOF means one thing will take you down. Having multiple SPOF means any one of those can take you down. Lack of any SPOF means no one thing will take you down, it will require multiple problems. 3 distinct options.
Edit: hm, too much time elapsed for me to edit the parent post
not fully random, but:
make up an algorithm that uses pieces of data that you know you can derive from some superficialities of anything you need a password for plus some some obfuscation function and some other data that you can derive or remember that is not related to the thing you need a password for.
e.g: the name of the site and the month you signed up in leet speek, rot-5'd and alternating letters, interspersed with symbols at some period related to a rhythm you like.
doing this gives you relatively strong passwords that you can reliably recreate while not needing to memorize them, that do not have an obvious pattern to them even if looking at them in mass, that have a very low chance of collision. you can remember a fairly complex recipe pretty easily ;)
depending on where your passwords are and what they're for, this might be preferable than storing them in one app that can compromise every password you have.
either way, someone only needs your important pw once. use multi-auth.
there's a point somewhere a bit faster than monthly-expiration where I would consider using a store and random gen in situations where i would otherwise not. really depends on you, what it's for, and what risks you need to care about the most.
[1] I'm not sure what they're called exactly, but basically all you do is enter a password and it generates your password using your password + site + KDF.
there are plenty of things that this isn't an appropriate approach for, and fwiw I wouldn't tell someone it would be a good strategy for all their passwords.
it can be useful when you have a set of longer lived passwords that you need to care about guaranteeing that the entire set can't be snarfed without holding you at gunpoint.
I don’t login to my online banking from my computer very often, nor do I login to government / tax services frequently. I’d be pretty upset if the credentials for these things (especially in the case of some banks, the second password required to perform any kind of transfer operation) got compromised simply because my entire password database got dumped from machine memory without having been used.
This of cause doesn't help against a resourceful and highly targeted attack, but that's less of a concern for me than some malware toolbox adding support for common password managers.
Even if an adversary has access to a machine, there is a difference if they can choose when/where to exploit/steal something, or if they have to wait for an action. If the adversary cant get persistence, a simple reboot of the machine might get them evicted and the keylogger is gone. That's just a simple example but it shows that things are more nuanced.
Apple for instance has efforts so that even root can't just debug arbitrary processes or unlock keychains of other users without them agreeing to it or disabling SIP.
It's about raising the bar and removing degrees of freedom for an adversary, so it becomes more dfficult. In the end of course systems can always be exploitable (given enough resources are allocated in breaking in).
Locks requiring more than 30 minutes are considered pretty much unbreakable (easier to break through the nearest wall).
This actually happened to someone at my company. But their passwords weren't compromised. If they were, I can't even imagine, the guys who took the machine were really trying to do whatever they could to ruin him and the company.
You make it sound like there's no mitigation at all for a password being compromised which isn't the case in practice.
If this ever happens, best plan would probably be to change your email password immediately, banks next, and freeze your credit as soon as possible.
But if it's ever breached I have no idea how you would get clear.
Ill also add that mitigating stuff like this was an early, easy use of separation kernels. They put the secret-protecting components, like disk encryption and VPN, in dedicated partitions outside Linux VMs. That worked well.
this is basically soft marketing of the skills they bring to the table. realistic/practical threat modeling not being one of them.
The high value things (bank, email, web hosting accounts) all have 2FA enabled.
The lower value ones, I can easily recover from a breach by simply resetting the PW via my email.
The only real threat I see is if you're storing passwords to things like encrypted containers (Veracrypt, TrueCrypt etc) but as you pointed out if they'd had something running on your system you're hosed either way.
My recovery codes are on index cards in a physical safe, and then I've got MFA via multiple devices (TOTP on Phone + yubikey for most things).
Or do you think that having both DBs on the same (possibly compromised) machine is too much risk?
Interesting idea. I had just been picturing a second keepass db with a different passphrase (or use a usb key with a keyfile kept offsite) but I like yours too.
(I'm also trying to brainstorm solutions scalable to non-experts so "&Ok fire up the CLI, we're doing GPG*" might work for me, but not everyone in my org :) )
I haven't found anything that I can self-host and allows me to have multiple "vaults". And I refuse to keep all my 2FA codes and recovery codes in the same place as the passwords, since that completely defeats the point.
When I asked 1Password about it, their response was that the functionality wouldn't be coming back in 7 because it wasn't a supported configuration -- it's called 1Password so users should only ever be remembering one password!
If Keepass's entire UX wasn't hot garbage it would be perfect. But here we are.
It can do this, and I don't see anything remotely resembling "hot garbage" in its UX.
That said, based on this report, the security model is significantly better, so the decision becomes do I care more about usability/being pretty, or security.
The never-ending trade-of between security and usability continues...
The "mobile-passwords" git repo doesn't have any password I don't use on my phone.
I'm not familiar with 1Password. How do you access these various "vaults" - you type a password, correct?
I guess I'm not following why multiple Keypass DBs with multiple passphrases is not acceptable for you, but several passwords in one app is?
(To be clear, I'm not saying your opinion is wrong I just want to understand - usable security is an interest of mine :) )
What functionality has gone from 7 and isn't coming back? Multiple vaults with distinct master passwords and not requiring their cloud backing?
You can set up multiple vaults, but it seems to store the master password for the additional vaults within the first, after the first time you unlock the additional vaults. So, effectively, it's a single vault -- access to the one gets you access to all.
Probably not a common scenario right now, but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
That's what full disk encryption and (eventually) hardware security chips and the like are for. It's not a threat model that has anything to do with password managers.
>Probably not a common scenario right now
It never can be, that's the point. Physical attacks simply do not scale like purely online attacks do, let alone attacks on centralized single points (ie., a central password database).
>but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
What? What tools "automate" stealing your notebook?? And also breaking through whatever physical security it has, like TPM or Apple's T-series chips or even just plain soldered on storage/memory/everything? The latter make repairs more of a PITA but they also make physical attacks significantly more difficult, even stuff like cooling memory and swapping (and encrypted memory based around tamper resistant security chips is a potential thing too).
Not the parent but I assume they meant a tool that traditional laptop thieves with little technical sophistication can use to easily extract valuable data from a machine after they have stolen it.
That only helps if you assume the laptop is fully powered off when it is stolen. If it's on or merely in "sleep" mode, disk encryption doesn't help.
> It never can be
What can never be? Laptops being stolen? A threat doesn't necessarily need to scale to be a problem as long as the gain from individual compromises is sufficient to make it worthwhile.
> What tools "automate" stealing your notebook?
The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
First, I said FDE and hardware security chips like Apple's T2 and mentioned stuff being soldered on and HSM backed encrypted memory. Yes, simple FDE and standard PCs can be subject to physical memory swaps and the like, but that becomes vastly more complicated and difficult with devices that use significant hardware security. This is no different then a modern iPhone, where merely having physical possession, even with the phone not powered off, doesn't mean it's trivial to access the data.
Second, you're engaging in the security fallacy of inventing theoretical attacks without considering economic cost or whether they pass the weakest point test in the threat model. The sort of scenario you've come up with is not that simple and not the sort of thing some random crook is likely to do, which is how this thread was started. But if you're dealing with a targeted physical attack by an actor with significant expertise and resources, there are far more trivial weaker points to go for. For example, they could just stick a pinhole camera looking down at your desk (or anywhere else you frequent with your notebook) and just record your password and avoid the whole mess. None of this has anything to do with password managers.
>What can never be?
Try reading the conversation? I responded to "Probably not a common scenario right now", which implies that it could someday become a common scenario. Ie., an attack that could be scalable. But physical end point attacks are inherently not scalable, just like anything else that requires actual boots on the ground. Resource cost is the framework of all security.
>The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
If the stealing isn't automated then it's not scalable and it's an entirely different scenario. And this makes zero sense anyway. You can't just download and run anything on a stolen quality notebook without breaking it's physical security first, which is increasingly non-trivial. The password manager database has absolutely nothing to do with any of this.
All it takes is for the _exploit_ to be automated (not the actual act of stealing laptops) such that any random person off the street can do it. Then a targeted attack is no longer necessary; crimes of opportunity become the larger threat.
[1]: https://www.digitaltrends.com/computing/microsoft-fixes-cort...
[2]: https://www.theguardian.com/technology/2017/nov/29/macos-hig...
If you have disk encryption you probably also have sleep mode lock the computer. So they still don't have access.
Is this true for Filevault? I know a lot of Mac owners who assume otherwise.
It's not just Mac users, I mentioned this issue in a meeting with an Apple sales engineer last month and he acted like you don't need to turn off a Mac to make it safer (he's not a security engineer so I don't really expect him to know how un/safe a running system with FileVault is). It may well be that the current OS and/or T2 chip makes it very, very hard to access the boot volume of a running Mac without a user's login but there's still a network exploit risk.
DMA access does sound plausible, but how can someone run a remote network traffic attack?
(I personally turned off any "smart wake" type of functionality)
I think the more obvious path is that if you have memory access, just wait for the decrypted contents to be exposed.
I always liked this idea: https://krypt.co/
Basically using an entirely separate device to authorize your access. 2FA devices still connect to the computer requesting access, I liked the idea that your phone act as the gatekeeper without ever touching your computer.
Problem is: It's a phone. Apple has done much but I wouldn't trust it either.
Basically even pretty good 2FA systems aren't at all full defenses if an attacker has root. They can help in very important ways to minimize the potential damage, to make recovery easier (since private keys are never compromised), to aid discovery/auditing, etc. But it's hard to avoid there having to be some trust in the client at the end of the day. And it's often a lot better to decentralize trust into client devices rather then something that can be centrally compromised. It's much harder for attackers.
Password Managers are no different, their raison d'etre is essentially trying to move the trust foundation more to clients. Client trust is a req though and any "compromise" that depends on controlling the client is uninteresting. They're basically a hack recreating PKI badly, but in a world where the technical foundations for a proper one didn't develop it's a good bandaid.