4 ms·

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: y

by blibble 13y ago

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.

xnyhps 13y ago
> 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 13y ago
  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 13y ago
    Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol. What year is this?
  - deleted 13y ago
    [deleted]
    - blibble 13y ago
      as I said it's not ideal. the only point of entry onto the machine is via the auth service, so if you get in that way you have access to it. it's not a matter of injecting code, it's literally one line to run spin up gdb attached to the process, and then one/two more more lines inside gdb to put a breakpoint on the line and print the variables on the stack when it's hit. add in the fact that something like 95% of our users reconnect every 24 hours, so you get the vast majority very quickly. yes, if the admins go rogue then we're screwed, but the same is true nearly always as they're the guys that set up the defences in the first place.
  - optimiz3 13y ago
    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 13y ago
      > 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 13y ago
        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.
ahf 13y ago
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 13y ago
  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.
bentcorner 13y ago
I don't know what fish is. Is it this? http://ultrx.net/doc/fish/ http://ultrx.net/doc/fish/
Tobu 13y ago
Here's the auth mechanism the parent is referring to: https://www.quakenet.org/development/challengeauth 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/ https://freenode.net/sasl/

by blibble 13y ago

xnyhps 13y ago

> 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 13y ago
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 13y ago
  Unencrypted password storage. Easily reversible (or bruteforced) authentication. Easily MITMed protocol. What year is this?
- deleted 13y ago
  [deleted]
  - blibble 13y ago
    as I said it's not ideal. the only point of entry onto the machine is via the auth service, so if you get in that way you have access to it. it's not a matter of injecting code, it's literally one line to run spin up gdb attached to the process, and then one/two more more lines inside gdb to put a breakpoint on the line and print the variables on the stack when it's hit. add in the fact that something like 95% of our users reconnect every 24 hours, so you get the vast majority very quickly. yes, if the admins go rogue then we're screwed, but the same is true nearly always as they're the guys that set up the defences in the first place.
- optimiz3 13y ago
  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 13y ago
    > 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 13y ago
      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.

ahf 13y ago

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 13y ago
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.

bentcorner 13y ago

I don't know what fish is. Is it this? http://ultrx.net/doc/fish/ http://ultrx.net/doc/fish/

Tobu 13y ago

Here's the auth mechanism the parent is referring to: https://www.quakenet.org/development/challengeauth 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/ https://freenode.net/sasl/