[blibble]

so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5.

with that out of the way: you've missed the main point, and that is that it's really really hard (I would use the word impossible but I'm not 100% certain) to secure multiuser chat.

the sheer number of places that could be compromised is so high, that offering a 'secure connection' (which users associate with actually secure online commerce) is dangerously misleading.

we understand the threat model very well, and we recommend that you shouldn't trust us to secure your communications, and suggest something like fish instead.

[ahf]

Non-plaintext authentication mechanisms are a good start - it's an extra layer of security that you add to your system. Having SSL between your servers is also an extra layer of security. Having client-to-server SSL is, once again, also an extra layer of security. And so on.

We are not asking the Quakenet staff to "fix" multiuser chat encryption - leave that to the protocol developers, researchers and people working on different experimental protocols to try to "fix".

But, I still don't understand how much you refuse to step into reality and face that SSL is nice to have on a modern IRC network - we agree that it's not perfect, but do allow your users to understand the risk and let them take the necessary step to enhance the privacy of their communication.

Right now you are just hindering it where every other network is way ahead of you in this regard...

Your users are not dumb. I, as a user, want to be able to decide whether or not I connect, to a network, over SSL, where I assume that the network is able to interconnect its servers over SSL encrypted links, then I can make the decision if I want to add an extra layer of security by using software like FiSH where I can share secrets with my closets friends using, say, a pre-shared key.

Please, stop assuming that us users are idiots.

[blibble]

please stop putting words in my mouth: I never said it's not nice to have, I said I don't think it adds much value, and that I believe that it's dangerously misleading.

I've been part of running a large IRC network for more than a decade: I have seen tens of thousands of users fall for various scams, get their passwords stolen, hand their passwords out willingly, connect through 'free bouncers' that perform operations as them, get DDoS'ed, install 'pingbooster.exe', you name it.

I wouldn't call them stupid, just mostly unaware or naive, and ultimately if we are going to attempt to protect their communications them we need to take their behaviour into account.

There are also operational concerns with deploying TLS: OpenSSL is up there in the top 10 list of 'software with the most security vulnerabilities', and if our servers get hacked our users really aren't any better off.

We have a some plans (inspired by Chrome's architecture) to work around this huge issue (restarting a webserver has no impact, but you can't do this with an ircd), but it all takes time and we're volunteers.

Ultimately I am a pragmatist, I will do things that I think are necessary and that I believe can work.

[kyrra]

If I understand your reasoning, TLS for HTTP should be considered useless as well. Users do stupid things that lets their information get stolen. SSL/TLS provides one layer of security, and at least prevents plaintext sniffing of traffic.

[xnyhps]

> so we've had a solution to the credential sniffing for 10+ years: our services support AUTH via something very similar to CRAM-MD5.

Interesting. This suggests you're storing all passwords in plain, is that true?

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

[Tobu]

Here's the auth mechanism the parent is referring to: https://www.quakenet.org/development/challengeauth

mIRC and irssi can handle it through scripts.

Contrast SASL, which is supported in every client I've used: https://freenode.net/sasl/

[bentcorner]

I don't know what fish is. Is it this?

http://ultrx.net/doc/fish/