Re: Root password strength

[Jeffrey Walton <noloader@gmail.com>]

On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue <peb@debian.org> wrote:
>
> Jeffrey Walton <noloader@gmail.com> wrote on 20/03/2024 at 17:19:46+0100:
>
> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue <peb@debian.org> wrote:
> >>
> >> John Hasler <john@sugarbit.com> wrote on 20/03/2024 at 16:58:01+0100:
> >>
> >> > Pierre-Elliott Bécue writes:
> >> >> A phrase you will easily remember but that would be hardcore to guess
> >> >> through social engineering is perfect.
> >> >
> >> > Better is a random string that you write down.  When people try to
> >> > generate phrases that meet those requirements they usually fail.
> >>
> >> Writing down a password is a bad idea.
> >
> > I don't think that's true anymore. The threat being mitigated is the
> > network attacker. The network attacker cannot (yet) reach through a
> > monitor and read a sticky note.
>
> Mitigating a specific threat by adding a new one is not a proper way to
> handle a threat when one can avoid both.

What does your threat model look like?

Are spouses who go through a purse or wallet to retrieve a company
password a threat in your model? If that's the case, then you have
compensating controls to mitigate the threat, like physical security
on the office workspace.

> > It is also why its Ok for a system to generate a list of recovery
> > codes, and have the user print them and store them in a safe place.
> > The other option are those cursed security questions, which have been
> > insecure for about 20 years now (but developers have their arms
> > wrapped around).
>
> A recovery code is generally designed to troubleshot 2FA issues, not as
> a replacement for the first layer of security that a password is.

I believe recovery codes to regain access to an account due to a lost
or forgotten password predates 2FA. Most businesses I've worked with
use a Self-Service scheme, like recovery codes, to avoid the Help Desk
call. Some use the cursed security questions.

I am aware some European banks use Temporary Access Numbers (TANs) as
a form of 2FA. (I've never seen them used in the US). Each month a
[new] TAN is included with the printed and mailed account statement.
The "postal channel" is considered reasonably secure. Again, the
threat being mitigated is the network attacker, not a nosy spouse.

> And therefore if it were to circuvent this first layer, then no, it's
> not ok to print them, except if you indeed have a safe.
>
> But in general it's a better approach to avoid having to resort to
> printed password on a paper.

Humans are human. We have to understand their psychology and
limitations. Part of that is realizing a user cannot possibly remember
all the passwords required in the internet age. A big part of the
problem is what is known as the "Selfish Security Model for Password
Authentication." Each website wants a user to have an account and
manage a password. It is an impossible feat for folks to accomplish,
and that's why problems like password reuse across security domains
happens.

> >> Managing passwords through a password-store (eg pass, keepassxc,
> >> whatever tool you prever) is a great idea, but you first need to unlock
> >> your disk that hopefully you encrypted and then your session. And if
> >> your laptop is borken, then having a root password you actually can
> >> remember is better.
> >
> > I believe NIST now approves online password managers. But I don't
> > trust them given the number of data breaches.
>
> Yes, but I wouldn't dare use one.

Jeff