Re: Root password strength
On Wed, Mar 20, 2024 at 1:45 PM Pierre-Elliott Bécue <peb@debian.org> wrote:
>
>
> Jeffrey Walton <noloader@gmail.com> wrote on 20/03/2024 at 18:30:34+0100:
>
> > 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?
>
> My home sees plenty different people coming in. Some I trust, some I
> trust less. Also videocalls is a nice way to get a paper password
> recorded (and yes it happens).
So now you are arguing someone jumps on a Zoom call, and then displays
their passwords to the camera. If we are going to use far-fetched
examples, then write the password down with invisible ink. Recover it
when needed using the special pen provided with the junior spy kit.
> Same goes for company.
Companies generally have physical security on their assets. No one is
going to wander in the server room unsupervised. No one is going to
wander the cubicles lifting mouse pads and looking through drawers
without raising suspicion.
If someone is allowed to do those things, then the company's controls
are not going to be very helpful, and the company has bigger problems.
> > 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.
>
> Yes, but in that case there's another point, which is a contact mail
> address.
>
> And even this way it's problematic.
>
> > 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.
>
> Again, trying to mitigate one threat by creating a full range of other
> threats is the receipe for disaster.
I think you are throwing the baby out with the bathwater. Taking a big
problem (the network attacker) and reducing it to a smaller problem
(securing recovery codes) reduces risk.
I read about account compromises all the time. The creative ones use
SIM swaps to circumvent 2FA. I can't remember an instance of an
account compromise because a thief stole a wallet or safe.
> >> 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.
>
> Noone asks someone to remember more than two or three passwords. The
> rest belongs to a password manager.
Huh? This is discussed in detail in Peter Gutmann's Engineering
Security, <https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf>,
Chapter 7. In particular, pages 565-567 discussed the Selfish Security
Model.
> And people can do whatether they want, it doesn't make it anything other
> than a bad practice if it is one because 80% of a population does it.
Agreed. You have to have a security model and model the threats. I
don't see much of that going on in this thread.
Jeff
Reply to: