Re: Root password strength
On Wed, Mar 20, 2024 at 1:32 AM <tomas@tuxteam.de> 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.
As far as the certificate, I suspect it alludes to public key. Both
IPSec and SSH can use public key cryptography (as opposed to
passwords), so they are about equally secure (compared to passwords).
IPSec is actually a little stronger with provable security properties
because it uses HKDF after key agreement to derive bulk encryption
keys. And I believe IPSec performs a key conformation step, which
helps with the security proofs.
The IPSec standard is maintained by Hugo Krawczyk and associates. Hugo
is a world class cryptographer. That's why the IPSec protocol does not
have the theoretical defects of SSH (or TLS).
Krawczyk is also the author of The Order of Encryption and
Authentication for Protecting Communications,
<http://www.iacr.org/archive/crypto2001/21390309.pdf>. It is a very
good paper.
> They are doing the same dance (key exchange, key pair validation, session
> key establishment) -- the "certificate" part is just a step further (and,
> BTW, SSH can do that, too), which just eases key management (at the expense
> of security: you have but one more moving part).
>
> The "port" thing stays the same: the VPN server uses a TCP connection, too.
>
> Moving the port to a non-standard number, using fail2ban, firewall knocking
> and those things don't increase security *directly* -- they just remove
> noise from the logs, which eases the admin's task and thus increase security
> indirectly.
>
> There's no magic.
Jeff
Reply to: