Re: Root password strength

[Michael Kjörling]

On 22 Mar 2024 20:01 -0400, from ler...@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?”

Re: Root password strength

[Michael Kjörling]

On 22 Mar 2024 17:26 +0500, from avbe...@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?”

Re: Root password strength

[Lee]

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

Re: Root password strength

[Alexander V. Makartsev]

On 22.03.2024 14:57, Jan Krapivin wrote:



чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev :

This conclusion seems less than optimal to me.
By condemning yourself to type 12+ character password every time
you 'sudo' would really hurt accessibility and usability of your
home computer and for no good reason.

If we focus solely on your use case: a login security of a PC at
home, without remote access, then password of your sudo user could
be as short and
simple as four numbers, of course unrelated to your date of birth,
phone number, or any other easily guessable sequence of numbers,
like '1234'.


Are you speaking only about sudo or root password also?


Dealing with root password could be tricky and you have three options:
1. You can implement the same 'faillock' scheme for root user as well 
and make root password shorter for convenience.
    Pro: 3 failed login attempts and root user will be locked for a 
time period.
    Con: You or somebody can (un)intentionally lock out root user for a 
time period.
2. You can set good password (12+ symbols) for root user without 
'faillock' scheme.

    Pro: You will be always able to login as root user.
    Con: Typing 12+ symbols password could be a headache.
3. You can unset (delete) root user password and lock the account.
    Pro: Nobody will be able to login as root user directly. Instead 
you will have to rely on sudo user to gain root privileges.
    Con: You will have to keep sudo account safe and set shorter lockup 
time period or make another sudo user as backup.


If you prefer to have root user as failsafe, to fix system when you 
screw something up. I suggest to go for option 2 and keep it simple.


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"

_*
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"?

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

*_
_*
That statement is not entirely true, because it depends on a method how 
a PC is connected to the Internet. There are three options:
1. Your PC is connected to Local Area Network (LAN) and there is a 
router/firewall device between your PC and the Internet cord.
    In this case any unsolicited Internet traffic (automated 
connections, port scans, etc) will be stopped by router/firewall device.
    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).
    In case you would want some traffic to reach your PC through a 
router/firewall device, you will have to configure a rule and allow it 
on router/firewall device.
2. Your PC is connected to a router device that works as a network 
bridge and your PC has public IP address assigned by ISP.
    In this case any unsolicited Internet traffic (automated 
connections, port scans, etc) will reach your PC and should be stopped 
by a firewall.
3. Your PC is connected to Internet cord directly and PC has public IP 
address assigned by ISP.
    In this case any unsolicited Internet traffic (automated 
connections, port scans, etc) will reach your PC and should be stopped 
by a firewall.


In cases 2 and 3 you have to keep firewall up and configured to block 
incoming traffic. Also you have to be aware of any active network 
services on your PC that could be accessed from the Internet and it is 
your job to keep them secure.
These services could be anything: SSH server, FTP server, HTTP server, 
SQL server, SAMBA server, game servers, etc.


In case 1 you are relatively safe from Internet traffic noise. Hosts on 
your LAN are separated from the Internet by router/firewall device.


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.


I hope this helps you to understand a little more how networking works 
under the hood and while there is indeed a network traffic noise 
reaching every second every host on the Internet, 99.99% of it simply 
dropped by firewalls, ISP filters, or fail otherwise.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Root password strength

[Joe]

On Fri, 22 Mar 2024 12:57:20 +0300
Jan Krapivin  wrote:

> чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev
> :
> 
> > This conclusion seems less than optimal to me.
> > By condemning yourself to type 12+ character password every time you
> > 'sudo' would really hurt accessibility and usability of your home
> > computer and for no good reason.
> >
> > If we focus solely on your use case: a login security of a PC at
> > home, without remote access, then password of your sudo user could
> > be as short and simple as four numbers, of course unrelated to your
> > date of birth, phone number, or any other easily guessable sequence
> > of numbers, like '1234'. 
> 
> Are you speaking only about sudo or root password also?
> 
> 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"*
> 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"?*
> This thread reminded of that topic -
> https://forums.debian.net/viewtopic.php?t=154002

Most people connect to the Net through a router, usually supplied by
the ISP. By default, that router should not permit any connection
attempts. It is worth checking its configuration, in case some
'helpful' supplier has enabled uPnP 'to make it easier to play online
games'. If so, turn it off. 

Make sure router management is not permitted from the WAN side. Some
ISPs expect to be able to access the router from the Net, something
which should be discouraged.

If you haven't already, change the admin password from the default,
though you probably won't be able to change the account name.

If you use wi-fi, then use the best security your router and clients
can deal with, usually WPA2. If you don't use wi-fi, turn it off at the
router.

Really, with a router in its factory default condition, nothing from
outside should ever get as far as your computer. The problems don't
usually start until you want to run some kind of server software which
is accessible from outside, which must then be appropriately secured.

The main security issues, of course, come from connections you have
invited into your computer, malicious email and web pages. All you can
do to mitigate those threats is to be sensible and careful.

-- 
Joe

Re: Root password strength

[Jan Krapivin]

чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev :

> This conclusion seems less than optimal to me.
> By condemning yourself to type 12+ character password every time you
> 'sudo' would really hurt accessibility and usability of your home computer
> and for no good reason.
>
> If we focus solely on your use case: a login security of a PC at home,
> without remote access, then password of your sudo user could be as short and
> simple as four numbers, of course unrelated to your date of birth, phone
> number, or any other easily guessable sequence of numbers, like '1234'.
>

Are you speaking only about sudo or root password also?

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"*
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"?*
This thread reminded of that topic -
https://forums.debian.net/viewtopic.php?t=154002

Re: Root password strength

[Alexander V. Makartsev]

On 20.03.2024 20:28, Jan Krapivin wrote:

I must mention that "32 characters" is only my guess.

In the Handbook it is said: "The root user's password should be long 
(12 characters or more) and impossible to guess."


Also, i must again say that in my case we speak just about a humble 
home desktop, without a ""ssh" access"" or whatever complicated.


Thank you for your answers and tips. I will make a very strong 
password for root and a strong one for  a user in the sudo group.

This conclusion seems less than optimal to me.
By condemning yourself to type 12+ character password every time you 
'sudo' would really hurt accessibility and usability of your home 
computer and for no good reason.


If we focus solely on your use case: a login security of a PC at home, 
without remote access, then password of your sudo user could be as short and
simple as four numbers, of course unrelated to your date of birth, phone 
number, or any other easily guessable sequence of numbers, like '1234'.
And to prevent guessing password by "bruteforce" you will need to 
restrict number of allowed login attempts.
This could be done by enabling and configuring PAM module. ( man 
pam_faillock )
If configured correctly after a few failed login attempts user will be 
locked out for a configured amount of time and will be unlocked 
automatically once time passes.


Also think about this scenario: a visitor or relative will get physical 
access to your PC and will be able to type on keyboard, reboot it, 
access USB ports, etc.
If perpetrator could do all that, long passwords won't save you, because 
it is easy to reset passwords or add a new sudo user without knowing any 
passwords.
This could be done by simply booting to live OS on USB drive and 
'chroot' into filesystem of your OS.


To defend from this scenario you need to have encrypted filesystem with 
a strong password and never leave your PC with logged in session.
Logged in user session could be used by hackers in theory and practice 
to exploit a known (unpatched) or an unknown (0-day) vulnerability and 
escalate user privileges.

Of course, these hackers have to come into your house first. :)


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Root password strength

[Curt]

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

Re: Root password strength

[Lee]

On Wed, Mar 20, 2024 at 3:50 PM Pierre-Elliott Bécue wrote:
>
> De : Lee
> À : Pierre-Elliott Bécue
> Cc : Debian Users ML 
> Date : 20 mars 2024 20:40:52
> Objet : Re: Root password strength
>
> > On Wed, Mar 20, 2024 at 1:47 PM Pierre-Elliott Bécue  wrote:
> >>
> >> Brad Rogers wrote on 20/03/2024 at 18:39:30+0100:
> >>> On Wed, 20 Mar 2024 17:09:31 +0100
> >>> Pierre-Elliott Bécue wrote:
> >>>
> >>> Hello Pierre-Elliott,
> >>>
> >>>> Most of the time, writing down a password is a very bad idea.
> >>>
> >>> Not in your own home.  And in any event, it depends where one keeps that
> >>> 'written down' password.
> >>>
> >>> And if it *does* become an issue at home, you've got bigger, more
> >>> immediate, problems to deal with;  Of the intruder variety.
> >>
> >> You have a rather bad cybersecurity approach. And you did not do a
> >> proper risk assessment.
> >
> > The OP said
> > - My password is easy because i am not afraid of direct physical
> > access to the computer.
> >
> > That seems like a good enough risk assessment to me, but please
> > explain what you think is "a proper risk assessment."
> >
> > Thanks,
> > Lee
>
> As stated elsewhere, I am done with this thread. Therefore I do not intend to 
> reply here.
>
> If you still want an answer I am happy to reply privately.

Yes, I would like an answer.  I've got passwords written down at home,
so I started thinking about it and I'm much more concerned about other
papers I have at home like bank statements etc. that could do much
more damage to me if they ended up in the wrong hands than a password
to an AP

Thanks
Lee

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 2:34 PM Pierre-Elliott Bécue  wrote:
>
> Jeffrey Walton  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, ,
> > 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

Re: Root password strength

[Pierre-Elliott Bécue]

De : Lee 
À : Pierre-Elliott Bécue 
Cc : Debian Users ML 
Date : 20 mars 2024 20:40:52
Objet : Re: Root password strength

> On Wed, Mar 20, 2024 at 1:47 PM Pierre-Elliott Bécue  wrote:
>> 
>> Brad Rogers  wrote on 20/03/2024 at 18:39:30+0100:
>>> On Wed, 20 Mar 2024 17:09:31 +0100
>>> Pierre-Elliott Bécue  wrote:
>>> 
>>> Hello Pierre-Elliott,
>>> 
>>>> Most of the time, writing down a password is a very bad idea.
>>> 
>>> Not in your own home.  And in any event, it depends where one keeps that
>>> 'written down' password.
>>> 
>>> And if it *does* become an issue at home, you've got bigger, more
>>> immediate, problems to deal with;  Of the intruder variety.
>> 
>> You have a rather bad cybersecurity approach. And you did not do a
>> proper risk assessment.
> 
> The OP said
> - My password is easy because i am not afraid of direct physical
> access to the computer.
> 
> That seems like a good enough risk assessment to me, but please
> explain what you think is "a proper risk assessment."
> 
> Thanks,
> Lee

As stated elsewhere, I am done with this thread. Therefore I do not intend to 
reply here.

If you still want an answer I am happy to reply privately.

-- 
Pierre-Elliott Bécue

Re: Root password strength

[Lee]

On Wed, Mar 20, 2024 at 1:47 PM Pierre-Elliott Bécue  wrote:
>
> Brad Rogers  wrote on 20/03/2024 at 18:39:30+0100:
> > On Wed, 20 Mar 2024 17:09:31 +0100
> > Pierre-Elliott Bécue  wrote:
> >
> > Hello Pierre-Elliott,
> >
> >>Most of the time, writing down a password is a very bad idea.
> >
> > Not in your own home.  And in any event, it depends where one keeps that
> > 'written down' password.
> >
> > And if it *does* become an issue at home, you've got bigger, more
> > immediate, problems to deal with;  Of the intruder variety.
>
> You have a rather bad cybersecurity approach. And you did not do a
> proper risk assessment.

The OP said
- My password is easy because i am not afraid of direct physical
access to the computer.

That seems like a good enough risk assessment to me, but please
explain what you think is "a proper risk assessment."

Thanks,
Lee

Re: Root password strength

[Pierre-Elliott Bécue]

John Hasler  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


signature.asc
Description: PGP signature

Re: Root password strength

[John Hasler]

tomas writes:
> Actually, I use between pwgen -n 8 (user pw) and pwgen -n 16 (LUKS
> encryption).

-n is the default for pwgen.  Note that this slightly reduces the size
of the search space.  Unfortunately many sites require it.

> I memorize the most important of them.

I memorize the ones I use most often through use.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Root password strength

[Pierre-Elliott Bécue]

Brad Rogers  wrote on 20/03/2024 at 19:03:48+0100:

> [[PGP Signed Part:No public key for 0F3EE001F02A3E20 created at 
> 2024-03-20T19:03:48+0100 using RSA]]
> On Wed, 20 Mar 2024 18:46:04 +0100
> Pierre-Elliott Bécue  wrote:
>
> Hello Pierre-Elliott,
>
>>You have a rather bad cybersecurity approach.
>
> I use password generators and vaults for all my passwords.  Nothing
> wrong with my cyber-security.

When you state that something like "writing down" a password is
reasonable in one's home as if this actual home were a heaven of safety,
I beg to differ.

Happy to know you actually have a more sensible approach in practice.

That being said, your root password might be needed in situations where
a vault is not accessible yet (let's say your laptop is in a bad
shape). So a vault can not be enough.

> Also note that I put 'written down' in single quotes - it was meant to
> indicate that the term could be a euphemism for such things as stored in
> a password vault, a secure note on a mobile phone, and so on.

It's not the original point of the thread, so while I can understand and
agree your understanding of "written down" not including a paper or
paperbook, it was clearly not the understanding of the initial post.

I guess I'll leave things there for good, anyway, people will do
whatever they think is best, regardless of cyber-security concerns.

-- 
PEB


signature.asc
Description: PGP signature

Re: Root password strength

[John Hasler]

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

Re: Root password strength

[Pierre-Elliott Bécue]

Jeffrey Walton  wrote on 20/03/2024 at 19:16:16+0100:

> On Wed, Mar 20, 2024 at 1:45 PM Pierre-Elliott Bécue  wrote:
>>
>>
>> Jeffrey Walton  wrote on 20/03/2024 at 18:30:34+0100:
>>
>> > On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue  
>> > wrote:
>> >>
>> >> Jeffrey Walton  wrote on 20/03/2024 at 17:19:46+0100:
>> >>
>> >> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  
>> >> > wrote:
>> >> >>
>> >> >> John Hasler  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 

Re: Root password strength

[Brad Rogers]

On Wed, 20 Mar 2024 18:46:04 +0100
Pierre-Elliott Bécue  wrote:

Hello Pierre-Elliott,

>You have a rather bad cybersecurity approach.

I use password generators and vaults for all my passwords.  Nothing
wrong with my cyber-security.

Also note that I put 'written down' in single quotes - it was meant to
indicate that the term could be a euphemism for such things as stored in
a password vault, a secure note on a mobile phone, and so on.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
White people going to school, where they teach you to be thick
White Riot - The Clash


pgpAeRFB5k2S7.pgp
Description: OpenPGP digital signature

Re: Root password strength

[Pierre-Elliott Bécue]

Michael Kjörling <2695bd53d...@ewoof.net> wrote on 20/03/2024 at 19:04:10+0100:

> On 20 Mar 2024 18:46 +0100, from p...@debian.org (Pierre-Elliott Bécue):
 Most of the time, writing down a password is a very bad idea.
>>> 
>>> Not in your own home.  And in any event, it depends where one keeps that
>>> 'written down' password.
>>> 
>>> And if it *does* become an issue at home, you've got bigger, more
>>> immediate, problems to deal with;  Of the intruder variety.
>> 
>> You have a rather bad cybersecurity approach. And you did not do a
>> proper risk assessment.
>
> "Writing a password down" can also be known as "using a password
> manager".

In that case it's "type it down". "Write it down" is not really open to
ambiguity.

> Which I would say is _solid_ advice for just about everyone, because
> if you're doing passwords properly and have any kind of Internet
> presence, you have essentially no chance of remembering every last
> one.
>
> The requirement being, of course, that you use a trustworthy password
> manager and a _very good_ password database protection passphrase.
>
> Learning a handful of strong passwords that you use regularly (FDE
> unlocking, login, password manager, maybe another set of those for
> work, and perhaps a few others) is perfectly reasonable, especially if
> you aren't arbitrarily forced to change them every few months.
> Committing _every_ password to memory is completely impractical.

Ok, so you reply to threads without actually reading them?
-- 
PEB


signature.asc
Description: PGP signature

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 1:45 PM Pierre-Elliott Bécue  wrote:
>
>
> Jeffrey Walton  wrote on 20/03/2024 at 18:30:34+0100:
>
> > On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue  
> > wrote:
> >>
> >> Jeffrey Walton  wrote on 20/03/2024 at 17:19:46+0100:
> >>
> >> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  
> >> > wrote:
> >> >>
> >> >> John Hasler  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, ,

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 17:07 +0100, from p...@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?”

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 18:46 +0100, from p...@debian.org (Pierre-Elliott Bécue):
>>> Most of the time, writing down a password is a very bad idea.
>> 
>> Not in your own home.  And in any event, it depends where one keeps that
>> 'written down' password.
>> 
>> And if it *does* become an issue at home, you've got bigger, more
>> immediate, problems to deal with;  Of the intruder variety.
> 
> You have a rather bad cybersecurity approach. And you did not do a
> proper risk assessment.

"Writing a password down" can also be known as "using a password
manager".

Which I would say is _solid_ advice for just about everyone, because
if you're doing passwords properly and have any kind of Internet
presence, you have essentially no chance of remembering every last
one.

The requirement being, of course, that you use a trustworthy password
manager and a _very good_ password database protection passphrase.

Learning a handful of strong passwords that you use regularly (FDE
unlocking, login, password manager, maybe another set of those for
work, and perhaps a few others) is perfectly reasonable, especially if
you aren't arbitrarily forced to change them every few months.
Committing _every_ password to memory is completely impractical.

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

Re: Root password strength

[tomas]

On Wed, Mar 20, 2024 at 11:02:41AM -0500, John Hasler wrote:
> Use one of the password generating programs such as pwgen to produce a
> 12 character random password.  Write it down.

Actually, I use between pwgen -n 8 (user pw) and pwgen -n 16 (LUKS encryption).
I memorize the most important of them. The older I get, the easier it gets
(surprisingly :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Root password strength

[Pierre-Elliott Bécue]

Brad Rogers  wrote on 20/03/2024 at 18:39:30+0100:
> On Wed, 20 Mar 2024 17:09:31 +0100
> Pierre-Elliott Bécue  wrote:
>
> Hello Pierre-Elliott,
>
>>Most of the time, writing down a password is a very bad idea.
>
> Not in your own home.  And in any event, it depends where one keeps that
> 'written down' password.
>
> And if it *does* become an issue at home, you've got bigger, more
> immediate, problems to deal with;  Of the intruder variety.

You have a rather bad cybersecurity approach. And you did not do a
proper risk assessment.

-- 
PEB


signature.asc
Description: PGP signature

Re: Root password strength

[Pierre-Elliott Bécue]

Jeffrey Walton  wrote on 20/03/2024 at 18:30:34+0100:

> On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue  wrote:
>>
>> Jeffrey Walton  wrote on 20/03/2024 at 17:19:46+0100:
>>
>> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  
>> > wrote:
>> >>
>> >> John Hasler  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


signature.asc
Description: PGP signature

Re: Root password strength

[Brad Rogers]

On Wed, 20 Mar 2024 17:09:31 +0100
Pierre-Elliott Bécue  wrote:

Hello Pierre-Elliott,

>Most of the time, writing down a password is a very bad idea.

Not in your own home.  And in any event, it depends where one keeps that
'written down' password.

And if it *does* become an issue at home, you've got bigger, more
immediate, problems to deal with;  Of the intruder variety.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Kill joy, bad guy, big talking, small fry
Death On Two Legs - Queen


pgpL80qZ__gan.pgp
Description: OpenPGP digital signature

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue  wrote:
>
> Jeffrey Walton  wrote on 20/03/2024 at 17:19:46+0100:
>
> > On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  
> > wrote:
> >>
> >> John Hasler  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

Re: Root password strength

[Pierre-Elliott Bécue]

John Hasler  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


signature.asc
Description: PGP signature

Re: Root password strength

[Pierre-Elliott Bécue]

Jeffrey Walton  wrote on 20/03/2024 at 17:19:46+0100:

> On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  wrote:
>>
>> John Hasler  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


signature.asc
Description: PGP signature

Re: Root password strength

[Max Nikulin]

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.

Re: Root password strength

[John Hasler]

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

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

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue  wrote:
>
> John Hasler  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

Re: Root password strength

[Pierre-Elliott Bécue]

John Hasler  wrote on 20/03/2024 at 17:02:41+0100:

> Use one of the password generating programs such as pwgen to produce a
> 12 character random password.  Write it down.

Most of the time, writing down a password is a very bad idea.

-- 
PEB


signature.asc
Description: PGP signature

Re: Root password strength

[Pierre-Elliott Bécue]

John Hasler  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


signature.asc
Description: PGP signature

Re: Root password strength

[John Hasler]

Use one of the password generating programs such as pwgen to produce a
12 character random password.  Write it down.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 10:58 -0500, from j...@sugarbit.com (John Hasler):
>> 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.

Which is why I keep recommending Diceware.

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

Re: Root password strength

[John Hasler]

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

Re: Root password strength

[Pierre-Elliott Bécue]

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

> On 20 Mar 2024 15:45 +0100, from p...@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


signature.asc
Description: PGP signature

Re: Root password strength

[Jan Krapivin]

I must mention that "32 characters" is only my guess.

In the Handbook it is said: "The root user's password should be long (12
characters or more) and impossible to guess."

Also, i must again say that in my case we speak just about a humble home
desktop, without a ""ssh" access"" or whatever complicated.

Thank you for your answers and tips. I will make a very strong password for
root and a strong one for  a user in the sudo group.

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 15:45 +0100, from p...@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.

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

Re: Root password strength

[Pierre-Elliott Bécue]

Jan Krapivin  wrote on 19/03/2024 at 15:42:55+0100:

> I read Debian Administrator's handbook now. And there are such words: 
>
>  The root user's password should be long (12 characters or more) and
>  impossible to guess. Indeed, any computer (and a fortiori any server)
>  connected to the Internet is regularly targeted by automated
>  connection attempts with the most obvious passwords.  Sometimes it
>  may even be subject to dictionary attacks, in which many combinations
>  of words and numbers are tested as password.  Avoid using the names
>  of children or parents, dates of birth, etc.: many of your co-workers
>  might know them, and you rarely want to give them free access to the
>  computer in question.
>
> The thing is my password is very easy now, and i haven't thought about
> "automated connection attempts", that sounds rather... scary?  My
> password is easy because i am not afraid of direct physical access to
> the computer.
>
> But... if there is a serious network danger, then i should change my
> password of course. But how strong it should be? If we speak about
> network attacks...

Any machine accessible through network connection could be more exposed
due to an overly simple user password. This is more true for root as
it's a well-known username (no need to guess the username) and it has
inherent full privileges in classic GNU/Linux distros.

> it should be like 32 symbols with special symbols?  Or this paragraph
> in a handbook is rather paranoid?

It's not paranoid.

> I have activated sudo now for my regular user. Can it (password of
> regular user) be less sophisticated than root password? Because it
> would be rather difficult to enter 32 symbols every time i wake my PC
> after suspend.

Have a read at https://xkcd.com/936/

Strength of password increases far more with their length than their
complexity.

A phrase you will easily remember but that would be hardcore to guess
through social engineering is perfect.

If you're weird as I am, and used to remember 20+-character-long random
password with symbols yadda yadda, then it's fine, too.

Also you could invest in a security token and configure pam_u2f for
root, but it seems overkill for basic users.

-- 
PEB


signature.asc
Description: PGP signature

Re: Root password strength

[tomas]

On Wed, Mar 20, 2024 at 09:23:58AM -0400, Jeffrey Walton wrote:

[...]

> > Also, are you saying that you do not let users rotate their keys
> > themselves; and if so, why on Earth not?
> 
> Key continuity has turned out to be a better security property than
> key rotation. It is wise to avoid gratuitous rotation schemes.

I will be the last ne to advocate any gratuitous rotation scheme (key
or password or anything).

My point is giving users enough wits and power (and competent help) to
make good decisions and to implement them.

If my laptop gets stolen, I'll definitely generate new keys.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 7:03 AM Michael Kjörling <2695bd53d...@ewoof.net> wrote:
>
> On 20 Mar 2024 15:46 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
> > Regarding certificates, I issue VPN certificates to be installed on each
> > remote device. I don't use public key.
>
> What exactly is this "certificate" that you speak of? In typical
> usage, it means a public key plus some surrounding metadata, but you
> say that you "don't use public key".
>
>
> > For ssh use I issue secret keys to each user and maintain matching public
> > keys in LDAP servers.  SSHD servers can get the public keys in real time by
> > using the AuthorizedKeysCommand. If a secret key is compromised I simply
> > remove the matching public key.
> >
> > [users are locked out from uploading their public key using ssh-copy-id]
>
> So the private keys aren't private, thereby invalidating a lot of
> assumptions inherent in public key cryptography.
>
> Also, are you saying that you do not let users rotate their keys
> themselves; and if so, why on Earth not?

Key continuity has turned out to be a better security property than
key rotation. It is wise to avoid gratuitous rotation schemes.

Jeff

Re: Root password strength

[Dan Ritter]

jeremy ardley wrote: 
> 
> On 20/3/24 19:03, Michael Kjörling wrote:
> > On 20 Mar 2024 15:46 +0800, fromjeremy.ard...@gmail.com  (jeremy ardley):
> > > [users are locked out from uploading their public key using ssh-copy-id]
> > So the private keys aren't private, thereby invalidating a lot of
> > assumptions inherent in public key cryptography.
> > 
> > Also, are you saying that you do not let users rotate their keys
> > themselves; and if so, why on Earth not?
> 
> 
> Private keys aren't private in any corporate network. Security management
> would be impossible to manage if users could generate their own keys and
> install them on any server. For one thing users do not have any easy way to
> revoke certificates.

No. Users create public/private keypairs, keep the private one
private and send you the public side to install on servers. A
user can revoke their own access by deleting the private one;
a sysadmin can revoke a user's access by deleting the public one
from each host that it's installed on.

For ssh, the sysadmin can also add/remove users from the
AllowUsers list in the sshd config, or add them to the DenyUsers
list, or remove their membership in an AllowGroups list.

Proponents of certificates are going to say "but this is harder
than adding their cert to the CRL", which is nominally true but
in practice, you most likely already have a distribution mechanism
for maintaining system configuration everywhere.

> In any serious network, private keys are simply a name for a secret key
> issued by an administrator to a user. Matching public keys are often
> published and are maintained by the administrator. Both keys are owned by
> the administrators.

This is incorrect, as Michael and others have stated.
 
> If you are in full control of your network and resources, sure, go ahead and
> rotate your keys. But if you are in a network run by others you have to
> accept their control of keys and access to resources.

No, you have to accept their control of access to their resources.

-dsr-

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 12:17 +0100, from to...@tuxteam.de:
>>> For ssh use I issue secret keys to each user and maintain matching public
>>> keys in LDAP servers [...]
> 
>> So the private keys aren't private, thereby invalidating a lot of
>> assumptions inherent in public key cryptography.
> 
> We are using that schema in our (small) company, too. Private keys
> are definitely private here (we don't "issue keys" to anyone, everyone
> uploads their *public* keys to the LDAP).

Right; I have no issues with _that_ part. It's the _issuing_ of a
whole key pair that means that the private key _must_ have been
accessible to someone else at some point. In a scheme where the key
pair is generated by the user, the private key _may_ still be
accessible to others (for example through administrator access), but
that's a trade-off we always have to make when using a system
administered by someone else; and it can be mitigated by e.g. storing
the key on a SSH-capable Yubikey or in the TPM, along with a
decent-strength passphrase.


> Definitely. "Issuing keys" to people is a "crypto smell". I know,
> it is being done far too often. People are too stupid to make their
> key pairs, it is often said. But keeping people stupid is your
> biggest security hole!

Step 1: Open a terminal

Step 2: Run this command: ssh-keygen -f ~/.ssh/my_key_ ...

Step 3: Submit (through whatever means appropriate to the environment)
the contents of ~/.ssh/my_key_.pub; do not ever, no matter what
anyone tells you, share the contents of ~/.ssh/my_key_

Step 4: Update ~/.ssh/config to indicate IdentityFile ~/.ssh/my_key_

It's not _that_ hard. I'm pretty sure pretty much anyone who can
meaningfully use SSH to start with can figure that out.

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

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 19:21 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
>>> Regarding certificates, I issue VPN certificates to be installed on each
>>> remote device. I don't use public key.
>> 
>> What exactly is this "certificate" that you speak of? In typical
>> usage, it means a public key plus some surrounding metadata, but you
>> say that you "don't use public key".
> 
> Each client is issued with a private key unique to the access point. When I
> say I don't use public key I mean I don't use certificates issued from
> public key authorities such as comodo

Ah, so when you say "public key", what you mean is "certificate issued
by a widely trusted X.509 PKI certificate authority" (a large chunk of
which is often abbreviated as CA). Not the cryptographic concept of
the public portion of an asymmetric key pair. Gotcha. Though now I'm
instead uncertain what you mean by "access point"; somehow I don't
think you're referring to IEEE 802.11 variants APs, although of course
certificate-based authentication _can_ be used with those.

By the way, no sane public CA these days should issue your keys _for_
you, and no customer should accept a process that involves the CA
doing so. The process of acquiring a signed certificate starts with
preparing and presenting a CSR which includes the public portion of a
key pair generated locally (for some definition of locally); this
ensures that it is at least _possible_ that only the party preparing
the CSR has knowledge of the corresponding private key. Breaches
notwithstanding, obviously, but that's an issue in any scheme.
Certainly no reasonable CA should _want_ the risk of ever handling the
corresponding private keys.


> Private keys aren't private in any corporate network. Security management
> would be impossible to manage if users could generate their own keys and
> install them on any server. For one thing users do not have any easy way to
> revoke certificates.

"Run this command, send me this file."

Depending on the setup, that can of course also be automated. It is
even possible to provision a provisional key pair, triggering a forced
key rotation upon login if that key is used (or if a flag is set in
the user database); and if you only allow _one_ key at any one time,
that this key is generated under the user's control should not present
any significant difficulties.

Also, I suspect that you use the term "certificate" here in a
different sense than elsewhere, because aside from the issues
surrounding PKI certificate revocations (as opposed to rotation) in
practice, private-CA certificates face similar issues which revocation
is supposed to help mitigate.

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

Re: Root password strength

[jeremy ardley]

On 20/3/24 19:03, Michael Kjörling wrote:

On 20 Mar 2024 15:46 +0800, fromjeremy.ard...@gmail.com  (jeremy ardley):

Regarding certificates, I issue VPN certificates to be installed on each
remote device. I don't use public key.

What exactly is this "certificate" that you speak of? In typical
usage, it means a public key plus some surrounding metadata, but you
say that you "don't use public key".
Each client is issued with a private key unique to the access point. 
When I say I don't use public key I mean I don't use certificates issued 
from public key authorities such as comodo

For ssh use I issue secret keys to each user and maintain matching public
keys in LDAP servers.  SSHD servers can get the public keys in real time by
using the AuthorizedKeysCommand. If a secret key is compromised I simply
remove the matching public key.

[users are locked out from uploading their public key using ssh-copy-id]

So the private keys aren't private, thereby invalidating a lot of
assumptions inherent in public key cryptography.

Also, are you saying that you do not let users rotate their keys
themselves; and if so, why on Earth not?



Private keys aren't private in any corporate network. Security 
management would be impossible to manage if users could generate their 
own keys and install them on any server. For one thing users do not have 
any easy way to revoke certificates.


In any serious network, private keys are simply a name for a secret key 
issued by an administrator to a user. Matching public keys are often 
published and are maintained by the administrator. Both keys are owned 
by the administrators.


If you are in full control of your network and resources, sure, go ahead 
and rotate your keys. But if you are in a network run by others you have 
to accept their control of keys and access to resources.

Re: Root password strength

[tomas]

On Wed, Mar 20, 2024 at 11:03:16AM +, Michael Kjörling wrote:
> On 20 Mar 2024 15:46 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
> > Regarding certificates, I issue VPN certificates to be installed on each
> > remote device. I don't use public key.
> 
> What exactly is this "certificate" that you speak of? In typical
> usage, it means a public key plus some surrounding metadata, but you
> say that you "don't use public key".

My take. I'm always a bit oversuspicious when umbrella words are thrown
around.

A certificate is (usually) a signed public key. You need it whenever
you need more complex key management (definitely not when things are
between your server and you).

> > For ssh use I issue secret keys to each user and maintain matching public
> > keys in LDAP servers [...]

> So the private keys aren't private, thereby invalidating a lot of
> assumptions inherent in public key cryptography.

We are using that schema in our (small) company, too. Private keys
are definitely private here (we don't "issue keys" to anyone, everyone
uploads their *public* keys to the LDAP).

> Also, are you saying that you do not let users rotate their keys
> themselves; and if so, why on Earth not?

Definitely. "Issuing keys" to people is a "crypto smell". I know,
it is being done far too often. People are too stupid to make their
key pairs, it is often said. But keeping people stupid is your
biggest security hole!

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Root password strength

[Michael Kjörling]

On 20 Mar 2024 15:46 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
> Regarding certificates, I issue VPN certificates to be installed on each
> remote device. I don't use public key.

What exactly is this "certificate" that you speak of? In typical
usage, it means a public key plus some surrounding metadata, but you
say that you "don't use public key".


