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.

Re: root password of debian live cd?

[Richmond]

Timothy M Butterworth  writes:

> On Tue, May 30, 2023 at 2:03 AM hlyg  wrote:
>
>
> On 5/30/23 12:37, to...@tuxteam.de wrote:
> >
> > This seems to have been discussed like eight years ago:
> >
> >    https://lists.debian.org/debian-live/2015/05/msg00081.html
> >
> > Perhaps it should go into a FAQ.
> >
> > Cheers
>
>
> Thank tomas!
>
> many packages break because of empty password? some other distro
> have no
> password for live cd, they don't break?
>
> i have tried latest deb11 live cd for i386/gnome, live or Live
> aren't
> correct passwords
>
>
> The Live CD has no root password you have to use sudo. 

Someone here suggested using live-config as a command line parameter in
Grub.

https://forums.debian.net/viewtopic.php?t=102937

If you are logged in as user you can use:

sudo bash

To get a root command prompt and set the root passwd using

passwd

Re: root password of debian live cd?

[Default User]

On Tue, 2023-05-30 at 00:05 -0400, Timothy M Butterworth wrote:
> 
> 
> On Tue, May 30, 2023 at 12:02 AM hlyg  wrote:
> > Thank bw! internet search also shows that live is password, but
> > it's not 
> > correct
> > 
> 
> 
> Live is the password you use with sudo as there is no root password
> set. 
> 
> > i have rebooted,
> > 
> > > probably something like this
> > > https://en.wikipedia.org/wiki/Principle_of_least_privilege
> > > 
> > > .
> > i think they disclaim all responsibilities, they can use empty
> > password, 
> > as some other distro do
> 
> 
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀



I don't mean to clog up this thread with an unnecessary post, but I
just wanted to note that I (unfortunately) have had to use (as recently
as 2023-05-28): 

debian-live-11.7.0-amd64-gnome+nonfree.iso 

a number of times recently, due to flatpak being a corpulent space hog,
obnoxiously trying very hard to fill up my /var partition (10Gb, as
originally set by the Debian installer).  But that is just a side
issue.  

(Note: this is the Gnome Live image that has the non-free extra
drivers, etc., not the  "standard" Debian Live image.  Perhaps the
standard Debian Live image works differently; I never use it.  And
note, this is Debian 11.7 (Bullseye), Debian 12 (Bookworm) may also act
differently.

I can state that in my experience, unequivocally, it boots into a Gnome
DE without any password needed.  If administrative permission is needed
to do something, "sudo " works, without having to enter any
password.  Example:

sudo apt install timeshift


This post is just a FWIW. Feel free to disregard.

Re: root password of debian live cd?

[Timothy M Butterworth]

On Tue, May 30, 2023 at 2:03 AM hlyg  wrote:

>
> On 5/30/23 12:37, to...@tuxteam.de wrote:
> >
> > This seems to have been discussed like eight years ago:
> >
> >https://lists.debian.org/debian-live/2015/05/msg00081.html
> >
> > Perhaps it should go into a FAQ.
> >
> > Cheers
>
>
> Thank tomas!
>
> many packages break because of empty password? some other distro have no
> password for live cd, they don't break?
>
> i have tried latest deb11 live cd for i386/gnome, live or Live aren't
> correct passwords
>

The Live CD has no root password you have to use sudo.


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

Re: root password of debian live cd?

[hlyg]

On 5/30/23 12:37, to...@tuxteam.de wrote:


This seems to have been discussed like eight years ago:

   https://lists.debian.org/debian-live/2015/05/msg00081.html

Perhaps it should go into a FAQ.

Cheers



Thank tomas!

many packages break because of empty password? some other distro have no 
password for live cd, they don't break?


i have tried latest deb11 live cd for i386/gnome, live or Live aren't 
correct passwords

Re: root password of debian live cd?

[tomas]

On Tue, May 30, 2023 at 07:52:21AM +0800, hlyg wrote:
> debian-live-11.0.0-i386-lxde.iso
> 
> do you know root password of cd above?

the "standard" Debian live user is "user" with password "live"
> 
> why do they create root password of live cd?


This seems to have been discussed like eight years ago:

  https://lists.debian.org/debian-live/2015/05/msg00081.html

Perhaps it should go into a FAQ.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: root password of debian live cd?

[Timothy M Butterworth]

On Tue, May 30, 2023 at 12:02 AM hlyg  wrote:

> Thank bw! internet search also shows that live is password, but it's not
> correct
>

Live is the password you use with sudo as there is no root password set.

i have rebooted,
>
> > probably something like this
> > https://en.wikipedia.org/wiki/Principle_of_least_privilege
> >
> > .
> i think they disclaim all responsibilities, they can use empty password,
> as some other distro do
>


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

Re: root password of debian live cd?

[hlyg]

Thank bw! internet search also shows that live is password, but it's not 
correct


i have rebooted,


probably something like this
https://en.wikipedia.org/wiki/Principle_of_least_privilege

.
i think they disclaim all responsibilities, they can use empty password, 
as some other distro do

root password of debian live cd?

[bw]

> do you know root password of cd above?
try sudo -i there usually is no root passwd 

and if it asks try 'live'

> why do they create root password of live cd?

probably something like this
https://en.wikipedia.org/wiki/Principle_of_least_privilege

root password of debian live cd?

[hlyg]

debian-live-11.0.0-i386-lxde.iso

do you know root password of cd above?

why do they create root password of live cd?

Re: How: Require root password instead of user password for GUI programs

[tomas]

On Fri, Apr 07, 2023 at 11:38:28PM +0100, Brian wrote:
> On Fri 07 Apr 2023 at 21:09:59 +0200, to...@tuxteam.de wrote:

[...]

> > You folks keeping up with desktop environments are
> > real heroes:-)
> 
> It's a dirty job, but someone has to do it :).

I gave up and ended at Fvwm in a big round circle.

I'm too old for this shit.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How: Require root password instead of user password for GUI programs

[Brian]

On Fri 07 Apr 2023 at 21:09:59 +0200, to...@tuxteam.de wrote:

> On Fri, Apr 07, 2023 at 06:22:48PM +0200, B.M. wrote:
> 
> [...]
> 
> > PolicyKit got replaced by polkit (at least in current Debian Testing),
> > and the "old" solution with setting AdminIdentities doesn't work
> > anymore. Instead one has to add a file /etc/polkit-1/rules.d/50-
> > default.rules as follows:
> > 
> > polkit.addAdminRule(function(action, subject) {
> > return ["unix-user:0"];
> > });
> 
> Gah.
> 
> > in order to require root credentials for admin tasks (if sudo is
> > installed).
> > 
> > I hope someone finds this useful.
> 
> You folks keeping up with desktop environments are
> real heroes:-)

It's a dirty job, but someone has to do it :).

-- 
Brian.

Re: How: Require root password instead of user password for GUI programs

[tomas]

On Fri, Apr 07, 2023 at 06:22:48PM +0200, B.M. wrote:

[...]

> PolicyKit got replaced by polkit (at least in current Debian Testing),
> and the "old" solution with setting AdminIdentities doesn't work
> anymore. Instead one has to add a file /etc/polkit-1/rules.d/50-
> default.rules as follows:
> 
> polkit.addAdminRule(function(action, subject) {
> return ["unix-user:0"];
> });

Gah.

> in order to require root credentials for admin tasks (if sudo is
> installed).
> 
> I hope someone finds this useful.

You folks keeping up with desktop environments are
real heroes:-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: How: Require root password instead of user password for GUI programs

[B.M.]

On Thu, 2023-04-06 at 11:04 -0400, Jeffrey Walton wrote:
> On Thu, Apr 6, 2023 at 8:36 AM B.M.  wrote:
> > 
> > I configured my system such that some users are in group sudo, but
> > they are
> > asked for the root password instead of just their user password by
> > creating a
> > file within /etc/sudoers.d/ with the line:
> > 
> >  Defaults rootpw
> > 
> > This is working just fine, but for graphical applications it
> > doesn't work: e.g.
> > to start synaptic I get a password prompt requiring my user
> > password, not the
> > root password.
> > 
> > How can I configure my system such that entering the root password
> > is also
> > required in these cases?
> > 
> > (Maybe there is something with polkit, but I couldn't figure out
> > myself...)
> 
> May be helpful:
> https://askubuntu.com/questions/1199006/how-to-let-polkit-request-root-password-instead-users-password
> 
> And possibly
> https://askubuntu.com/questions/1246661/defaults-rootpw-for-the-gui-password-prompt
> 
> Jeff

Thank you for your ideas.

In fact it seems that these solutions are a bit outdated - I found out
that the following is needed, as documented in the Arch Wiki.

PolicyKit got replaced by polkit (at least in current Debian Testing),
and the "old" solution with setting AdminIdentities doesn't work
anymore. Instead one has to add a file /etc/polkit-1/rules.d/50-
default.rules as follows:

polkit.addAdminRule(function(action, subject) {
return ["unix-user:0"];
});

in order to require root credentials for admin tasks (if sudo is
installed).

I hope someone finds this useful.

Best,
Bernd

Re: How: Require root password instead of user password for GUI programs

[Joe]

On Thu, 6 Apr 2023 11:04:13 -0400
Jeffrey Walton  wrote:

> On Thu, Apr 6, 2023 at 8:36 AM B.M.  wrote:
> >
> > I configured my system such that some users are in group sudo, but
> > they are asked for the root password instead of just their user
> > password by creating a file within /etc/sudoers.d/ with the line:
> >
> >  Defaults rootpw
> >
> > This is working just fine, but for graphical applications it
> > doesn't work: e.g. to start synaptic I get a password prompt
> > requiring my user password, not the root password.
> >
> > How can I configure my system such that entering the root password
> > is also required in these cases?
> >
> > (Maybe there is something with polkit, but I couldn't figure out
> > myself...)  
> 
> May be helpful:
> https://askubuntu.com/questions/1199006/how-to-let-polkit-request-root-password-instead-users-password
> 
> And possibly
> https://askubuntu.com/questions/1246661/defaults-rootpw-for-the-gui-password-prompt
> 
> Jeff
> 

On Debian, it is my experience that a default installation of Synaptic
always requires the root password. It is invoked by synaptic-pkexec.

-- 
Joe

Re: How: Require root password instead of user password for GUI programs

[Jeffrey Walton]

On Thu, Apr 6, 2023 at 8:36 AM B.M.  wrote:
>
> I configured my system such that some users are in group sudo, but they are
> asked for the root password instead of just their user password by creating a
> file within /etc/sudoers.d/ with the line:
>
>  Defaults rootpw
>
> This is working just fine, but for graphical applications it doesn't work: 
> e.g.
> to start synaptic I get a password prompt requiring my user password, not the
> root password.
>
> How can I configure my system such that entering the root password is also
> required in these cases?
>
> (Maybe there is something with polkit, but I couldn't figure out myself...)

May be helpful:
https://askubuntu.com/questions/1199006/how-to-let-polkit-request-root-password-instead-users-password

And possibly 
https://askubuntu.com/questions/1246661/defaults-rootpw-for-the-gui-password-prompt

Jeff

How: Require root password instead of user password for GUI programs

[B.M.]

Hi,

I configured my system such that some users are in group sudo, but they are
asked for the root password instead of just their user password by creating a
file within /etc/sudoers.d/ with the line:

 Defaults rootpw

This is working just fine, but for graphical applications it doesn't work: e.g.
to start synaptic I get a password prompt requiring my user password, not the
root password.

How can I configure my system such that entering the root password is also
required in these cases?

(Maybe there is something with polkit, but I couldn't figure out myself...)

Thank you.

Have a nice day,
Bernd

Re: unkown root password and mkdir problem.

[Michael Castellon]

for superuser:
su

regards.



On Fri, Dec 10, 2021 at 4:14 AM Andrei POPESCU 
wrote:

> On Vi, 05 nov 21, 19:17:11, Thomas George wrote:
> >
> > I have used sudo successfully with many commands including mkdir but sudo
> > tar fails to uncompress files because it cannot make the necessary
> > directories. That is sudo tar runs but must use mkdir which fails.
>
> In such cases you might want to run the command in a `sudo -i` (or '-s',
> depending on your preference) session.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Re: unkown root password and mkdir problem.

[Andrei POPESCU]

On Vi, 05 nov 21, 19:17:11, Thomas George wrote:
> 
> I have used sudo successfully with many commands including mkdir but sudo
> tar fails to uncompress files because it cannot make the necessary
> directories. That is sudo tar runs but must use mkdir which fails.

In such cases you might want to run the command in a `sudo -i` (or '-s', 
depending on your preference) session.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: unkown root password and mkdir problem.

[deloptes]

Thomas George wrote:

> Thanks, this fixed my problem and as Greg recommended I have reset mkdir
> ownership and options

If I were you, I would be very careful using root

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

Re: unkown root password and mkdir problem.

[Thomas George]

Thanks, this fixed my problem and as Greg recommended I have reset mkdir 
ownership and options


On 11/5/21 7:35 PM, Jeremy Ardley wrote:


On 6/11/21 7:17 am, Thomas George wrote:
when installing debian I entered eight digits as the root password. 
The instillation completed successfully. Later I tried to become root 
but the eight digits didn't work and many permutations also didn't work.


I have used sudo successfully with many commands including mkdir but 
sudo tar fails to uncompress files because it cannot make the 
necessary directories. That is sudo tar runs but must use mkdir which 
fails.


I have found mkdir in /usr/bin and changed the ownership to root:tom 
and given it rwx permissions but this does not solve the problem.


If there are no suggested solutions to this email tomorrow I will 
backup all my files to external drive and reinstall bullseye




Try

sudo passwd root

And reset the root password to a known string

Re: unkown root password and mkdir problem.

[Greg Wooledge]

On Sat, Nov 06, 2021 at 07:35:22AM +0800, Jeremy Ardley wrote:
> On 6/11/21 7:17 am, Thomas George wrote:
> > I have found mkdir in /usr/bin and changed the ownership to root:tom and
> > given it rwx permissions but this does not solve the problem.

> Try
> 
> sudo passwd root
> 
> And reset the root password to a known string

And after you do that, change the ownership and permissions of
/usr/bin/mkdir back to what they are supposed to be:

-rwxr-xr-x 1 root root 85184 Sep 24  2020 mkdir

If that wasn't what they were originally, then your system is severely
broken, and all bets are off.

Re: unkown root password and mkdir problem.

[Jeremy Ardley]

On 6/11/21 7:17 am, Thomas George wrote:
when installing debian I entered eight digits as the root password. 
The instillation completed successfully. Later I tried to become root 
but the eight digits didn't work and many permutations also didn't work.


I have used sudo successfully with many commands including mkdir but 
sudo tar fails to uncompress files because it cannot make the 
necessary directories. That is sudo tar runs but must use mkdir which 
fails.


I have found mkdir in /usr/bin and changed the ownership to root:tom 
and given it rwx permissions but this does not solve the problem.


If there are no suggested solutions to this email tomorrow I will 
backup all my files to external drive and reinstall bullseye




Try

sudo passwd root

And reset the root password to a known string

--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

unkown root password and mkdir problem.

[Thomas George]

when installing debian I entered eight digits as the root password. The 
instillation completed successfully. Later I tried to become root but 
the eight digits didn't work and many permutations also didn't work.


I have used sudo successfully with many commands including mkdir but 
sudo tar fails to uncompress files because it cannot make the necessary 
directories. That is sudo tar runs but must use mkdir which fails.


I have found mkdir in /usr/bin and changed the ownership to root:tom and 
given it rwx permissions but this does not solve the problem.


If there are no suggested solutions to this email tomorrow I will backup 
all my files to external drive and reinstall bullseye

Re: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Alexander V. Makartsev]

On 21.03.2021 12:40, Andrei POPESCU wrote:

[Bcc: debian-boot]

Dear Debian-User subscribers,

The Release Notes editor is asking whether this is still an issue for
bullseye (i.e. if the patch to Debian Installer mentioned below was
applied in the meantime).

It will be a while until I get to check that. If someone can confirm
either way please write to #977358.

Full quote below for context.

Thanks,
Andrei

This is still an issue for bullseye. Patch was not applied, but solution 
works if you apply it manually after OS installation.

I've tested it on latest weekly build (debian-testing-amd64-netinst.iso).

--
With kindest regards, Alexander.

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

Re: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Andrei POPESCU]

[Bcc: debian-boot]

Dear Debian-User subscribers,

The Release Notes editor is asking whether this is still an issue for 
bullseye (i.e. if the patch to Debian Installer mentioned below was 
applied in the meantime).

It will be a while until I get to check that. If someone can confirm 
either way please write to #977358.

Full quote below for context.

Thanks,
Andrei

On Lu, 14 dec 20, 13:12:59, Andrei POPESCU wrote:
> Package: release-notes
> X-Debbugs-CC: debian-user@lists.debian.org
> 
> Dear Release Notes Maintainers,
> 
> Some text based on below would make sense for the Release Notes for 
> buster. If agreed I'll try to come up with a wording.
> 
> On Lu, 07 dec 20, 10:11:48, Greg Wooledge wrote:
> > On Sat, Dec 05, 2020 at 12:41:57PM +0200, Andrei POPESCU wrote:
> > > On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> > > > I am also going to guess that Deepin, like Ubuntu, defaults to giving
> > > > you a user account with sudo access, and no root password.  You can
> > > > achieve that in Debian as well, by doing something special during the
> > > > installation.  In all cases, it's a stupid idea and you shouldn't do it.
> > > 
> > > This is a pretty strong (and harsh!) statement. Care to expand on the 
> > > reasons?
> > 
> > It prevents access to single-user mode.  The fact that Debian (and
> > these others?) still puts a single-user mode entry into the GRUB menu,
> > knowing that it won't work, is just adding insult to injury.
> 
> A web search found #802211[1].
> 
> Short version:
> 
> For systemd >= 240 (buster[2]) run as root
> 
> systemctl edit rescue.service
> 
> and add:
> 
> [Service]
> Environment=SYSTEMD_SULOGIN_FORCE=1
> 
> (see /usr/share/doc/systemd/ENVIRONMENT.md.gz)
> 
> 
> The 'rescue.service' is started by systemd in case it detects 'single' 
> on the kernel command line (see systemd(1)).
> 
> You might want to do the same for 'emergency.service' as well (or 
> instead), since this service is started *automatically* in case of 
> certain errors (see systemd.special(7)) or if you add 'emergency' to the 
> kernel command line (e.g. if you can't fix your system via the 'rescue' 
> service).
> 
> 
> An untested patch to the Debian Installer exists to add both snippets if 
> the user chooses to leave the root password blank.
> 
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
> [2] see the bug for another snippet that should work for squeeze or 
> earlier.
> 
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser



signature.asc
Description: PGP signature

Re: Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[nickgeovanis]

Thanks Andrei.

On Mon, Dec 14, 2020, 5:15 AM Andrei POPESCU 
wrote:

> Package: release-notes
> X-Debbugs-CC: debian-user@lists.debian.org
>
> Dear Release Notes Maintainers,
>
> Some text based on below would make sense for the Release Notes for
> buster. If agreed I'll try to come up with a wording.
>
> On Lu, 07 dec 20, 10:11:48, Greg Wooledge wrote:
> > On Sat, Dec 05, 2020 at 12:41:57PM +0200, Andrei POPESCU wrote:
> > > On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> > > > I am also going to guess that Deepin, like Ubuntu, defaults to giving
> > > > you a user account with sudo access, and no root password.  You can
> > > > achieve that in Debian as well, by doing something special during the
> > > > installation.  In all cases, it's a stupid idea and you shouldn't do
> it.
> > >
> > > This is a pretty strong (and harsh!) statement. Care to expand on the
> > > reasons?
> >
> > It prevents access to single-user mode.  The fact that Debian (and
> > these others?) still puts a single-user mode entry into the GRUB menu,
> > knowing that it won't work, is just adding insult to injury.
>
> A web search found #802211[1].
>
> Short version:
>
> For systemd >= 240 (buster[2]) run as root
>
> systemctl edit rescue.service
>
> and add:
>
> [Service]
> Environment=SYSTEMD_SULOGIN_FORCE=1
>
> (see /usr/share/doc/systemd/ENVIRONMENT.md.gz)
>
>
> The 'rescue.service' is started by systemd in case it detects 'single'
> on the kernel command line (see systemd(1)).
>
> You might want to do the same for 'emergency.service' as well (or
> instead), since this service is started *automatically* in case of
> certain errors (see systemd.special(7)) or if you add 'emergency' to the
> kernel command line (e.g. if you can't fix your system via the 'rescue'
> service).
>
>
> An untested patch to the Debian Installer exists to add both snippets if
> the user chooses to leave the root password blank.
>
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
> [2] see the bug for another snippet that should work for squeeze or
> earlier.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
>

Bug#977358: release-notes: document how to make the rescue mode usable if no root password is set (buster)

[Andrei POPESCU]

Package: release-notes
X-Debbugs-CC: debian-user@lists.debian.org

Dear Release Notes Maintainers,

Some text based on below would make sense for the Release Notes for 
buster. If agreed I'll try to come up with a wording.

On Lu, 07 dec 20, 10:11:48, Greg Wooledge wrote:
> On Sat, Dec 05, 2020 at 12:41:57PM +0200, Andrei POPESCU wrote:
> > On Vi, 04 dec 20, 08:09:44, Greg Wooledge wrote:
> > > I am also going to guess that Deepin, like Ubuntu, defaults to giving
> > > you a user account with sudo access, and no root password.  You can
> > > achieve that in Debian as well, by doing something special during the
> > > installation.  In all cases, it's a stupid idea and you shouldn't do it.
> > 
> > This is a pretty strong (and harsh!) statement. Care to expand on the 
> > reasons?
> 
> It prevents access to single-user mode.  The fact that Debian (and
> these others?) still puts a single-user mode entry into the GRUB menu,
> knowing that it won't work, is just adding insult to injury.

A web search found #802211[1].

Short version:

For systemd >= 240 (buster[2]) run as root

systemctl edit rescue.service

and add:

[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1

(see /usr/share/doc/systemd/ENVIRONMENT.md.gz)


The 'rescue.service' is started by systemd in case it detects 'single' 
on the kernel command line (see systemd(1)).

You might want to do the same for 'emergency.service' as well (or 
instead), since this service is started *automatically* in case of 
certain errors (see systemd.special(7)) or if you add 'emergency' to the 
kernel command line (e.g. if you can't fix your system via the 'rescue' 
service).


An untested patch to the Debian Installer exists to add both snippets if 
the user chooses to leave the root password blank.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
[2] see the bug for another snippet that should work for squeeze or 
earlier.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Debian 8: Shutdown, Reboot, Suspend und Hibernate only after entering root password

[Christoph Pleger]

Hello,

Some days ago, I installed some machines with Debian jessie. Now I want to
achieve that, from the different desktop environments (KDE, GNOME, etc.),
the computers can only be shutdown, rebooted, suspended or hibernated,
after entering the root password.

In Debian 7, I achieved that by creating a file
/etc/polkit-1/localauthority/50-local.d/custom-menu.pkla with the
following contents:

[Disable suspend]
 Identity=unix-user:*
 Action=org.freedesktop.upower.suspend
 ResultActive=no
 ResultAny=no

[Disable hibernate]
 Identity=unix-user:*
 Action=org.freedesktop.upower.hibernate
 ResultActive=no
 ResultAny=no

[Disable shutdown]
 Identity=unix-user:*
 Action=org.freedesktop.consolekit.system.stop
 ResultActive=no
 ResultAny=no

[Disable reboot]
 Identity=unix-user:*
 Action=org.freedesktop.consolekit.system.restart
 ResultActive=no
 ResultAny=no


In Debian 8, this does not have the desired effect any more. Obviously,
the names of the actions have been changed to
org.freedesktop.login1.reboot etc., but even after replacing the action
names in custom-menu.pkla accordingly, no root authentication is required
before shutting down the computers.

So, what is the correct way to achieve my goal in jessie?

Viele Grüße
  Christoph

Re: Debian 8: Shutdown, Reboot, Suspend und Hibernate only after entering root password

[Brian]

On Thu 14 Jan 2016 at 16:10:03 +0100, Christoph Pleger wrote:

> Some days ago, I installed some machines with Debian jessie. Now I want to
> achieve that, from the different desktop environments (KDE, GNOME, etc.),
> the computers can only be shutdown, rebooted, suspended or hibernated,
> after entering the root password.
> 
> In Debian 7, I achieved that by creating a file
> /etc/polkit-1/localauthority/50-local.d/custom-menu.pkla with the
> following contents:

[Snip]

> In Debian 8, this does not have the desired effect any more. Obviously,
> the names of the actions have been changed to
> org.freedesktop.login1.reboot etc., but even after replacing the action
> names in custom-menu.pkla accordingly, no root authentication is required
> before shutting down the computers.
> 
> So, what is the correct way to achieve my goal in jessie?

We had something similar just recently. You probably need to adjust your
Action line.

  https://lists.debian.org/debian-user/2016/01/msg00174.html

Any use?

Re: Debian 8: Shutdown, Reboot, Suspend und Hibernate only after entering root password

[Floris]

Op Thu, 14 Jan 2016 16:10:03 +0100 schreef Christoph Pleger  
<christoph.ple...@cs.tu-dortmund.de>:



Hello,

Some days ago, I installed some machines with Debian jessie. Now I want  
to

achieve that, from the different desktop environments (KDE, GNOME, etc.),
the computers can only be shutdown, rebooted, suspended or hibernated,
after entering the root password.

In Debian 7, I achieved that by creating a file
/etc/polkit-1/localauthority/50-local.d/custom-menu.pkla with the
following contents:

[Disable suspend]
 Identity=unix-user:*
 Action=org.freedesktop.upower.suspend
 ResultActive=no
 ResultAny=no

[Disable hibernate]
 Identity=unix-user:*
 Action=org.freedesktop.upower.hibernate
 ResultActive=no
 ResultAny=no

[Disable shutdown]
 Identity=unix-user:*
 Action=org.freedesktop.consolekit.system.stop
 ResultActive=no
 ResultAny=no

[Disable reboot]
 Identity=unix-user:*
 Action=org.freedesktop.consolekit.system.restart
 ResultActive=no
 ResultAny=no


In Debian 8, this does not have the desired effect any more. Obviously,
the names of the actions have been changed to
org.freedesktop.login1.reboot etc., but even after replacing the action
names in custom-menu.pkla accordingly, no root authentication is required
before shutting down the computers.

So, what is the correct way to achieve my goal in jessie?

Viele Grüße
  Christoph




Is there an other file with a higher number which overwrite the current  
one?


success,

Floris

RE: Debian 7.1 root password issue.

[Wayne Hartell]

Cindy-Sue Causey butterflyby...@gmail.com wrote:

 On 2/2/15, Wayne Hartell w.hart...@ozemail.com.au wrote:
  Michael Collins wrote:
 
   Log in with the user account.  Left-click the user account name 
  (upper right corner), select system settings, select user, left-click 
  Unlock.
   Enter the root password.  Change the user account to an administrator.
 
 
  As a new Linux/Debian user I have been doing the not recommended 
  thing (at least I think it says it's not recommended; it has been a 
  while since my last install) thing of not setting a password for root. 
  That way there's no hoops to jump through to the installer puts my 
  intended user account into the sudoers list. Now the steps to do this 
  manually are re-described above I realize that under Gnome it's not 
  actually that hard to do (when making my install selections I had 
  memories of the manual way trying to edit the sudoers file, which for 
  a new user is a little daunting. I recall it taking me a few attempts to 
  get it to work. The installer gave me an easy way out). 
 
 
  That brings me to my point; due to my installer choices, I cannot log 
  in under root on the three systems that I have installed so far. Right 
  now I have no reason to believe that this is or ever will be an issue 
  since I can use sudo and that feels safer to me. Does anyone have any 
  different opinions on this? (These are home systems and predominantly 
  for learning Linux/Debian at this point, as opposed to being core 
  systems that are depended upon for daily use, although one day in the 
  not too distant future I hope to change this).

 My apologies if this has already been suggested or if you've already 
 mentioned you tried it, but have you tried:
 passwd root
 via command line as one of your users that has rights to do so? You 
 enter a password, enter it again to confirm, and done deal. It seems a 
 little too easy to do, actually. Every time I do it, my mind wanders off 
 thinking how easy it is to change if someone gains control of one of 
 our sudo enabled user accounts...

I just gave that a whirl and yes it works like a charm!

Regards,
Wayne.

  Just thinking out loud :)
  Cindy :)


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/006b01d0402b$6d149060$473db120$@ozemail.com.au

Re: Debian 7.1 root password issue.

[Bob Proulx]

Wayne Hartell wrote:
 As a new Linux/Debian user I have been doing the not recommended
 thing (at least I think it says it's not recommended; it has been a
 while since my last install) thing of not setting a password for
 root. That way there's no hoops to jump through to the installer
 puts my intended user account into the sudoers list.

I don't think that is not recommended at all.  It is fully
supported.  It is a well behaved path.  It isn't well known though and
I think that may be what you are reading as not recommended.  But
those of us that know what it does do know what it does and it is
just one of the choices available.  Not being as well known as the
mainstream path in this case doesn't make it less well tested because
less well known is still quite well known and quite well tested.  Also
I will point out that Ubuntu does this by default.  Ubuntu's default
is one way and Debian's default is the other way.

 Now the steps to do this manually are re-described above I realize
 that under Gnome it's not actually that hard to do (when making my
 install selections I had memories of the manual way trying to edit
 the sudoers file, which for a new user is a little daunting. I
 recall it taking me a few attempts to get it to work. The installer
 gave me an easy way out).

Debian creates a 'sudo' group.  Any user in the sudo group has sudo
access.  This is done by the default /etc/sudoers config line:

  # Allow members of group sudo to execute any command
  %sudo   ALL=(ALL:ALL) ALL

There is some history as to why that is done that way.  For one thing
it allowed a style of system config where that /etc/sudoers file is
never modified.  If it is never modified then the package manager can
update it without any interaction from the user.

The traditional /etc/sudoers config where individual modifications are
made for each user requires the package manager to notify the admin
upon every upgrade that the file is different in the new package and
the admin must merge those together.  That trips people sometimes such
as when secure_path was added to the config.  Admins that said keep
their current config then had problems with PATH until they figured
out that they were missing secure_path.  They should have merged their
custom config with the new config.  It was a self induced problem but
one that happens.

By keeping the /etc/sudoers file package pristine that problem is
avoided.  I now recommend putting any custom config into something
like /etc/sudoers.d/zz-sudoers-local instead.  That will never be
packaged and will never need a merge.

 That brings me to my point; due to my installer choices, I cannot
 log in under root on the three systems that I have installed so
 far. Right now I have no reason to believe that this is or ever will
 be an issue since I can use sudo and that feels safer to me. Does
 anyone have any different opinions on this? (These are home systems
 and predominantly for learning Linux/Debian at this point, as
 opposed to being core systems that are depended upon for daily use,
 although one day in the not too distant future I hope to change
 this).

