[blibble]

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.

[pixl97]

Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol.

What year is this?

[optimiz3]

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.

Add on a layer of encryption (unique key per password, keys in a separate encrypted table) and you're way better off than you are now.

Also, since MD5 can be collided, consider SSL for the login process.

[xnyhps]

> 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.

[optimiz3]

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.