> For ssh use I issue secret keys to each user and maintain matching public
> keys in LDAP servers.  SSHD servers can get the public keys in real time by
> using the AuthorizedKeysCommand. If a secret key is compromised I simply
> remove the matching public key.
> 
> [users are locked out from uploading their public key using ssh-copy-id]

So the private keys aren't private, thereby invalidating a lot of
assumptions inherent in public key cryptography.

Also, are you saying that you do not let users rotate their keys
themselves; and if so, why on Earth not?

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

Re: Root password strength

[jeremy ardley]

On 20/3/24 13:32, to...@tuxteam.de wrote:
How will a "VPN" with a "certificate" (whatever that means in this  > context) be more secure than a SSH (assuming key pair 
authentication, > not password)? > > They are doing the same dance (key 
exchange, key pair validation, > session key establishment) -- the 
"certificate" part is just a step > further (and, BTW, SSH can do that, 
too), which just eases key > management (at the expense of security: you 
have but one more moving > part). > > The "port" thing stays the same: 
the VPN server uses a TCP > connection, too. > > Moving the port to a 
non-standard number, using fail2ban, firewall > knocking and those 
things don't increase security *directly* -- they > just remove noise 
from the logs, which eases the admin's task and > thus increase security 
indirectly.


Benefits of running VPN rather that VPN + SSH or even just SSH:

- VPN only has only one 'hole' in the firewall.

- Providing VPN ingress through or to your firewall is a different 
security model to hosting a ssh server on your firewall.


- Accessing an internal host using SSH from an internal machine is yet 
another security model.


- A SSH server exposed to public will have less ability to detect and 
counter serious probes compared to a VPN server


If you go for the arrangement I use, you need have only one security 
mechanism for all internal ssh servers and that mechanism will also 
defend in the event the firewall is breached.


Then in isolation you can develop a security strategy for your public 
facing VPN ports as well as firewall configuration to mitigate any breach.


Regarding certificates, I issue VPN certificates to be installed on each 
remote device. I don't use public key.


For ssh use I issue secret keys to each user and maintain matching 
public keys in LDAP servers.  SSHD servers can get the public keys in 
real time by using the AuthorizedKeysCommand. If a secret key is 
compromised I simply remove the matching public key.


[users are locked out from uploading their public key using ssh-copy-id]

Re: Root password strength

[tomas]

On Wed, Mar 20, 2024 at 02:01:44AM -0400, Jeffrey Walton wrote:
> On Wed, Mar 20, 2024 at 1:32 AM  wrote:
> >
> > On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:
> >
> > > A 'safer' implementation will not even expose an ssh port. Instead there
> > > will be a certificate based VPN where you first need a certificate to
> > > connect and then you need a separate certificate to log in as root. A
> > > further enhancement of security is to use 2-factor authentication - which 
> > > is
> > > supported in sshd via pam.
> >
> > How will a "VPN" with a "certificate" (whatever that means in this context)
> > be more secure than a SSH (assuming key pair authentication, not password)?
> 
> This may be more theoretical, but... IPSec uses
> Encrypt-then-Authenticate (EtA), which is provably secure under random
> models. In fact, I believe IPSec is IND-CCA2 secure (Ciphertext
> Indistinguishability), which is a strong notion of security. SSH uses
> Encrypt-and-Authenticate (E), which is provably insecure. The SSH
> protocol leaks information because of the order of operations of
> encryption and authentication.

Of course it's not only theoretical. I took issue with the umbrella
statement "VPN", which might be IPSec or some variant of TLS, to
mention two ends of the scale.

We might have lots of ground to cover until the issues you mention
really matter, but at some point they will, for sure.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Root password strength

[Jeffrey Walton]

On Wed, Mar 20, 2024 at 1:32 AM  wrote:
>
> On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:
>
> > A 'safer' implementation will not even expose an ssh port. Instead there
> > will be a certificate based VPN where you first need a certificate to
> > connect and then you need a separate certificate to log in as root. A
> > further enhancement of security is to use 2-factor authentication - which is
> > supported in sshd via pam.
>
> How will a "VPN" with a "certificate" (whatever that means in this context)
> be more secure than a SSH (assuming key pair authentication, not password)?

This may be more theoretical, but... IPSec uses
Encrypt-then-Authenticate (EtA), which is provably secure under random
models. In fact, I believe IPSec is IND-CCA2 secure (Ciphertext
Indistinguishability), which is a strong notion of security. SSH uses
Encrypt-and-Authenticate (E), which is provably insecure. The SSH
protocol leaks information because of the order of operations of
encryption and authentication.

As far as the certificate, I suspect it alludes to public key. Both
IPSec and SSH can use public key cryptography (as opposed to
passwords), so they are about equally secure (compared to passwords).
IPSec is actually a little stronger with provable security properties
because it uses HKDF after key agreement to derive bulk encryption
keys. And I believe IPSec performs a key conformation step, which
helps with the security proofs.

The IPSec standard is maintained by Hugo Krawczyk and associates. Hugo
is a world class cryptographer. That's why the IPSec protocol does not
have the theoretical defects of SSH (or TLS).

Krawczyk is also the author of The Order of Encryption and
Authentication for Protecting Communications,
. It is a very
good paper.

> They are doing the same dance (key exchange, key pair validation, session
> key establishment) -- the "certificate" part is just a step further (and,
> BTW, SSH can do that, too), which just eases key management (at the expense
> of security: you have but one more moving part).
>
> The "port" thing stays the same: the VPN server uses a TCP connection, too.
>
> Moving the port to a non-standard number, using fail2ban, firewall knocking
> and those things don't increase security *directly* -- they just remove
> noise from the logs, which eases the admin's task and thus increase security
> indirectly.
>
> There's no magic.

Jeff

Re: Root password strength

[tomas]

On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote:

> A 'safer' implementation will not even expose an ssh port. Instead there
> will be a certificate based VPN where you first need a certificate to
> connect and then you need a separate certificate to log in as root. A
> further enhancement of security is to use 2-factor authentication - which is
> supported in sshd via pam.

How will a "VPN" with a "certificate" (whatever that means in this context)
be more secure than a SSH (assuming key pair authentication, not password)?

They are doing the same dance (key exchange, key pair validation, session
key establishment) -- the "certificate" part is just a step further (and,
BTW, SSH can do that, too), which just eases key management (at the expense
of security: you have but one more moving part).

The "port" thing stays the same: the VPN server uses a TCP connection, too.

Moving the port to a non-standard number, using fail2ban, firewall knocking
and those things don't increase security *directly* -- they just remove
noise from the logs, which eases the admin's task and thus increase security
indirectly.

There's no magic.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Root password strength

[debian-user]

Michael Kjörling <2695bd53d...@ewoof.net> wrote:

> For most values of "you", most attackers don't care about _your_
> account, or _your_ system; they care about _any_ account, or _any_
> system. Actually targeted attacks do happen, but very rarely compared
> to what might be thought of as attackers throwing stuff at the wall
> and seeing what sticks. (There's even a term for that: Internet
> background noise.)

There's increasing an extra channel available to attackers - namely
'smart' things, or the IoT. For example, many people have a 'smart' TV
that they allow to connect to the Internet so they can use various
streaming services. Each of those services, plus the TV manufacturer,
then becomes a potential point of attack into your system. Similarly
people have security cameras and doorbells connected to the Internet
and even things like fridges and washing machines! Any such device can
be compromised and used to attack computers or door locks or whatever.

Re: Root password strength

[jeremy ardley]

On 19/3/24 23:02, Greg Wooledge wrote:

On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:

The root user's password should be long (12 characters or more) and
impossible to guess. Indeed, any computer (and a fortiori any server)
connected to the Internet is regularly targeted by automated connection
attempts with the most obvious passwords. [...]

For most people, this really isn't a concern, because they either don't
run an ssh server at all, or they use the default sshd_config which does
not allow root logins.

The only time you need to worry about this is if you:

  * Run an ssh server, AND
  * Accept ssh connections from the public Internet, AND
  * Have changed the sshd_config file to allow ssh root logins.



A preferred method of securing root on public access systems is to use 
client certificates. Some implementations will have no password for root 
so unless you have the certificate you will never be able to log in.


Cloud servers such as hosted by AWS typically do this.

A 'safer' implementation will not even expose an ssh port. Instead there 
will be a certificate based VPN where you first need a certificate to 
connect and then you need a separate certificate to log in as root. A 
further enhancement of security is to use 2-factor authentication - 
which is supported in sshd via pam.


For me to get remote root access to my systems I first need to connect 
to my firewall with a certificate based vpn; then I need to present a 
root client certificate; and then I need to enter a 2fa code.


Even from within my network I need a client certificate and 2fa to 
connect to an sshd server.

Re: Root password strength

[Greg Wooledge]

On Tue, Mar 19, 2024 at 03:49:06PM +, debian-u...@howorth.org.uk wrote:
> Dan Ritter  wrote:
> > Check whether you are running ssh:
> > 
> > /sbin/service ssh status
> 
> It's not called ssh; it is sshd
> Also nowadays it's more usual to say
> 
>  $ systemctl status sshd

On Debian, the systemd service name for openssh-server is "ssh", not
"sshd".  However, Debian offers an *alias* named "sshd" which allows
people to type your command and still get a meaningful result.

However, it should be noted that "ssh" is the actual service name, which
matters if you're going to do something like creating a drop-in override.
Those need to be done with the correct name instead of the alias name.

Re: Root password strength

[Michael Kjörling]

On 19 Mar 2024 17:42 +0300, from daydreamer199...@gmail.com (Jan Krapivin):
> The thing is my password is very easy now, and i haven't thought about
> *"automated
> connection attempts"*, that sounds rather... scary? My password is easy
> because i am not afraid of direct physical access to the computer.
> 
> But... if there is a serious network danger, then i should change my
> password of course. But how strong it should be? If we speak about network
> attacks... it should be like 32 symbols with special symbols? Or this
> paragraph in a handbook is rather paranoid?
> 
> I have activated sudo now for my regular user. Can it (password of regular
> user) be less sophisticated than root password? Because it would be rather
> difficult to enter 32 symbols every time i wake my PC after suspend.

My suggestion for a memorable password is to use a _passphrase_
instead.

I discuss my approach at [1] and to a lesser extent at [2], both of
which you may find worth your while to read through. At [1], the most
relevant section would be the one on passwords you must memorize.

A 6-7 word Diceware passphrase [3] will provide very much adequate
security unless your threat model includes a nation-state government
brute-forcing your password; which chances are it doesn't. I recommend
using the EFF's long word list [4], but any "five dice" (7776 entries)
Diceware word list will provide equivalent security when used with a
word separator. (Unless using a word list deliberately designed for
that use case, Diceware passphrases have reduced security when used
without a word separator. The EFF long word list takes this into
account and therefore doesn't strictly require word separators to
achieve the intended degree of security.)

Two examples of such passphrases are: pedometer settling stretch
endocrine elusive unpaid rented; or: valiant overtime last drab carol
landslide supper. (Naturally, please don't use either of these.) The
xkcd example [5] is: correct horse battery staple; but four words is
relatively weak.

Such a 7-word Diceware passphrase has roughly equivalent strength
(about 90 bits' worth) to a 15 characters mixed-case alphanumeric
traditional password such as ieraey6Wic1Shoh, or an 18 characters
single-case alphanumeric password such as gav7it7aetiengo9ei; but is
arguably much easier to remember and type.

Even a 6-word Diceware passphrase (about 77 bits' worth of security)
will virtually guarantee that the weak link in your security will not
be your account password, yet if you are a reasonably good typist can
be typed accurately in a few seconds with a bit of practice. Also,
many variations of [6] apply. Technical protective measures can only
go so far, BUT that doesn't mean that they are useless; far from it.

For most values of "you", most attackers don't care about _your_
account, or _your_ system; they care about _any_ account, or _any_
system. Actually targeted attacks do happen, but very rarely compared
to what might be thought of as attackers throwing stuff at the wall
and seeing what sticks. (There's even a term for that: Internet
background noise.)

So _even more important is probably to keep your system up to date on
software._ Install updated versions of packages promptly as they
become available in the Debian repositories. If you have any
out-of-tree packages installed, make sure to set up so that you get
notified of updates to those. Software bugs, especially but not
exclusively in software that is exposed to the network in any way
shape or form (this very much includes something like your web
browser), is likely a bigger risk to most people than is a halfway
decent password being brute-forced over the network.


 [1]: https://michael.kjorling.se/password-tips/
 [2]: 
https://michael.kjorling.se/blog/2023/forget-what-everyone-tells-you-makes-a-password-strong/
 [3]: https://www.diceware.com/
 [4]: https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases
 [5]: https://xkcd.com/936/
 [6]: https://xkcd.com/538/

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

Re: Root password strength

[debian-user]

Dan Ritter  wrote:
> Jan Krapivin wrote: 
> > I read Debian Administrator's handbook now. And there are such
> > words:
> > 
> > The root user's password should be long (12 characters or more) and
> > impossible to guess.   
> ...
> 
>  
> > The thing is my password is very easy now, and i haven't thought
> > about *"automated
> > connection attempts"*, that sounds rather... scary? My password is
> > easy because i am not afraid of direct physical access to the
> > computer.
> > 
> > But... if there is a serious network danger, then i should change my
> > password of course. But how strong it should be? If we speak about
> > network attacks... it should be like 32 symbols with special
> > symbols? Or this paragraph in a handbook is rather paranoid?
> > 
> > I have activated sudo now for my regular user. Can it (password of
> > regular user) be less sophisticated than root password? Because it
> > would be rather difficult to enter 32 symbols every time i wake my
> > PC after suspend.  
> 
> The threats are different for:
> 
> - a laptop that travels and can be stolen
> - a desktop that does not leave your residence
> - a server that accepts connections from the outside world
> 
> If you have a laptop, you want to have your filesystem encrypted
> (LUKS or ZFS encryption, most likely) and protected by a 12+
> character password.
> 
> If you have a desktop, perhaps you feel it is at low risk. 
> 
> If you have a machine that runs the ssh daemon, you should not
> use passwords at all for remote logins; you should use ssh keys.
> 
> Check whether you are running ssh:
> 
> /sbin/service ssh status

It's not called ssh; it is sshd
Also nowadays it's more usual to say

 $ systemctl status sshd

> If it is active, use sudo to edit /etc/ssh/sshd_config to lock
> down access. (It may be that you don't want it running at all,
> too.)
> 
> -dsr-
> 

Re: Root password strength

[Kamil Jońca]

Greg Wooledge  writes:

> On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:
>> The root user's password should be long (12 characters or more) and
>> impossible to guess. Indeed, any computer (and a fortiori any server)
>> connected to the Internet is regularly targeted by automated connection
>> attempts with the most obvious passwords. [...]
>
> For most people, this really isn't a concern, because they either don't
> run an ssh server at all, or they use the default sshd_config which does
> not allow root logins.
>
> The only time you need to worry about this is if you:
>
>  * Run an ssh server, AND
>  * Accept ssh connections from the public Internet, AND
>  * Have changed the sshd_config file to allow ssh root logins.

The last condition is not needed. Quite often ssh bots tests other
accounts (ubuntu, admin, php, www, etc...) and if these account allow
su/sudo this also migh be a threat.

KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: Root password strength

[Marco Moock]

Am Tue, 19 Mar 2024 17:42:55 +0300
schrieb Jan Krapivin :

> The thing is my password is very easy now

The simplest thin is to change that now.

, and i haven't thought about *"automated connection attempts"*,
> that sounds rather... scary?

Those attempts happen if a server software (like SSH, Telnet, rlogin)
is running on you machine and reachable from the Internet.
The IPv4 address range can be iterated easily (only 4 billion
addresses) and the ports too.

> My password is easy because i am not afraid of direct physical access
> to the computer.

As long as it isn't connected to a network or running any services
reachable from the outside, there is no danger.

I recommend choosing a good password anyway because if you intent to
have remote access in the future, you might forget to choose long
passwords for ALL users.

Re: Root password strength

[Dan Ritter]

Jan Krapivin wrote: 
> I read Debian Administrator's handbook now. And there are such words:
> 
> The root user's password should be long (12 characters or more) and
> impossible to guess. 
...

 
> The thing is my password is very easy now, and i haven't thought about
> *"automated
> connection attempts"*, that sounds rather... scary? My password is easy
> because i am not afraid of direct physical access to the computer.
> 
> But... if there is a serious network danger, then i should change my
> password of course. But how strong it should be? If we speak about network
> attacks... it should be like 32 symbols with special symbols? Or this
> paragraph in a handbook is rather paranoid?
> 
> I have activated sudo now for my regular user. Can it (password of regular
> user) be less sophisticated than root password? Because it would be rather
> difficult to enter 32 symbols every time i wake my PC after suspend.

The threats are different for:

- a laptop that travels and can be stolen
- a desktop that does not leave your residence
- a server that accepts connections from the outside world

If you have a laptop, you want to have your filesystem encrypted
(LUKS or ZFS encryption, most likely) and protected by a 12+
character password.

If you have a desktop, perhaps you feel it is at low risk. 

If you have a machine that runs the ssh daemon, you should not
use passwords at all for remote logins; you should use ssh keys.

Check whether you are running ssh:

/sbin/service ssh status

If it is active, use sudo to edit /etc/ssh/sshd_config to lock
down access. (It may be that you don't want it running at all,
too.)

-dsr-

Re: Root password strength

[Greg Wooledge]

On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:
> The root user's password should be long (12 characters or more) and
> impossible to guess. Indeed, any computer (and a fortiori any server)
> connected to the Internet is regularly targeted by automated connection
> attempts with the most obvious passwords. [...]

For most people, this really isn't a concern, because they either don't
run an ssh server at all, or they use the default sshd_config which does
not allow root logins.

The only time you need to worry about this is if you:

 * Run an ssh server, AND
 * Accept ssh connections from the public Internet, AND
 * Have changed the sshd_config file to allow ssh root logins.

Re: Root password strength

[Jan Krapivin]

> The threats are different for:
>
> - a laptop that travels and can be stolen
> - a desktop that does not leave your residence
> - a server that accepts connections from the outside world
>
>
> Check whether you are running ssh:
>

It is a simple home desktop PC

*@deb:~$ /sbin/service ssh status*

*Unit ssh.service could not be found.*

*@deb:~$ sudo /sbin/service ssh status*


*[sudo] password for ***: *

*Unit ssh.service could not be found.*

Re: Root password strength

[Jan Krapivin]

> Do you have some kind of remote access enabled or do you intend to in
> the near future?
>

No and no. Its just a simple home PC.

>
> If not, then you do not need to worry. Even less if you have a firewall
> to block any service that might appear by mistake.
>

I have UFW (gufw) enabled.

 Thank you.

Re: Root password strength

[Nicolas George]

Jan Krapivin (12024-03-19):
> The thing is my password is very easy now, and i haven't thought about
> *"automated
> connection attempts"*, that sounds rather... scary? My password is easy
> because i am not afraid of direct physical access to the computer.

Hi.

Do you have some kind of remote access enabled or do you intend to in
the near future?

If not, then you do not need to worry. Even less if you have a firewall
to block any service that might appear by mistake.

Regards,

-- 
  Nicolas George

Root password strength

[Jan Krapivin]

I read Debian Administrator's handbook now. And there are such words:

The root user's password should be long (12 characters or more) and
impossible to guess. Indeed, any computer (and a fortiori any server)
connected to the Internet is regularly targeted by automated connection
attempts with the most obvious passwords. Sometimes it may even be subject
to dictionary attacks, in which many combinations of words and numbers are
tested as password. Avoid using the names of children or parents, dates of
birth, etc.: many of your co-workers might know them, and you rarely want
to give them free access to the computer in question.

The thing is my password is very easy now, and i haven't thought about
*"automated
connection attempts"*, that sounds rather... scary? My password is easy
because i am not afraid of direct physical access to the computer.

But... if there is a serious network danger, then i should change my
password of course. But how strong it should be? If we speak about network
attacks... it should be like 32 symbols with special symbols? Or this
paragraph in a handbook is rather paranoid?

I have activated sudo now for my regular user. Can it (password of regular
user) be less sophisticated than root password? Because it would be rather
difficult to enter 32 symbols every time i wake my PC after suspend.