You probably don't realize it but you are asking a religious question.
There is no single right answer.  But people do feel very strongly
about the issue and people do feel strongly that other people's
opinions are wrong about it.  If you search the archives there have
been flamewars on it before.  The sect that thinks allowing root
logins is ultimately bad have some belief that because root isn't
blocked from logging in that attackers can somehow magically actually
log in as root.  That just isn't true.

For you in your environment I don't see it ever being a problem.  You
should definitely feel free to continue.  You will even find people
who believe blocking root is The One True Way.  Anyone doing anything
different they feel is doing something heinously wrong.

For me in my environment I have often needed to log into remote server
systems as root because the system was in trouble and needed a root
login to take corrective action.  I have many times had cases where
logging in as a non-root user was ineffective because the non-root
user was unable to fork sudo due to the system being sick and needing
help.  With the ability to log in as root I was able to diagnose the
problems, take corrective action on the remote server, and get it back
online.  Most importantly diagnose problems.  Without visibility I
would only have been able to power cycle the server and would have had
no diagnostic ability and no idea what it was doing.  For me being
able to log in as root is The One True Way.

There is a huge difference and a large sameness between enterprise
servers and your portable laptop.  They can both be running exactly
the same Debian system.  It is the Universial Operating System after
all.  And yet your home desktop or laptop is not anything at all like
an enterprise server system.  It is interesting that they are so much
the same and 

Re: Debian 7.1 root password issue.

[Cindy-Sue Causey]

On 2/2/15, Wayne Hartell w.hart...@ozemail.com.au wrote:
 Michael Collins wrote:

  Log in with the user account.  Left-click the user account name (upper
 right corner), select system settings, select user, left-click Unlock.
  Enter the root password.  Change the user account to an administrator.


 As a new Linux/Debian user I have been doing the not recommended thing (at
 least I think it says it's not recommended; it has been a while since my
 last install) thing of not setting a password for root. That way there's no
 hoops to jump through to the installer puts my intended user account into
 the sudoers list. Now the steps to do this manually are re-described above I
 realize that under Gnome it's not actually that hard to do (when making my
 install selections I had memories of the manual way trying to edit the
 sudoers file, which for a new user is a little daunting. I recall it taking
 me a few attempts to get it to work. The installer gave me an easy way out).


 That brings me to my point; due to my installer choices, I cannot log in
 under root on the three systems that I have installed so far. Right now I
 have no reason to believe that this is or ever will be an issue since I can
 use sudo and that feels safer to me. Does anyone have any different opinions
 on this? (These are home systems and predominantly for learning Linux/Debian
 at this point, as opposed to being core systems that are depended upon for
 daily use, although one day in the not too distant future I hope to change
 this).


My apologies if this has already been suggested or if you've already
mentioned you tried it, but have you tried:

passwd root

via command line as one of your users that has rights to do so? You
enter a password, enter it again to confirm, and done deal. It seems a
little too easy to do, actually. Every time I do it, my mind wanders
off thinking how easy it is to change if someone gains control of one
of our sudo enabled user accounts...

Just thinking out loud :)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* Sid's down the street at the local hotel-motel-boatel right now.
We're trying to patch things up. *


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cao1p-kdkkn_pxkv_6glpnrbc3oxkmlnsnlsut37o2iaougn...@mail.gmail.com

Re: Debian 7.1 root password issue.

[Michael Collins]

SANG KIM sangkim8986 at msn.com writes:

 
 I recently installed debian 7.1 and I reinstalled it at least five 
times.  I've tried installing it with a root password created and without 
and Debian still won't let me log in as root.  It says authentication 
failed after I type in the root password.  
  
 I've tried reinstalling it without creating a root password and it still 
won't let me log in.  I get the same message as before.  I can log in as 
another user, but not as root.  I've checked the passwords entered and 
every time the password is correct, but Debian says that it's not.  How can 
I fix these issues.  
  
 I've tried to use the password command to remove whatever password I 
created/didn't create and I get an error message that the password command 
cannot be found in BASH.  Is there something wrong with the Debian 7.1?  I 
can't even install updates to the OS.
  
 Thank you.
 

Log in with the user account.  Left-click the user account name (upper 
right corner), select system settings, select user, left-click Unlock.  
Enter the root password.  Change the user account to an administrator.

What a pita!

Regards, 
MC