On Thu, Sep 4, 2025, 20:51 Jay Acuna via NANOG <[email protected]> wrote:
> On Thu, Sep 4, 2025 at 7:21 AM Tom Beecher via NANOG > <[email protected]> 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. > This is precisely why I still avoid NIST curves where possible (favoring Edwards curves). > 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. > RFC 1186 (MD4) was published Oct. 1990. By 1991, severe weaknesses were published and several collisions found. By 1995, near-collisions could be generated in a flash. Later that year, a full revision attack had been found and published. In 2004, significant collision efficiencies were published (along with other algos in the family, including MD5). By 2007, complete collisions can be generated in 2 or less hash ops. In 2008, a 2^128 →2^102 preimage for MD4 was published. In 2010, a 2^128 →2^99.7 preimage for MD4 was published. In 1991, MD5 was designed. It was published as RFC 1321 in 1992. In 1993, pseudo-collisions were found. In 1996, the compression routine in MD5 was considered broken. It's about this time that recommendations to switch to SHA(-1) are made. 2004, MD5CRK demonstrates a working birthday attack accomplished within an hour on a p690 cluster. 2005, two x.509 certificates sharing the same hash with different public keys are published. (Improved collision construction methodology is released days after this that reduces it to a few hours on a laptop.) (A 2005 laptop, keep in mind.) 2006, collision finding can now be done within a minute on a laptop. 2010, a single-block (512B) MD5 collision is announced (but not published). 2012, the Flame malware uses a forged Microsoft code-signing certificate with MD5 collision against a valid one. 2013, colliding is down to 1/8th block (64B). As of today and public knowledge, collision finding is at 2^24.1 and with chosen-prefix, this is reduced to 2^39. 12 years is an awfully long time of silence, given MD5's much wider adoption (and still-current usage) over MD4. 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 small explicit clarification in case people are freaking out, password-based auth for SSH doesn't send the password in plaintext *over the wire*, KEX happens before auth and a shared secret key is used to encrypt the transport for the session before auth occurs. The *daemon*, however, does indeed receive the sent password, correct. > A reused password only has to be captured a single time by one rogue SSH > daemon > or one device on the network. > And for an extra fun time it has a username associated with it. This is daunting for those that use centralized auth in their org. > 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. > It's a hard line, but one I can stand behind. I also cannot stress the benefit of physical-token/FIDO2 MFA as well. It's easier than ever with OpenSSH 8.2p/8.3p (8.3p adds verify-required). Though net kit may be a fair bit away from this, and from my understanding IOS doesn't use OpenSSH (or a fork thereof) whatsoever - they have a 100% in-house-developed sshd. > 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. This is precisely what I set up for my org's jumpboxes/bastions. I'm sysops, not netops, though - so I have a significantly higher amount of flexibility in this particular context. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/IPJ2FPWTJAGCBVZXC2DKYDNX7BGUK5DI/
