
Password Managers: Under the Hood of Secrets Management - thenaturalist
https://www.securityevaluators.com/casestudies/password-manager-hacking/
======
gruez
The threat model used for this assessment pretty much never happens in
reality. If you're arbitrarily reading memory using software, then you can
also install a keylogger or steal clipboard contents, which the authors
themselves concede no password managers can protect against. So what's really
being evaluated is how well password managers can withstand physical attacks
(DMA/coldboot), which isn't a concern for 99.999% of people. Furthermore, if
your attackers had physical access, they could very well install a physical
keylogger to steal your passwords, bypassing your password manager's
countermeasures entirely.

~~~
DanHulton
Except for the case where they entire password DB can be decrypted and read
(in the case of 1Password 7, at least). Sure, a keylogger could eventually get
all of the passwords I use on the regular, but it couldn't get _literally
every_ password I have and in a nice, neat format along with where the
passwords are used.

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.

~~~
xoa
> _Sure, a keylogger could eventually get all of the passwords I use on the
> regular, but it couldn 't get literally every password I have and in a nice,
> neat format along with where the passwords are used._

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.

~~~
kaens
> how do you propose remembering unique fully random passwords for dozens to
> hundreds of services over the course of decades?

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.

~~~
gruez
What you're basically describing is no-sync password managers[1], with all of
its disadvantages (password changes/rotation, username storage, etc) but also
with security by obscurity instead of a proven KDF.

[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.

~~~
kaens
correct, the point of doing something like what i'm describing is to have a
system for keeping / creating N unique passwords stored _only_ in your head,
in a way that provides an acceptable amount of strength, avoids disclosing all
of your passwords if one is compromised, and doesn't require you to be a
savant of long-random-string memorization.

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.

~~~
jsutton
Your strategy doesn't negate the need for a password manager for all of your
non-essential web accounts.

------
iambateman
> "First and foremost, password managers are a good thing. All password
> managers we have examined add value to the security posture of secrets
> management"

This is the point for 99.9% of people. If you're at risk of having someone
attack you and your digital life in a targeted way, perhaps consider
evaluating the security implications of each password manager.

Otherwise, pick any damn password manager and focus on something else.

~~~
seppin
> Otherwise, pick any damn password manager and focus on something else.

People make the same mistake at the gym. "Which workout plan should I use?"

Any plan. Any of them.

~~~
iamkroot
I've always said that the best workout plan is the one that you'll actually
do.

------
pier25
Here is the response from 1Password:
[https://discussions.agilebits.com/discussion/comment/493044/...](https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044)

~~~
Ajedi32
Interesting, so their augment is essentially that the memory-safety provided
by the use of a memory-managed language is more valuable to them from a
security standpoint than the memory scrubbing capabilities afforded by a
lower-level language?

~~~
mediocrejoker
I think that's a fair characterization of their response, yeah.

As someone in that thread pointed out, I would say that the onus should be on
the OS SDK to provide memory management primitives specifically for the
purpose of security that can be zeroed out after use.

They also point out that the threat profile is someone who can read your
system memory when 1P is locked (serious compromise already), but is unable to
read it when it's unlocked (otherwise why bother reading it when locked),
which is a pretty small set of use cases.

~~~
Ajedi32
> They also point out that the threat profile is someone who can read your
> system memory when 1P is locked (serious compromise already), but is unable
> to read it when it's unlocked

I can think of at least one situation where that would be the threat profile:
someone steals your laptop.

Not a super common scenario, but not exactly unheard of either.

~~~
huzaif
That makes it kind of an edge case:

1- User uses the laptop and logs into 1P successfully then locks it. 2- Hacker
steals the laptop and uses it without a reboot. 3- Hacker hacks the
windows/mac os password to logon. 4- Hacker dumps process memory for 1P.

~~~
loeg
Coldboot attacks do not necessarily require breaking Windows/Mac password. I
agree it is unlikely for most individuals, though.

------
SloopJon
Reposting my comment from the previous submission:

From a Washington Post article on this study: "LastPass had me speak with its
top technical executive -- but it also got [lead researcher] Bednarek banned
on Bugcrowd, the site for researchers to report flaws, because he disclosed
the bug to me."

[https://www.washingtonpost.com/technology/2019/02/19/passwor...](https://www.washingtonpost.com/technology/2019/02/19/password-
managers-have-security-flaw-you-should-still-use-one/)

More from CyberScoop:

[https://www.cyberscoop.com/bugcrowd-adrian-bednarek-
lastpass...](https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass/)

------
Ajedi32
Very interesting results. I'm not sure I agree that it's necessary to keep
password information out of memory in an unlocked password database, since an
attacker could always just extract the decryption keys from memory and use
those to decrypt the database on disk to get the same information.

The other findings about sensitive information remaining in memory even
_after_ the password managers are locked are concerning however. It'd be great
if the article included a link to the CVEs or bug tracker issues for these
vulnerabilities so we could keep track of whether or not they've been fixed.

~~~
dontbenebby
>The other findings about sensitive information remaining in memory even
_after_ the password managers are locked are concerning however.

Sounds like a reasonable countermeasure is to quit the manager when not in
use.

After all, I'd need to enter my password if I was "unlocking" or restarting
the app either way. (At least in my manager)

------
peterwwillis
I don't care if the password manager is secure against local attacks, because
the average user will still be vulnerable without extensive security policies.
Sure, there's the "anything is better than nothing" argument, but if we're
just throwing darts at the wall, deciding which dart board is nicer isn't
going to affect your score.

If you can read local memory, you can probably write to (at least other)
memory, and then it's a short hop to content injection and session hijacking.
Erasing key material from memory or preventing its misuse then only seems
useful against cold boot attacks.

------
nickjj
I really like the pass manager (CLI):
[https://www.passwordstore.org/](https://www.passwordstore.org/)

It stays encrypted at rest on your machine protected by GPG keys and when you
want to access a password you can choose to copy it to your clipboard for 45
seconds or print it to stdout.

No subscription services, and everything stays local on your machine, but you
can easily sync it to other devices using whatever file syncing service you
want since it's just encrypted files on disk.

~~~
folkhack
This was brought up last time - but even having something like the path
"./Banking/bankofamerica.com" visible on the filesystem is a disclosure of
sensitive information, even if the password is encrypted at-rest. Otherwise I
love the idea of *nix based philosophy for password management =)

~~~
nickjj
The path does leak some information but in that case the bad actor would also
need to know the username along with the password (both of which would be
encrypted).

But you have to ask yourself. Who are you protecting against here? Are people
browsing around your laptop / workstation without you monitoring what they're
doing?

If someone has your machine without your consent, then you're pretty much
screwed because 99.99999% of people will leave themselves logged into things
like gmail which requires no password to access it once the machine is powered
on. It's basically this xkcd scenario:
[https://xkcd.com/1200/](https://xkcd.com/1200/)

~~~
folkhack
> Are people browsing around your laptop / workstation without you monitoring
> what they're doing?

Nope - but the industry that I work in constantly assumes "bad actors" are
present. Although it's not perfect - everything is 2FA, all disks on laptops
encrypted, there are strict rules in dealing with secrets/sensitive
information, etc. My main concern is if someone were able to do a rip of my
home directory.

Trust me - there's a TON of room for improvement, but doing some general
protection against someone with "shell" access is something I'm in the
practice of... it's the same reason I carefully manage what ends up in my
.zsh_history or .bash_history =)

> If someone has your machine without your consent, then you're pretty much
> screwed

Agreed. Encrypt the disk (I trust LUKS), lock your machine when not in-use,
ensure it shuts itself down if a password is "fat-fingered" more than twice,
use solid passwords with good complexity, use 2FA when you can/should, etc.

------
r1ch
I wonder if password managers should consider running under a higher
privileged account (eg administrator). This would prevent lower privileged
processes (eg your typical drive-by malware) from being able to get a handle
to read memory without also using a privilege escalation technique.

~~~
briHass
That's exactly how I have KeePass configured on Windows 10. I've set my
keyfile (additional entropy for the encrypted password DB, combined with
master password) access to only allow the Admin account. Then, I set
keepass.exe to always run as Admin, which of course prompts the UAC whenever
it is launched.

This actually accomplishes a few things:

* The keyfile is safe from processes launched using the standard user account (i.e. non-elevated). Malware accidentally launched by 'me' can't read it.

* Keepass.exe is running in the admin process space, which protects its memory from processes running in non-elevated space.

* Launching admin-space Keepass, and seeing the UAC prompt, Microsoft includes information about how the exe is signed -- which Keepass is -- that allows me to verify every time that I'm not launching a bogus keepass.exe.

* The password database file is still in user-land, so it can be synced with standard cloud sync tools. It is worthless without the keyfile though, even if my master pass ever slipped.

------
thecopy
I just moved from LastPass to 1Password7, and this sentence will make me
consider moving back:

> Surprisingly, we found that it is less secure in the running state compared
> to 1Password4. 1Password7 decrypted all individual passwords in our test
> database as soon as it is unlocked and caches them in memory, unlike
> 1Password4 which kept only one entry at a time in memory. Compounding this,
> we found that 1Password7 scrubs neither the individual passwords, the master
> password, nor the secret key (an extra field introduced in 1Password6 that
> combines with the master password to derive the encryption key) from memory
> when transitioning from unlocked to locked.

That is unacceptable, what type of developers do they have?

~~~
SlowRobotAhead
If it’s an interesting annecodte to you, I moved myself an 5 people in my
company from 1Pass v4 to LastPass, no complaints from anyone and the iPhone
integration is unbeatable.

Altogether I’ve moved 100 people to LastPass and some of those users have been
not-exactly-power-users, yet, zero complaints from 100 people. A year later
almost every single one is still using and the downstream effect of
children/friends/kids is surely in the hundreds. They owe me a shirt or
something really!

LastPass isn’t perfect but it’s pretty great for the price. What made you
switch to 1P v7?

~~~
throwawaymath
Are the people using LastPass commenting on how nice the interface is, or are
they just not saying anything at all?

I have to use both LastPass (enterprise) and 1Password 7 (personal). The
experience is pretty incomparable: the LastPass user interface and browser
extension are _abysmal_ , whereas 1Password is very enjoyable. On the most
recent version of Chrome, the LastPass extension is slower, less intuitive and
less organized than the 1Password extension. 1Password also has more features
and a fast desktop application for macOS.

Note that I'm not saying LastPass doesn't work. It _works_...but it's an
incredible pain for me to use every day at work after using 1Password at home.
I think the design sucks, to put it bluntly.

~~~
SlowRobotAhead
I've had a few questions about interface, but for the most part it's intuitive
and I've had very few questions even from older people. Not hearing anything
is a good sign.

I've had none of the UI issues you have (Firefox, Safari) and have heard none
from any user. Weird!

~~~
ken
Did they do an overhaul recently? Maybe people are remembering an older
version.

I had to use LastPass at work, maybe 2 years ago, and I can confirm, it may
have had the worst user interface (both in terms of aesthetics and usability)
of any webpage I've ever had to use. I simply couldn't believe any self-
respecting developer shipped that.

------
hsnewman
So why don't these tools use CryptProtectMemory to protect the memory:
[https://docs.microsoft.com/en-
us/windows/desktop/api/dpapi/n...](https://docs.microsoft.com/en-
us/windows/desktop/api/dpapi/nf-dpapi-cryptprotectmemory) ?

~~~
Someone1234
Your own article tells you why:

> Using CryptProtectMemory and CryptUnprotectMemory for password encryption is
> not secure because the data exists as plaintext in memory before it is
> encrypted and at any time the caller decrypts it for use.

In order to benefit from CryptProtectMemory you have to carefully lifecycle
strings in and out of secure storage as needed; this wouldn't mitigate some of
the issues presented in the article.

~~~
loeg
C# has a core class to safely lifecycle protected strings. The decryption key
is only resident in kernel memory, so a dump of the user process when
protected theoretically cannot read the protected string contents. (Of course,
this doesn't prevent against a cold boot attack unless the keys are escrowed
in a TPM.)

[https://referencesource.microsoft.com/#mscorlib/system/secur...](https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs)

------
gabriel34
Keepass does have coutermeasures against clipboard sniffing (auto-type instead
of copying to clipboard) and keyloggers (Two-Channel Auto-Type Obfuscation).

These are effective against non-specialized attack software.

[https://keepass.info/help/v2/autotype_obfuscation.html](https://keepass.info/help/v2/autotype_obfuscation.html)

------
jrockway
Any computer program is going to have data in RAM. It's up to something else
to protect that. (This is why ARM machines have that encrypted RAM, this is
why real security software runs in some sort of tamper-proof area, etc. This
paper shows the general "whatever" attitude that general-purpose computers
adopt towards attacks where someone has physical or root access.)

~~~
phishfi
Can't a password manager use the TPM to encrypt/decrypt the passwords in real
time, a la Windows Hello?

~~~
loeg
It seems like a TPM would be a good way for the OS to implement
CryptProtectMemory.

------
whelchel
Can anyone comment on how concerning this is? It doesn’t seem good. I was
considering updating from 1Password4 to 7 and biting the bullet on the
subscription model. Based on this case study it seems 7 is a security
regression trade for UX improvements. Now, I’m considering Keepass or at least
waiting to hear some responses from providers involved.

~~~
peterwwillis
It's not a concern. As an average user your only consideration is "Do they
keep my passwords safe on the disk?", and the answer is "yes" for all of them.

If you work for the NSA and cover yourself with a tinfoil blanket to enter
your passwords, just lock and close the password manager completely after
you've used it to login to a service, and you're all good.

~~~
UnFleshedOne
Why is having _all_ password being unencrypted available to _all_ processes
running under the same user context considered an esoteric attack?

Basically we are one browser exploit away from using ad-networks to steal all
your passwords (from 1Password7).

~~~
peterwwillis
I don't think it's an "esoteric" attack, it's just that the cost-benefit of
locking things down a tiny bit more isn't significant. We're always one
browser exploit away from malware that can do whatever it wants.

Ok, so say the malware couldn't access all your passwords _immediately_. It's
just going to sit on your computer and collect them (and existing sessions) as
you use them, or force you to re-auth and then collect them. And if it's
highly prized info, the malware will eventually get updated with a privesc to
go around the user context. This is what malware has been doing for years, and
nobody notices until exfiltrated passwords start getting used.

~~~
UnFleshedOne
By the time I go through all my passwords at least once, browsers and OS will
release multiple rounds of patches and potentially fix the exploit in
question. This is still preferable to uploading whole database...

~~~
peterwwillis
I think the cost-benefit differs. If the whole database is leaked, you just
rotate everything. Only the stuff that has been used (which tipped you to it
being leaked) has a real impact. Nobody's going to compromise every single
account you have all at the same time, unless they're specifically targeting
you, in which case they're going to get everything anyway. So on balance, it
doesn't matter if some random malware gets 1 of your passwords or all of them.
The real-world impact is about the same: limited. The cost of worrying about
the extra security outweighs the benefit.

Another way to go would be tiers of password managers. Even if all of their
unlocked integrity sucks, you can have one manager that keeps your most
sensitive accounts, and another manager for the rest. You rarely unlock the
sensitive one, and after you log in, you unlock it and exit it. Now you have
much better opsec with very little additional cost.

~~~
UnFleshedOne
Imagine a malware ad, using zero day browser exploit that is designed to dump
1password db at scale and upload it for further processing. As an attacker you
can run this for a while (while exploit is valid) and then compromise
thousands of bank accounts you have collected. As many as your scripts
support.

------
nothrabannosir
What I don’t see this paper focus on is security offered by the OS.
Historically and commonly, for “normal people” apps, we’ve only been able to
rely on one kind of compartmentalisation: memory is not readable between apps.
However, any file the user has access to is fair game for any app. This is a
Bad Time for any password manager, or really any app (think e.g. about your
email cache in a thunderbird profile, or Firefox session tokens which can be
siphoned , etc).

For ages, on Unix this could be solved with users and daemonisation. Later
came SELinux which is criminally underused.

In the popular OS market, for a while there was flocker, on OSX. It used event
hooks in the kernel to allow fine grained control over filesystem access,
locking certain dirs down to certain apps. The app was bought by some
enterprise offering (f-secure) and taken offline. The creator (Jonathan
Zdziarski) was then hired by Apple. Recently, similar features have been
rolled out by Apple natively for OSX. Try reading your iMail or calendar cache
using the terminal: you’ll get an iOS-like pop up window asking you if this
app has permission to your mail, or contacts. This is a step in the right
direction.

All that’s left is for Apple to allow the user (or app developers) to specify
such locks ourselves. This was already possible with flocker, but
unfortunately that’s nowhere to be found, anymore. Perhaps it’s possible for
apps delivered through the App Store? This would solve the problem that a
password manager offers any process access to your full (encrypted) password
DB, which is a pretty serious problem (makes the master password too
valuable!).

Given the direction things are moving in, and the hire of Jonathan, I’m very
hopeful this will eventually arrive. It would be a _tremendous_ win for
security on OSX. This everything-goes mentality of FS access has been a pet
peeve of mine for over a decade. :) and, tbh, I think it’s a much more
relevant attack vector than some process “reading memory”.

[https://techcrunch.com/2017/04/06/f-secure-buys-little-
flock...](https://techcrunch.com/2017/04/06/f-secure-buys-little-flocker-to-
upgrade-its-mac-security-play/)

------
ComputerGuru
It doesn't help that many of these password managers are written in high-level
languages (some are Electron based, ffs!) where you have zero control over the
actual allocation (and subsequent clearing) of bits. The best you can do is
overwrite the memory and hope that the framework/runtime/GC does the right
thing.

~~~
magnat
For .NET, there is SecureString class [1] which provides reasonable protection
against stealing secrets from memory. Not many password managers (if any) use
.NET, though.

[1] [https://docs.microsoft.com/en-
gb/dotnet/api/system.security....](https://docs.microsoft.com/en-
gb/dotnet/api/system.security.securestring?view=netframework-4.7.2)

~~~
Someone1234
Here's the source code if anyone is interested in how it works:

[https://referencesource.microsoft.com/#mscorlib/system/secur...](https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs)

------
calibas
I had a client who required me to use LastPass because he didn't want me to
see the the actual password. I was wondering how that was even possible, maybe
some kind of magic I didn't know about. Turns out it's trivial to get the
passwords using a browser's built-in inspector.

------
asdz
clipboard sniffing? I remember years ago, there's some tools that you install
and it will automatically encrypt all the clipboard content to prevent
sniffing.

Nowadays, a password manager can't even do that?

* might not be straightforward as it install some DLL inject stuff

------
pier25
In the iterations it says that LastPass requires "100,100" iterations to brute
force in non running state, but in the image table at the end with colors it
says "5K" for LastPass.

Is this a mistake or am I missing something?

~~~
TheDong
> requires "100,100" iterations to brute force

That phrase doesn't really capture what iterations means there. How you said
it makes it sound like you only have to try 100k computations to brute force a
valid answer, which is certainly not true.

It's talking about key stretching / key derivation [0].

That is not 100100 iterations to brute force it, that is 100100 iterations of
PBKDF2-SHA256 applied to the password you type in as the master password.

It does look like the tables are not identical. However, since lastpass's docs
[1] say it's 100100 (and configurable), I'd say that's likely the accurate
default value.

[0]:
[https://en.wikipedia.org/wiki/Key_stretching](https://en.wikipedia.org/wiki/Key_stretching)

[1]: [https://support.logmeininc.com/lastpass/help/about-
password-...](https://support.logmeininc.com/lastpass/help/about-password-
iterations-lp030027)

~~~
pier25
Thanks for the explanation

------
megakid
I just migrated from LastPass to 1Password7, happier with the GUI/interfaces
but I hope they fix these issues up to at least make it harder to extract the
passwords when in a locked state.

~~~
selectodude
One thing that is nice about 1Password going to a subscription model is that
they have to work for your business every month or every year. In the comment
they made, they talked about looking into a transition to Rust, which has
better memory security capabilities.

------
NoblePublius
I use Dashlane. Am I dumb? Lastpass looks better.

------
illumin8
These evaluations all happened on Windows, which is notoriously bad at
protecting memory from snooping by other processes.

Does anyone know how well MacOS versions of all the password managers would
have fared? I suspect the JavaScript based password managers like LastPass
would fare similarly, but it would be interesting to see if 1Password has
better security on MacOS than Windows.

~~~
bndw
MacOS isn't much better. I just tried it myself using fridump[0] and was able
to see plaintext secrets when dumping memory.

But as pointed out above, if someone has access to dump your machine's memory
then you've got bigger fish to fry.

[0]
[https://github.com/Nightbringer21/fridump](https://github.com/Nightbringer21/fridump)

------
ashton314
How much does this apply to secret managers like [Hashicorp
Vault]([https://vaultproject.io](https://vaultproject.io))? I get it it's more
than "just" a password manager.

------
entity345
Are there any decent password managers that do not charge monthly fees?

I don't mind paying to buy a good tool but the Saas model is getting out of
hand.

~~~
qudat
I use [https://www.passwordstore.org/](https://www.passwordstore.org/) and
love it. It's a lot more manual than lastpass or 1password but all I care
about is keeping my devices synced, being in full control of my data, and not
having to pay anything.

~~~
kdtsh
It's so good. It's incredibly simple and fast (it's just a script which works
as a front end to git and GPG); it's very well documented and there are only a
few commands you need; devices are sync'd by way of git; it's got a heap of
add-ons, including an OTP generator. There's even a great iOS app, PassForiOS,
which also handles OTP 2FA (the only downside to the app is that you have to
clone from an existing pass repository, but that's not a big deal unless you
don't have a computer or you were planning on starting to build your password
database on your phone). Never used it on Windows or Android so I can't say
what it's like there, but if you're on macOS, a combination of GPG Suite,
pass, and the default Terminal make password management easy.

edit: there's the unfortunate fact that the names of files in which passwords
are stored are in plaintext, since it's all ordinary files and directories.
pass-tomb is supposed to be a good way of encrypting your .password-store
directory, but I don't think this is compatible with the iOS app. Still, not a
serious problem for my use case anyway, and a solution is available if I'd be
willing to forego the iOS app.

------
mediocrejoker
Why did they evaluate 1Password v4 instead of v7?

~~~
velcrovan
If you read the whole thing, they evaluated both, and found that v7 is
actually far worse than v4.

~~~
mediocrejoker
Yes sorry I replied without reading the entire paper. Would be good to see
some responses from the companies.

edit: looks like AgileBits has already responded

[https://discussions.agilebits.com/discussion/comment/493044/...](https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044)

------
everdev
> First and foremost, password managers are a good thing. All password
> managers we have examined add value to the security posture of secrets
> management, and as Troy Hunt, an active security researcher once wrote,
> “Password managers don’t have to be perfect, they just have to be better
> than not having one”

I would assume that a pseudo-random moderately strong password per site stored
in your brain would be more secure than a random strong password that's stored
electronically and vulnerable to attack, but maybe not?

~~~
ocdtrekkie
Password managers are universally terrible, but until security experts stop
telling people to use them, everyone's going to dump their sensitive passwords
into incredibly poor apps written to put all your access in one place secured
by one single password.

A lot of password advice today is bad. You only should be making valuable
passwords (those that control sensitive data or access) unique. Forum accounts
do not need that level of security and you waste cognitive power by doing so.

Banks, email accounts, and a handful of others are the only ones worth truly
securing. And passphrases can be incredibly easy to remember, unlike
passwords.

~~~
hombre_fatal
> Forum accounts do not need that level of security

Though it's also in the platform's best interest to defend itself from weak
passwords because there are usually a lot more defenses against fresh accounts
than existing accounts that get taken over. We're seeing websites becoming
more and more proactive here like rejecting passwords that appear on
haveibeenpwned.

Also, I recognize your username from your extreme stance against password
managers in the past and you seem to make the mistake of not acknowledging
trade-offs. I think it weakens your point, especially when talking about end-
user security where 90%+ of people are reusing passwords, not debating whether
they should use a password manager or roll their own physical password pad
scheme.

If you reject current password managers, can you envision a digital solution
that _would_ satisfy you?

~~~
ocdtrekkie
Why is a "digital solution" a requirement? Storing all your passwords on a
computer, or worse, in the cloud, will never be a good solution.

