Re: Filsystemkorruption i ext4?

[Nicholas Geovanis]

On Wed, Mar 20, 2024, 11:28 AM Jesper Dybdal 
wrote:

> I have now done the following:
> * Checked the RAID array - no problems found.
> * Run fsck.  It found three cases of the block count being incorrect.  I
> don't know which the other two affected files are.
> * Run one pass of memtest86+.  Nothing found.
>
> So it seems not to be a problem with the disks.
> A bug in ext4?  Well, ext4 has always done its job for me wihtout problems.
> A RAM error that memtest86+ did not find?  Possible.  Once upon a time,
> when you bought an ordinary pc, its RAM had ECC as a matter of course;
> unfortunately, that is not the case nowadays.
>
> I think I'll let memtest86+ run overnight one of the coming nights.
>
> Unless it is simply a RAM error, then it is a bit scary...
>

I have seen that a couple times, unlikely but possible. Maybe review your
RAM configuration too, ensure that the sticks are on the same supported
refresh rate and distributed across the slots in an approved way.

Regards,
> Jesper
>
> On 2024-03-19 21:47, Franco Martelli wrote:
> > On 19/03/24 at 15:43, Jesper Dybdal wrote:
> >
> >>
> >> My plan is to boot a rescue disk and mount that partition read-only.
> >> Then:
> >> * If the file looks ok after reboot, then I'll strongly suspect the
> >> RAM - and run memtest.
> >> * Otherwise, I'll have to run fsck and see what happens.
> >>
> >> kernel version:
> >> root@nuser:~# uname -a
> >> Linux nuser 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31)
> >> x86_64 GNU/Linux
> >>
> >> The partition in question is a RAID 1 controlled by md.
> >
> > Another check you can perform it is on the RAID array, by default it
> > runs on the first Sunday of each month at 00:57. You should have this
> > file /etc/cron.d/mdadm that takes care to run this check monthly.
> >
> > Before you reboot, does it look OK /proc/mdstat ?
> >
>
> --
> Jesper Dybdal
> https://www.dybdal.dk
>
>
>
>

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 the

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: printing QR-codes on labels with 300dpi label printers with LaTeX

[Thomas Schmitt]

Hi,

Max Nikulin wrote:
> I admit "dithering" may be incorrect term, [...]
> Consider 2 squares having size of 2.5×2.5 pixels. Non-even sizes and fuzzy
> lines variants:
> █████
> ██████
> ████ ██
>██ ██
>█████
> Second variant might have sense if an image is treated as a photo unlikely
> having regular patterns with horizontal and vertical lines.

I see ...
The second rendering style is probably best described as "Bad Distortion".


Have a nice day :)

Thomas

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: printing QR-codes on labels with 300dpi label printers with LaTeX

[Max Nikulin]

On 20/03/2024 01:51, Thomas Schmitt wrote:

Max Nikulin wrote:

When vector graphics, that does not match device resolution, is rasterized,
the result is either non-even sizes of similar elements or fuzzy lines due
to dithering.


Nitpicking:

"Dithering" in raster graphics is emulation of color resolution at the
expense of space resolution.

[...]


The fuzzy lines are rather the opposite. They use surplus color
resolution to emulate ibetter spacial resolution. Over here the usual
term is "Anti-aliasing".


I admit "dithering" may be incorrect term, but I am in doubts if that 
printer (claimed to have 300dpi resolution, but not suitable for QR 
codes) has surplus color resolution. I do not mean anti-aliasing in the 
sense of adjusting pixels darkness (and color).


Consider 2 squares having size of 2.5×2.5 pixels. Non-even sizes and 
fuzzy lines variants:


█████
██████
████ ██
   ██ ██
   █████

Second variant might have sense if an image is treated as a photo 
unlikely having regular patterns with horizontal and vertical lines.

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: How does the 64bits time_t transition work?

[songbird]

Detlef Vollmann wrote:
> Is there a description anywhere how the 64bit time transition works?
> I'm currently stuck with a hard to maintain Sid system.
> It currently has "871 not upgraded" and it's nearly impossible to
> install new packages.
>
> I've looked e.g. into gnutls (on amd64), and libgnutls30t64 (3.8.3-1.1)
> as well as libgnutls30 (3.8.3-1) both install
> /usr/lib/x86_64-linux-gnu/libgnutls.so.30.37.1.
> Does the new libgnutls.so.30.37.1 provide both ABIs?
>
>Detlef

  it's an on-going transition, it may be a few weeks before
