Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #268391 > unrolled thread

Root password strength

Back to article view | Back to linux.debian.user

Contents

  Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-19 15:50 +0100
    Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-19 16:00 +0100
    Re: Root password strength Dan Ritter <dsr@randomstring.org> - 2024-03-19 16:10 +0100
      Re: Root password strength debian-user@howorth.org.uk - 2024-03-19 16:50 +0100
        Re: Root password strength Greg Wooledge <greg@wooledge.org> - 2024-03-19 21:20 +0100
    Re: Root password strength Greg Wooledge <greg@wooledge.org> - 2024-03-19 16:10 +0100
      Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-19 21:30 +0100
        Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 06:40 +0100
          Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 07:10 +0100
            Re: Root password strength tomas@tuxteam.de - 2024-03-20 08:40 +0100
          Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-20 08:50 +0100
            Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 12:10 +0100
              Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 12:20 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 13:20 +0100
              Re: Root password strength jeremy ardley <jeremy.ardley@gmail.com> - 2024-03-20 12:30 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 13:10 +0100
                Re: Root password strength Dan Ritter <dsr@randomstring.org> - 2024-03-20 13:40 +0100
              Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 14:30 +0100
                Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 14:50 +0100
    Re: Root password strength Marco Moock <mm@dorfdsl.de> - 2024-03-19 16:40 +0100
    Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-19 20:40 +0100
      Re: Root password strength debian-user@howorth.org.uk - 2024-03-19 22:00 +0100
    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 16:00 +0100
      Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 16:20 +0100
        Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-20 16:30 +0100
          Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:10 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 17:20 +0100
              Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:50 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 19:10 +0100
                  Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:30 +0100
                Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:50 +0100
                Re: Root password strength Lee <ler762@gmail.com> - 2024-03-20 20:50 +0100
                  Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 21:00 +0100
                    Re: Root password strength Lee <ler762@gmail.com> - 2024-03-20 21:30 +0100
            Re: Root password strength <tomas@tuxteam.de> - 2024-03-20 18:50 +0100
              Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 19:50 +0100
          Re: Root password strength "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-03-21 20:40 +0100
            Re: Root password strength Jan Krapivin <daydreamer199005@gmail.com> - 2024-03-22 11:00 +0100
              Re: Root password strength Joe <joe@jretrading.com> - 2024-03-22 12:00 +0100
              Re: Root password strength "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-03-22 13:30 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-23 10:50 +0100
              Re: Root password strength Lee <ler762@gmail.com> - 2024-03-23 01:10 +0100
                Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-23 11:30 +0100
        Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 16:50 +0100
      Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:00 +0100
        Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 17:10 +0100
          Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 17:30 +0100
            Re: Root password strength Max Nikulin <manikulin@gmail.com> - 2024-03-20 17:50 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:00 +0100
              Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 18:40 +0100
                Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:50 +0100
                  Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 19:20 +0100
                    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:40 +0100
                      Re: Root password strength Jeffrey Walton <noloader@gmail.com> - 2024-03-20 21:20 +0100
                      Re: Root password strength Curt <curty@free.fr> - 2024-03-21 17:50 +0100
                  Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 19:40 +0100
                    Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 19:50 +0100
          Re: Root password strength John Hasler <john@sugarbit.com> - 2024-03-20 17:30 +0100
            Re: Root password strength Pierre-Elliott Bécue <peb@debian.org> - 2024-03-20 18:00 +0100
          Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 19:20 +0100
        Re: Root password strength Michael Kjörling <2695bd53d63c@ewoof.net> - 2024-03-20 17:10 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#268497

On 22 Mar 2024 17:26 +0500, from avbetev@gmail.com (Alexander V. Makartsev):
>     This is because of how IPv4 network address translation (NAT) works, to
> allow multiple LAN hosts to connect to Internet with single IP address
> assigned by Internet Service Provider (ISP).

A NAT router might also implement firewalling functionality, but _NAT
is not a firewall_.

Dropping traffic because it is prohibited (or because it's not
allowed) is _not_ the same thing as dropping traffic because the
device doesn't know what to do with it.


> Now, I don't want to scaremonger and feed anyone's paranoia, but for the
> sake of completion, there are known cases in history when router/firewall
> had vulnerabilities, or firmware flaws, or configuration negligence, that
> allowed perpetrators to 'hack' them, as in gain full access and control over
> their firmware and gain network access to LAN hosts.
> These cases are extremely rare nowadays and very hard to pull off
> successfully, especially if the device owner keeps firmware up-to-date and
> configuration tidy.

Sure, firewalls can have bugs (which may or may not affect security).
But so can software running on a PC. The solution is much the same:
use supported software, and install updates promptly. For a firewall,
get one where the vendor offers, or can at least be expected to offer,
upgrades for a significant amount of time.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#268493

On Fri, Mar 22, 2024 at 9:02 AM Jan Krapivin  wrote:
>
> The thing that bothers me are words: "any computer (and a fortiori any server) connected to the Internet is regularly targeted by automated connection attempts"

Change it to "any computer (and a fortiori any server) >>using IPv4
and directly<< connected to the Internet is regularly targeted by
automated connection attempts"
and yes, I'm 100% confident they're getting automated connection attempts.

Why the qualifier >>using IPv4 and directly<< connected?

The IPv4 address space is only 32 bits long.  Scanning 2^32 = about
4,000,000,000 addresses for an open port is easily doable.
The IPv6 address space is a bit harder...  Let's just say that 7/8th
of the IPv6 address space is reserved[1] so that means 2^125 addresses
would need to be scanned .. which just isn't going to happen.
There are ways for attackers to get the IPv6 address scan space down
to a reasonable number.  I probably don't know most of them..

What's the difference between "connected" and "directly connected"?
None of my computers are directly connected to the Internet.
Everything is hiding behind a firewall that supposedly blocks _all_
unsolicited traffic coming in from the Internet.
So however much I believe no unsolicited traffic is allowed into my
network is about how much I believe there are no automated connection
attempts to my computers.

> I am not tech-savvy. Can you say with 100% (90%?) confidence that there is no such thing? That home PC without SSH and whatever complicated is safe (rather safe) from "automated connection attempts"?

What make it more fun is that it is not only SSH that could allow an
attacker in. A quick & easy check is to look for open ports - eg.
  sudo ss -lptu

shows you all the programs listening for new connections (right now ..
10 minutes from now could be a whole different thing).
Except.. oops.. not _all_ the programs listening for new connections.
While writing this I tried

$ sudo ss -lwnp
State  Recv-Q  Send-Q   Local Address:Port   Peer Address:Port Process
UNCONN 0       0              0.0.0.0:255         0.0.0.0:*
users:(("atop",pid=186997,fd=4))

so there's atop allowing connections on a "raw" socket.  .. whatever that is.
And there's the non-tcp/udp protocols like GRE or IPSec (think VPN
tunnels) where connections might be allowed in.

> This thread reminded of that topic - https://forums.debian.net/viewtopic.php?t=154002

Indeed.  Is a firewall necessary or no?  Some say yes, some say no.

I look at a firewall as the place where you implement your basic
network security policy.  Should SSH be allowed in from the Internet?
NetBIOS?  how about SNMP?
I fall into the "some say yes" camp because I say the firewall is
where those questions should be answered.

Regards,
Lee


[1] https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

The assignable Global Unicast Address space is defined in [RFC3513] as
the address block
defined by the prefix 2000::/3. [RFC3513] was later obsoleted by [RFC4291].

[toc] | [prev] | [next] | [standalone]

#268498

On 22 Mar 2024 20:01 -0400, from ler762@gmail.com (Lee):
> The IPv4 address space is only 32 bits long.  Scanning 2^32 = about
> 4,000,000,000 addresses for an open port is easily doable.
> The IPv6 address space is a bit harder...  Let's just say that 7/8th
> of the IPv6 address space is reserved[1] so that means 2^125 addresses
> would need to be scanned .. which just isn't going to happen.
> There are ways for attackers to get the IPv6 address scan space down
> to a reasonable number.  I probably don't know most of them..

You are correct that the globally assigned unicast IPv6 address range
is a /3 out of 128 bits so 2^125 addresses. (2000::/3 out of ::/0.)

But only a tiny sliver of that address space is actually assigned to
anyone on the global Internet.

One can start by looking at the core routing tables and routing
announcements that form the Internet backbone. My guess, without
having looked, would be that you'd be looking at maybe _at most_ say a
/10 (although likely not contiguous) which actually routes anywhere at
all in the default-free zone. It might well be significant less than
that.

If you're already willing to do something like this, I strongly
suspect DNS in particular can help narrow the range down further. For
example, you could iterate over /32s and see which of those have any
reverse DNS set up by looking for corresponding delegations in
ip6.arpa. That'll miss some, but should catch the majority of actively
used assignments.

You can probably eliminate most /64s more or less immediately by
trying to reach _any_ address within each, because most /64s likely
won't be in use and therefore won't route.

Also, while addresses within each /64 look random, there's probably
ample opportunity to optimize the search there through for example EUI
assignment prefix tables and IPv6 address node portion generation
rules. And once someone connects to anywhere directly (that is, not
through something like a VPN concentrator which will replace with its
own outgoing address), whatever system was connected to at a minimum
has a known-good address to check.

And all this is just things I can think of right now. I wouldn't be
the least surprised if there are many more optimizations that can be
made by someone who actually spends some time looking into this.

So while scanning the IPv6 address space certainly is a larger
undertaking than similarly for IPv4, **scanning the IPv6 address space
is far less than 2^93 times harder** than scanning the IPv4 address
space as one might think looking only at _possible_ address length.
IPv6 addresses look random to the human eye, but especially in the
network /64 half of the address, they are far from randomly assigned.

Also, IPv6 typically being used with globally routable addresses
everywhere (as the Internet was meant to be) means that having good
firewalling is a _must_ in the present-day environment. If you do,
then having a globally routable IP address assigned to an end node is
not much of an issue.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

#268434

[Multipart message — attachments visible in raw view] — view raw

Michael Kjörling <2695bd53d63c@ewoof.net> wrote on 20/03/2024 at 16:16:41+0100:

> On 20 Mar 2024 15:45 +0100, from peb@debian.org (Pierre-Elliott Bécue):
>>> it should be like 32 symbols with special symbols?  Or this paragraph
>>> in a handbook is rather paranoid?
>> 
>> It's not paranoid.
>
> For 82 symbols (mixed-case alphanumeric plus 20 special characters),
> 32 characters is equivalent to about 203 bits. (82^32 ~ 2^203 or,
> expressed differently, log_2(82^32) ~ 203.)
>
> At a rate of 2^50 guesses per second, that will take about 3.6*10^38
> _years_ to go through. A widely agreed-upon figure for the age of the
> universe is around 1.4*10^10 years. Therefore such a password would
> take, very roughly, 10^28 times the age of the universe to brute
> force.
>
> Of course, with only 32 characters actually chosen, the character set
> size can in principle be reduced to 32, yielding 32^32 = 2^160
> possibilities. At the same rate, that would take about 4.1*10^25
> years; a measly 10^15 times the age of the universe.
>
> I sincerely doubt that guessability of such a password will be the
> weak link in overall system security.

I'm referring to the paragraph in the handbook, not the 32 random
character password.

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268435

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.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268436

[Multipart message — attachments visible in raw view] — view raw

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.

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.

Let's stop to overcomplexify, the best course of action for passwords
you need to remember are passphrases, and to this matter, Randall nailed
the matter properly.

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268440

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.

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

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

> Let's stop to overcomplexify, the best course of action for passwords
> you need to remember are passphrases, and to this matter, Randall nailed
> the matter properly.

Jeff

[toc] | [prev] | [next] | [standalone]

#268442

On 20/03/2024 23:19, Jeffrey Walton wrote:
> The network attacker cannot (yet) reach through a
> monitor and read a sticky note.

It may be visible during a video call performed from a smartphone.

[toc] | [prev] | [next] | [standalone]

#268444

[Multipart message — attachments visible in raw view] — view raw

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.

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

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.

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

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268447

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

[toc] | [prev] | [next] | [standalone]

#268451

[Multipart message — attachments visible in raw view] — view raw

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

Same goes for company.

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

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

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.

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268454

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

[toc] | [prev] | [next] | [standalone]

#268457

[Multipart message — attachments visible in raw view] — view raw

Jeffrey Walton <noloader@gmail.com> wrote on 20/03/2024 at 19:16:16+0100:

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

It's not far-fetched, it's actually something that's occurring from time
to time.

And that's easily preventable.

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

Companies regularly receive external personel, and it's quite easy to
have someone trespassing either a bit "oops sorry wrong office".

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

While one could just easily tackling the first issue without creating a
second one with a… password manager? I think you're spending a lot of
energy to recommend a dangerous solution because… who knows? instead of
agreeing to recommend a sensible and easy to deploy solution.

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

Yeah, using SMS/calls for MFA is not the best option. It's still one,
though. But the whole is still offtopic regarding password security
mechanisms (ie, don't flying write your password on a paper).

>> >> 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 because it's discussed in an irrelevant pdf means it's what one asks
in this thread?

Do you want to also bring in security practices from the 80's?

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

You don't need a threat model to understand why writing a password on a
paper is generally a bad practice.

But since you invest this much energy on defending a bad practice, I'll
let you keep the trend alone.

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268463

On Wed, Mar 20, 2024 at 2:34 PM Pierre-Elliott Bécue <peb@debian.org> wrote:
>
> Jeffrey Walton <noloader@gmail.com> wrote on 20/03/2024 at 19:16:16+0100:
>
>  [...]
> >> 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 because it's discussed in an irrelevant pdf means it's what one asks
> in this thread?

I don't think I would call Gutmann's book on Security Engineering "irrelevant."

Gutmann earned his PhD in Security Usability. He's written two books
on the subject. He also wrote a book on Security Engineering (cited
above). He participates in IETF Working Groups, and has authored a few
RFCs. I would not make the mistake of dismissing his work as
irrelevant.

> Do you want to also bring in security practices from the 80's?

Jeff

[toc] | [prev] | [next] | [standalone]

#268468

>
> You don't need a threat model to understand why writing a password on a
> paper is generally a bad practice.
>
> But since you invest this much energy on defending a bad practice, I'll
> let you keep the trend alone.
>

I have written down key passwords which I keep in my wallet. To get my
wallet, you will have to shoot me dead (of course, you may very well be
an expert pickpocket adept in the arcane arts of diversion).

Anyhow, here in the Gallic regions where spring is busting out all over,
this password question isn't even remotely related to the problem
statement, as much of my personal data was revealed to unknown sources
by a medical professional who fell for a phishing technique (my French
SSN, name, DOB, and god know what else through no fault or foible of my
own fell into nefarious hands). As a source of futile comfort, I can share
my grief with nearly half of the French population.

In more recent news, Pole Emploi, (which now goes by the moniker of 'France
Travail'), suffered a similar a data breach.

The only real remedy is to unplug yourself entirely from the system
(Unibomber-style).

À bon entendeur, salut !
-- 

[toc] | [prev] | [next] | [standalone]

#268456

Pierre-Elliott Bécue writes:
> 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).

I keep my passwords in a small book the size of a passport and I secure
it the same way I secure my wallet.  No visitor is going to get access
to it and no video call would get a look at it (if I did those).  Bruce
Schneier recommends this approach.  Most people are going to use
crackable passwords if you insist that they memorize them.  You can't
stop that by yelling at them.

I use a password manager for non-critical passwords, but I also write
them down in my password book.  I don't want to lose them in a disk crash
and I won't store anthing important in the "cloud".

The never write down a password rule originated back when you only had
one 6 or 8 character password which you used to log on to the VAX via
the VT100 in your cubicle.  People would stick a slip of paper with
their password on it under the keyboard where the janitor could get at
it.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268458

[Multipart message — attachments visible in raw view] — view raw

John Hasler <john@sugarbit.com> wrote on 20/03/2024 at 19:35:42+0100:

> Pierre-Elliott Bécue writes:
>> 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).
>
> I keep my passwords in a small book the size of a passport and I
> secure it the same way I secure my wallet.

And yet your digital persona is less secure than if you didn't do it.

> No visitor is going to get access to it

If you indeed put your wallet in a safe, then I can understand this
statement, otherwise it's just overly optimistic.

> and no video call would get a look at it (if I did those). Bruce
> Schneier recommends this approach.  Most people are going to use
> crackable passwords if you insist that they memorize them.  You can't
> stop that by yelling at them.

Bruce is excellent, I don't know whether he actually stated what you
said, but even if he did, being excellent doesn't mean that whatever he
says is golden.

And remembering a passphrase is easy, not easily crackable if well
chosen, and you don't actually need to remember more than two of them
(let's go with three if you have a PGP key).

> I use a password manager for non-critical passwords, but I also write
> them down in my password book.  I don't want to lose them in a disk crash
> and I won't store anthing important in the "cloud".

And then, backups were invented.

> The never write down a password rule originated back when you only had
> one 6 or 8 character password which you used to log on to the VAX via
> the VT100 in your cubicle.  People would stick a slip of paper with
> their password on it under the keyboard where the janitor could get at

I don't know whether this is true or false, and it doesn't really change
a thing.

As the other subthreads I'll leave things there, feel free to defend one
more time a bad practice regarding password management if you feel like
it.
-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268441

Pierre-Elliott Bécue writes:
> Writing down a password is a bad idea.

Why?
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#268446

[Multipart message — attachments visible in raw view] — view raw

John Hasler <john@sugarbit.com> wrote on 20/03/2024 at 17:21:20+0100:

> Pierre-Elliott Bécue writes:
>> Writing down a password is a bad idea.
>
> Why?

Because anyone falling on the paper with the password can do a lot of
harm. Because you can't control what this paper will become with
certainty, while it's easier to make sure you won't spell out your
passphrase from your memory randomly. Because if at some point you trash
it accidentally, then you're locked out (happily redefining a root
password is ~trivial even if one lost it, but if it's a LUKS password
then you're as good as done with your data).

And because it's a bad practice that people tend to generalize and then
in some not so remote future, a company's IT infrastructure becomes a
pile of ashes.

Don't write a password down.

-- 
PEB

[toc] | [prev] | [next] | [standalone]

#268453

On 20 Mar 2024 17:07 +0100, from peb@debian.org (Pierre-Elliott Bécue):
> Let's stop to overcomplexify, the best course of action for passwords
> you need to remember are passphrases, and to this matter, Randall nailed
> the matter properly.

If you're referring to https://xkcd.com/936/ I believe Diceware
predates that comic by over 15 years. Reinhold's page has a copyright
going back to 1995; the XKCD comic first appears in the Internet
archive in 2011. Even the domain xkcd.com wasn't registered until
2003, roughly coinciding with the Internet Archive's first capture of
Reinhold's page at its current URL.

The XKCD comic isn't bad, but it completely ignores the issue of just
_how_ the constituent words in the passphrase are chosen. Diceware
_explicitly_ addresses that.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.user

csiph-web