Jacob and Ori, thank you for filling in some more details. Without the specifics I had been making some wrong assumptions about where the exact threat was.
I think I now have a clearer picture: It's not particularly p9sk1 which is vulnerable, but the protocol for ticket request / response, which leaks enough information to allow offline exploration of user keys. The contribution of p9sk1 is that its handshake protocol helpfully reveals a valid user name - ie the authid - which can be used by an attacker to make a legitimate ticket request, without any need for eavesdropping or guessing at user names. So, if you have an authentication service exposed to the ipv4 internet (or to the ipv6 internet with a findable address), and your authid or a known or guessable userid has a weak enough password to succumb to a dictionary search, it's probably right to say that a random attacker could make a cpu connection or mount your file service with an afternoon's work on consumer hardware. Nobody needs to have weak passwords, though. Using the !hex attribute instead of !password with factotum, and/or using secstore(1), makes it easy to have a randomly generated DES key with the full 56 bits of entropy. This makes the attacker do more work ... but not all that much more. I hadn't kept up with how powerful commodity GPUs have become. (My most recent experience with High Performance Computing involved transputer arrays and Cray T3Ds. Nowadays I specialise in low performance computing.) It appears that investment of a few thousand dollars and a few days compute time (maybe less if using cloud services) is enough for a full brute-force exploration of the single-DES keyspace. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2867926d1deafb39060269df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