things settle down.

  that's what happens with unstable at times.

  there are the release mailing lists and the debian-devel
mailing list which will give you some idea of how things
are going.


  songbird

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: Filsystemkorruption i ext4?

[Franco Martelli]

On 20/03/24 at 09:15, Jesper Dybdal wrote:

[Sorry for the accidental Danish-language subject line :-( ]

On 2024-03-19 21:47, Franco Martelli wrote:

On 19/03/24 at 15:43, Jesper Dybdal wrote:



My plan is to boot a rescue disk and mount that partition read-only. 
Then:
* If the file looks ok after reboot, then I'll strongly suspect the 
RAM - and run memtest.

* Otherwise, I'll have to run fsck and see what happens.

kernel version:
root@nuser:~# uname -a
Linux nuser 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) 
x86_64 GNU/Linux


The partition in question is a RAID 1 controlled by md.


Another check you can perform it is on the RAID array, by default it 
runs on the first Sunday of each month at 00:57. You should have this 
file /etc/cron.d/mdadm that takes care to run this check monthly.

Good idea!  That should of course be done first.  It's running now.


Before you reboot, does it look OK /proc/mdstat ?

Yes, it seems ok.


I would suggest you to mount the filesystem yes read-only but also with 
the noload option ( … -o ro,noload … ) see "man mount" for a brief 
explanation.


Cheers

--
Franco Martelli

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: Filsystemkorruption i ext4?

[Jesper Dybdal]

I have now done the following:
* Checked the RAID array - no problems found.
* Run fsck.  It found three cases of the block count being incorrect.  I 
don't know which the other two affected files are.

* Run one pass of memtest86+.  Nothing found.

So it seems not to be a problem with the disks.
A bug in ext4?  Well, ext4 has always done its job for me wihtout problems.
A RAM error that memtest86+ did not find?  Possible.  Once upon a time, 
when you bought an ordinary pc, its RAM had ECC as a matter of course; 
unfortunately, that is not the case nowadays.


I think I'll let memtest86+ run overnight one of the coming nights.

Unless it is simply a RAM error, then it is a bit scary...

Regards,
Jesper

On 2024-03-19 21:47, Franco Martelli wrote:

On 19/03/24 at 15:43, Jesper Dybdal wrote:



My plan is to boot a rescue disk and mount that partition read-only. 
Then:
* If the file looks ok after reboot, then I'll strongly suspect the 
RAM - and run memtest.

* Otherwise, I'll have to run fsck and see what happens.

kernel version:
root@nuser:~# uname -a
Linux nuser 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) 
x86_64 GNU/Linux


The partition in question is a RAID 1 controlled by md.


Another check you can perform it is on the RAID array, by default it 
runs on the first Sunday of each month at 00:57. You should have this 
file /etc/cron.d/mdadm that takes care to run this check monthly.


Before you reboot, does it look OK /proc/mdstat ?



--
Jesper Dybdal
https://www.dybdal.dk

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: How does the 64bits time_t transition work?

[Detlef Vollmann]

Marco Moock wrote:


It currently has "871 not upgraded" and it's nearly impossible to
install new packages.


The libs will have a suffix of t64, so you need to use dist-upgrade to
upgrade the packages if they depend on the t64 libs.


No, only the package names have the 't64' suffix, the libraries
still have the same name as before.
Hence my question whether the libraries provide both ABIs.


Although, carefully read what it wants to remove. If it wants to remove
packages you need, don't hit y.


I did this before, and it threatened to remove a number
of critical packages (like qemu).  But thanks for the tip:
I just ran it again and now it's nearly only old libraries
that are removed.

Unfortunately it will upgrade packages that I don't want to,
but now the manual upgrade actually works (it didn't some
hours ago, so waiting helps ;-)

Thanks,
  Detlef

Re: How does the 64bits time_t transition work?

[Marco Moock]

Am 20.03.2024 um 09:29:12 Uhr schrieb Erwan David:

> Since I begin to have this in tetsing : and what should we do when a 
> package tries to remove other (except wait) ?
> 
> eg, now in testing upgrading nextcloud-desktop would remove 
> plasma-discover, and fwbuilder would remove cups.

Be aware that unstable or testing is, as the name says, unstable. :-)
You can file a bug report, but it will take time until every dependency
problem is fixed.

It did take ~ 2 weeks for my system to fulfill all dependencies.

-- 
kind regards
Marco

Send unsolicited bulk mail to 1710923352mu...@cartoonies.org

Re: How does the 64bits time_t transition work?

[Thomas Schmitt]

Hi,

Marco Moock wrote:
> The libs will have a suffix of t64

I wonder whether those suffixes will go away at some stage of this effort.

(Further i wonder when the package tracker appearance of libisoburn
 will become less ugly than currently:
   https://tracker.debian.org/pkg/libisoburn
 and how i shall deal with a bug report which complains about the
 inconsistent state of the control file in respect to libburn and
 libisofs:
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067103
)


Have a nice day :)

Thomas

Re: How does the 64bits time_t transition work?

[Erwan David]

Le 20/03/2024 à 09:09, Marco Moock a écrit :

Am 20.03.2024 um 08:22:16 Uhr schrieb Detlef Vollmann:


It currently has "871 not upgraded" and it's nearly impossible to
install new packages.

The libs will have a suffix of t64, so you need to use dist-upgrade to
upgrade the packages if they depend on the t64 libs.

Although, carefully read what it wants to remove. If it wants to remove
packages you need, don't hit y.

Then upgrade the packages manually and look which package creates
dependency problems.

Since I begin to have this in tetsing : and what should we do when a 
package tries to remove other (except wait) ?


eg, now in testing upgrading nextcloud-desktop would remove 
plasma-discover, and fwbuilder would remove cups.



--
Erwan David

Re: How does the 64bits time_t transition work?

[Brad Rogers]

On Wed, 20 Mar 2024 08:22:16 +0100
Detlef Vollmann  wrote:

Hello Detlef,

>Is there a description anywhere how the 64bit time transition works?

I'm far from an expert, but from what I've read, this transition is
*huge*.  Possibly the largest that has ever occurred in Debian.  It's
going to take time to get it done.  Lots, and lots, of time.  In the
meanwhile, it means a good deal of disruption in Sid/unstable.

You should already be aware that running sid comes with certain
difficulties, and if you're not prepared/willing to deal with them then,
in all likelihood, Sid isn't for you.

Following Marco's advice would be a good first step, IMO.

-- 
 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?"
Walking through town is quite scary
I Predict A Riot - Kaiser Chiefs


pgpjt0vtGOW_8.pgp
Description: OpenPGP digital signature

Re: Filsystemkorruption i ext4?

[Jesper Dybdal]

[Sorry for the accidental Danish-language subject line :-( ]

On 2024-03-19 21:47, Franco Martelli wrote:

On 19/03/24 at 15:43, Jesper Dybdal wrote:



My plan is to boot a rescue disk and mount that partition read-only. 
Then:
* If the file looks ok after reboot, then I'll strongly suspect the 
RAM - and run memtest.

* Otherwise, I'll have to run fsck and see what happens.

kernel version:
root@nuser:~# uname -a
Linux nuser 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) 
x86_64 GNU/Linux


The partition in question is a RAID 1 controlled by md.


Another check you can perform it is on the RAID array, by default it 
runs on the first Sunday of each month at 00:57. You should have this 
file /etc/cron.d/mdadm that takes care to run this check monthly.

Good idea!  That should of course be done first.  It's running now.


Before you reboot, does it look OK /proc/mdstat ?

Yes, it seems ok.

Thanks,
Jesper

--
Jesper Dybdal
https://www.dybdal.dk

Re: How does the 64bits time_t transition work?

[Marco Moock]

Am 20.03.2024 um 08:22:16 Uhr schrieb Detlef Vollmann:

> It currently has "871 not upgraded" and it's nearly impossible to
> install new packages.

The libs will have a suffix of t64, so you need to use dist-upgrade to
upgrade the packages if they depend on the t64 libs.

Although, carefully read what it wants to remove. If it wants to remove
packages you need, don't hit y.

Then upgrade the packages manually and look which package creates
dependency problems.

-- 
kind regards
Marco

Send unsolicited bulk mail to 1710919336mu...@cartoonies.org

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]

How does the 64bits time_t transition work?

[Detlef Vollmann]

Is there a description anywhere how the 64bit time transition works?
I'm currently stuck with a hard to maintain Sid system.
It currently has "871 not upgraded" and it's nearly impossible to
install new packages.

I've looked e.g. into gnutls (on amd64), and libgnutls30t64 (3.8.3-1.1)
as well as libgnutls30 (3.8.3-1) both install
/usr/lib/x86_64-linux-gnu/libgnutls.so.30.37.1.
Does the new libgnutls.so.30.37.1 provide both ABIs?

  Detlef

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&A), 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