correct, which is far from ideal (essentially we're trapped by our CRAM-MD5 support)
we've thought long and hard about this too, and don't consider it to be a large threat, as the only two people with access to the box[1] could silently replace the AUTH code and log all the passwords anyway, rendering any secured password store irrelevant.
[1]: it's not even known outside the core where the box lives, and it's also essentially completely isolated from the internet at large.
> Just looked up CRAM-MD5, and the password is used as a key to HMAC-MD5, which means you can at least store MD5'ed versions of the passwords.
In real CRAM-MD5 this is not true. It uses HMAC-MD5 of the key directly. To be able to calculate that, you need to do
MD5((key XOR opad) || ...)
Which means that you either store "key XOR opad" (not meaningfully different from storing key), or an intermediate result from MD5, which is tricky.
Quakenet's authentication mechanisms, except for LEGACY-MD5, call MD5, SHA1 and SHA256 before using it as the key, so they could store just each of those different hashes (unsalted). The LEGACY-MD5 mechanism does require the plain text password to be known by the server.
That's what I mean - store the intermediate result of the MD5(key XOR ipad) and MD5(key XOR opad). The only trickery is implementing the HMAC wrapper, but that's not very difficult.
we've thought long and hard about this too, and don't consider it to be a large threat, as the only two people with access to the box[1] could silently replace the AUTH code and log all the passwords anyway, rendering any secured password store irrelevant.
[1]: it's not even known outside the core where the box lives, and it's also essentially completely isolated from the internet at large.