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.
Dan Ritter <[email protected]> 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
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.)
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.
On Wed, Mar 20, 2024 at 1:32 AM <[email protected]> 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.
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]
On 20 Mar 2024 15:46 +0800, from [email protected] (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 [...]
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?
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
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.
On 20/3/24 19:03, Michael Kj�rling wrote:
On 20 Mar 2024 15:46 +0800, [email protected] (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.
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.
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).
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!
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 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.
it should be like 32 symbols with special symbols? Or this paragraph
in a handbook is rather paranoid?
It's not paranoid.
On 20 Mar 2024 15:45 +0100, from [email protected] (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.
A phrase you will easily remember but that would be hardcore to guess
through social engineering is perfect.
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.
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.
Use one of the password generating programs such as pwgen to produce a
12 character random password. Write it down.
Writing down a password is a bad idea.
On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue <[email protected]> wrote:
John Hasler <[email protected]> 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.
Pierre-Elliott Bécue writes:
Writing down a password is a bad idea.
Why?
Use one of the password generating programs such as pwgen to produce a
12 character random password. Write it down.
On Wed, 20 Mar 2024 17:09:31 +0100
Pierre-Elliott Bécue <[email protected]> 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.
On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue <[email protected]> wrote:
Jeffrey Walton <[email protected]> wrote on 20/03/2024 at 17:19:46+0100:
On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue <[email protected]> wrote:
John Hasler <[email protected]> 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.
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.
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.
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).
On 20 Mar 2024 18:46 +0100, from [email protected] (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.
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
Actually, I use between pwgen -n 8 (user pw) and pwgen -n 16 (LUKS encryption).
I memorize the most important of them.
[[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 <[email protected]> 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.
On Wed, Mar 20, 2024 at 1:45 PM Pierre-Elliott Bécue <[email protected]> wrote:
Jeffrey Walton <[email protected]> wrote on 20/03/2024 at 18:30:34+0100:
On Wed, Mar 20, 2024 at 12:51 PM Pierre-Elliott Bécue <[email protected]> wrote:
Jeffrey Walton <[email protected]> wrote on 20/03/2024 at 17:19:46+0100: >> >>
On Wed, Mar 20, 2024 at 12:09 PM Pierre-Elliott Bécue <[email protected]> wrote:
John Hasler <[email protected]> wrote on 20/03/2024 at 16:58:01+0100: >> >> >>
Pierre-Elliott Bécue writes:
A phrase you will easily remember but that would be hardcore to guess
through social engineering is perfect.
Better is a random string that you write down. When people try to >> >> >> > generate phrases that meet those requirements they usually fail.
Writing down a password is a bad idea.
I don't think that's true anymore. The threat being mitigated is the
network attacker. The network attacker cannot (yet) reach through a
monitor and read a sticky note.
Mitigating a specific threat by adding a new one is not a proper way to >> >> handle a threat when one can avoid both.
What does your threat model look like?
My home sees plenty different people coming in. Some I trust, some I
trust less. Also videocalls is a nice way to get a paper password
recorded (and yes it happens).
So now you are arguing someone jumps on a Zoom call, and then displays
their passwords to the camera. If we are going to use far-fetched
examples, then write the password down with invisible ink. Recover it
when needed using the special pen provided with the junior spy kit.
Same goes for company.
Companies generally have physical security on their assets. No one is
going to wander in the server room unsupervised. No one is going to
wander the cubicles lifting mouse pads and looking through drawers
without raising suspicion.
If someone is allowed to do those things, then the company's controls
are not going to be very helpful, and the company has bigger problems.
Are spouses who go through a purse or wallet to retrieve a company
password a threat in your model? If that's the case, then you have
compensating controls to mitigate the threat, like physical security
on the office workspace.
It is also why its Ok for a system to generate a list of recovery
codes, and have the user print them and store them in a safe place.
The other option are those cursed security questions, which have been >> >> > insecure for about 20 years now (but developers have their arms
wrapped around).
A recovery code is generally designed to troubleshot 2FA issues, not as >> >> a replacement for the first layer of security that a password is.
I believe recovery codes to regain access to an account due to a lost
or forgotten password predates 2FA. Most businesses I've worked with
use a Self-Service scheme, like recovery codes, to avoid the Help Desk
call. Some use the cursed security questions.
Yes, but in that case there's another point, which is a contact mail
address.
And even this way it's problematic.
I am aware some European banks use Temporary Access Numbers (TANs) as
a form of 2FA. (I've never seen them used in the US). Each month a
[new] TAN is included with the printed and mailed account statement.
The "postal channel" is considered reasonably secure. Again, the
threat being mitigated is the network attacker, not a nosy spouse.
Again, trying to mitigate one threat by creating a full range of other
threats is the receipe for disaster.
I think you are throwing the baby out with the bathwater. Taking a big problem (the network attacker) and reducing it to a smaller problem
(securing recovery codes) reduces risk.
I read about account compromises all the time. The creative ones use
SIM swaps to circumvent 2FA. I can't remember an instance of an
account compromise because a thief stole a wallet or safe.
And therefore if it were to circuvent this first layer, then no, it's
not ok to print them, except if you indeed have a safe.
But in general it's a better approach to avoid having to resort to
printed password on a paper.
Humans are human. We have to understand their psychology and
limitations. Part of that is realizing a user cannot possibly remember
all the passwords required in the internet age. A big part of the
problem is what is known as the "Selfish Security Model for Password
Authentication." Each website wants a user to have an account and
manage a password. It is an impossible feat for folks to accomplish,
and that's why problems like password reuse across security domains
happens.
Noone asks someone to remember more than two or three passwords. The
rest belongs to a password manager.
Huh? This is discussed in detail in Peter Gutmann's Engineering
Security, <https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf>,
Chapter 7. In particular, pages 565-567 discussed the Selfish Security
Model.
And people can do whatether they want, it doesn't make it anything other
than a bad practice if it is one because 80% of a population does it.
Agreed. You have to have a security model and model the threats. I
don't see much of that going on in this thread.
On Wed, Mar 20, 2024 at 1:47 PM Pierre-Elliott Bécue <[email protected]> wrote:
Brad Rogers <[email protected]> wrote on 20/03/2024 at 18:39:30+0100:
On Wed, 20 Mar 2024 17:09:31 +0100
Pierre-Elliott Bécue <[email protected]> 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
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.
чт, 21 мар. 2024 г. в 22:34, Alexander V. Makartsev <[email protected]>:
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
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).
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.
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..
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:09:34 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,857 |