Re: MD5 is insecure

[Jay Acuna via NANOG <nanog () lists nanog org>]

On Thu, Sep 4, 2025 at 7:21 AM Tom Beecher via NANOG
<nanog () lists nanog org> wrote:

> However, Cisco's implementation is not vulnerable to any currently known
> exploits, and no theoretical attack vectors don't seem to apply either.

You mean not vulnerable to an exploit whose details are currently
available to you.
It is highly probable that known exploits to MD5 hashing exist which
have much greater
value to the finders not sharing the details than the practically nonexistent
renumeration you'd get publishing.

The MD5 hash has a history of being broken for a long period of time, and no
longer used on modern systems requiring security, and is in a state where
you could reasonably presume viable preimage attack methods have been worked
out and are available to nefarious  actors, but are also not going to
be disclosed
to the public and not going to be taken up as matters for academic research.

> The fact that you make a recommendation for readers to *stop using public
> key SSH auth* because of that is , respectfully, absolutely irresponsible.

It's a silly recommendation. No matter how broken the Pubkey auth system is
by taking a MD5: it is still many orders of magnitude stronger than
password-based
authentication.   MD5 is not so broken that the potential attacks would require
less computation than cracking a hashed password.

Password-based auth with SSH only even exists for backwards compatibility with
telnet, for as long as I can remember.. the best practice is passwords  and
host-based auth should never be used with SSH other than temporarily when
migrating away from Rlogin or Telnet that used these insecure auth methods.


Passwords have to be typable by a human which greatly reduces the size of
keyspace to search, there are fewer bits involved. And the more practical issue
is verifier compromise.
Humans often set weak passwords, or don't like using multiple passwords, and
Single sign-on solutions systemize the security hole.  With password-based auth
- your password is sent in plaintext to a SSH daemon.  SSH defenses against
adversary in the middle are weaker with password-based auth.

A reused password only has to be captured a single time by one rogue SSH daemon
or one device on the network.

One of the best things you can do for authentication security is to
eliminate passwords
and use a crypto-based system. Passwords for SSH should have been
deprecated and
had support for them completely removed from all hardware a long time ago.

On first login when setting up a new piece of hardware --  The
hardware can be designed
to only permit a password that one time, then generate
and display an admin keypair to be imported into the SSH client,  then
require the admin of new equipment to log back in using that keypair
before the keypair can
be saved, and before it is made possible to finalize or save an
initial device configuration and
activate any services.

--
-JA
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/FY4DGI3K5WVKNLHWWSLRYZHGRY736PJB/