XSF Discussion - 2020-12-08

SamWhited: I don't quite get the reasoning for prefering PLAIN over MD5 in <https://xmpp.org/extensions/xep-0438.html#pinning> (and in draft-ietf-kitten-password-storage-02).

RFC 6331 !

Holger: MD5 can be broken in a few minutes on a normal laptop and if you use it you can't hash the password on the server. Plain doesn't protect the password in transit (just like MD5) but the server can hash and compare against bcrypt or something, so it does protect it at rest.

All true of course, but this is about a client preference list, not about the question "should servers store clear-text", no?

I.e. are these reasonings relevant to the client in the situation where the server offers MD5 + PLAIN?

Yes. The client should prefer the thing that gives the server the flexibility to drop MD5 later.

That's the part I don't get, I guess :-)

Also it says not to support MD5 at all, so plain just wins by default

I half-get that part.

We're trying to make the upgrade path smooth. We can't necessarily guarantee that any given server is doing good things with our data, but we can at least encourage them not to do bad things by not supporting and using them ourselves.

Hm k, fair enough.

I should probably remove MD5 from that example ordering entirely; it's just there for the purpose of example while the actual normative text says not to use MD5 at all but it's probably confusing having it in a list

with that line of argument, you should always use PLAIN, even if SCRAM is offered

That reasoning sounds a bit twisted to my ears.

jonas’: for hash agility? I tend to agree with that, but I know most people won't.

I'm not sure I like such twists in documents that make security recommendations. Esp. if those twists aren't made very explicit.

I should make it more explicit then. I don't think it's a twist though: MD5 is broken and deprecated, there is another RFC by experts that says so seems like a pretty straight forward reason not to use it to me.

Right now the reasoning reads bogus to me and reduces the confidence I have into those documents.

then again, I also don’t understand why what a client uses (when faced with multiple choices) has any influence on what a server does

assuming that PLAIN is not supported by clients because they always pick DIGEST-MD5 when faced with PLAIN + DIGEST-MD5 is not quite realistic

It has an influence when the server admin wants to upgrade but they have a hundred customers still using MD5 that they'd have to migrate and they decide not to bother.

But I agree it's not likely to happen in real life, and also the text that ranks them is literally just an example. I'll just remove MD5 from it entirely.

SamWhited: We have already spoken about MD5 previously, I am very happy to see other people too :)

What I see in practice is effects such as: (1) Back in the days, people deemed MD5 more secure[tm] than PLAIN. So clients such as Psi disabled PLAIN by default, only allowing MD5. (2) Today, people read security docs such as yours and explicitly disable MD5 in ejabberd configs, PLAIN still being permitted. Result: Psi can no longer log in. Security win: Non-existent.

I'm all for security improvements. But only if they actually improve security.

Oh I see, that's where I disagree then. I think that is a good thing and we should be pushing for MD5 to be deprecated.

If it means ancient clients can't log in, so be it. Let's not let them hold us back from deprecating an actually broken mechanism.

it’s not more broken than PLAIN though

It is more broken than plain because if servers support it they can't do any other sort of hashing.

In my scenario the client doesn't hold us back from anything. We just break auth for no reason at all.

With DIGEST-MD5 your security is just entirely broken. With PLAIN you at least get the same level of transport security as the web if you're using TLS, and at rest you get good hash agility and strong hashing.

In my scenario the server has plain-text passwords.

SamWhited, ok, that’s not wrong, but that should go in server recommendations then, not client recommendations.

If the server only has hashes, MD5 will just not work anyway. That's fine and in that case there's nothing to discuss.

We're only talking about the scenario where the server has plain-text passwords.

That's a good idea, maybe it's in the wrong section. Client recommendations just say "Don't use MD5 and prefer SCRAM to plain" and server recommendations say "Don't support MD5, if you support plain use bcrypt" or something.

Holger: why does the server have plain-text passwords at all?

SamWhited: That question is entirely unrelated to the client preference list.

There's reasons for having plain-text passwords. Other services needing them anyway or whatever. Unrelated.

I'm obviously all for suggesting server admins to prefer hashing passwords _if_ they don't need clear-text.

I disagree, in most environments I believe that's an unacceptable way to do things. There may of course be super specific niche use cases for it, but this document is meant to be a general security document which can't cater to every niche use case or it would have to say "It's good to use TLS, but you don't have to, and it's good to have authentication at all, but you can trust the network or just everybody, etc."

These are best practices, not overall global rules and I think that's the only practical way to write a document like this.

SamWhited: 👍

I work for a university and we're running various commercial software that requires clear-text passwords. I don't think we're super-niche. But that's all completely besides the point.

Again, that's fine, I just don't think a best practices document needs to cater to that

I disagree with documents having to be written like this, but whatever.

If it matters to you maybe it's worth bringing it up on the kitten list so the actual experts can weigh in?

Doesn't matter enough to me :-)

But thanks for your feedback, I might disagree but get your idea now.

For now based on this feedback I'm going to remove DIGEST-MD5/CRAM-MD5 from the example ordering because it seems to be confusing in general (some people didn't read the rest of the text and assumed that meant they should be supported, others just disagreed with the ordering somewhat like this even though it doesn't matter since they're just deprecated) and I'll re-evaluate what belongs in client/server best practices.

Thanks for bringing it up

👍 Removing it altogether makes more sense to me.

SCRAM-SHA-1 has been MTI in XMPP, and DIGEST-MD5 has been deprecated since 2011. I'm all in favor of considering it dead.

regarding Psi doesn't login anymore. with which sasl mechanisms?

SCRAM-SHA-1 works for years there..

rion: Yeah may well just be old versions affected.

And/or Tkabber?

Forgot.

I remember "allow plaintext auth: no" knobs in both, and in the past this meant "no PLAIN, just MD5".

btw how to force ejabberd to offer other than scram-sha-1 scram mechs?

> And/or Tkabber? I guess this one is really dead for years.

Other SCRAM mechanisms weren't supported until very recently (committed during the past few days).

Holger: out of curiosity, how did you handle supporting multiple SCRAM mechanisms? Only allow the one negotiated by the client or do you store multiple sets of SCRAM bits?

Or force dropping back to plain text storage?

I always use ejabberd for all my local tests. So this is somewhat important to me :)

rion: Use the current Git code :-)

SamWhited: So far we (the code isn't by me) only store a single hash.

Same in prosody

So the client can only use that mechanism. Unless the admin has plain-text storage of course (which is still the default).

Okay, thanks. I'd be really curious if you have issues with eg. people who use Conversations and Dino and Converations logs in with SCRAM-SHA-256 first so now Dino can never log in again because it doesn't support it (it might, I have no idea, just an example)

THE DEFAULT?

SamWhited, it’s not so much about logging in as much as about what happens during initial account provisioning

SamWhited: I'm sure we'll run into those. Which is the reason I wasn't looking all that much forward to SRAM-XXX support.

Yah, I'm not a huge fan of SCRAM for this reason among others.

and the problem with that is obviously that mechanisms are listed pre-auth, so there’s no way to do hash agility with scram without plain storage

jonas’, don't look at prosodys defaults

Zash, I was under the impression that internal_hashed is the default nowadays?

jonas’, you can store multiple sets of hashes

Zash, yeah, but you would’ve had to have those stored like 10 years ago

jonas': ejabberd support SIP by default, among other things :-)

I wrote eIBR with an aim to solve this somewhat, but it's still not great that we have to work around this with a separate protocol

Holger, how’s that an excuse for storing plaintext by default?

SIP needs it?

does it?

Yes.

I don’t know SIP really, but I fail to imagine a protocol which forces plain-text credential storage on the server side

And so does TURN if you don't do XEP-0215, for example.

jonas’, default/template config file doesn't necessarily match the built-in defaults...

Zash, ok, right, I judge by the default config file :)

Oof, both of these things hurt me.

Holger, then again, I’m super tired and exhausted and maybe my imagination is just lacking

SamWhited: Aha! Revenge for your anti-SCRAM propaganda!!!1! :P

jonas': Well any protocol which does MD5 auth or something like that.

hah, fair enough. Jokes aside though, this sort of basic configuration and policy thing is how security issues happen. It's almost never a directed malicious actor you have to worry about, it's things that confuse the user or don't actually do what they say on the tin that causes someone to configure something badly,or they don't configure it and it's insecure by default and their database gets stolen or whatever

Holger, how do you deal with FIPS mode or whatsitcalled where even thinking "md5" gets you SIGKILL'd?

Holger, right m(

jonas': I.e. "avoid transmitting plain-text password by transmitting a MAC/hash instead", which requires the clear-text password as input. A decade or two ago, everyone did that because security.

Zash: Er, there's something where leaving it to the admin isn't good enough?

Holger, yeah, right, makes sense

especially for stuff like SIP

Holger: Someone had trouble because Prosody uses md5 in a non-security thing and it would hit an assert or something in OpenSSL in FIPS mode because you're not allowed to touch it.

Much fun.

Ah eww.

Does anyone happen to have machine-readable compliance suite data?

{"compliance_suites": "https://xmpp.org/extensions/xep-0443.html"}

*ducks as things are thrown*

That would be nice to have.

as we all know only XML is machine readable

or... everything is machine readable given the right regex

define(brain, machine)

If "readable" is qualified by "given the right regex", pretty sure that makes XML unreadable.

Surely PCRE can do it

A thing that reads a DOAP and tells you what compliance level you're at would be nice

Fair. I'll move the goal posts and claim I always meant that "readable" includes "on a machine with finite memory" too then :)

you can absolutely parse XML and even HTML with a regex

Zash: Link Mauve worked on a DOAP parser afaik. For exactly that

can != should though :)

moparisthebest: can you? Jokes aside, I think namespaces aren't regular and if you use PCRE you can define input that would result in very large expansions

But I dunno, haven't really thought about it, I think that's just an assumption I've had for a long time that I've never bothered to verify.

The internet suggets that I am wrong, but what does the internet know?

I suspect you *could* fully support everything, you just wouldn't want to, but it works fine for simple cases

ahh, no, I know exactly why it's impossible: XML allows infinite nesting but the point of regular expressions it to be able to use finite automata ("finite" being the important part)

Anyways, sorry, stupid academic tangent that doesn't matter but is kind of interesting. Like you said: "don't do it"

XML itself, namespaces or not, is not regular.

many "regular expression" engines are also not regular though :)

we need someone stubborn enough yet also well versed in sed enough to give it a go, if only we knew the guy who implemented an XMPP client in sed...

if only!

I do not interact with such crazyfolk!

Zash: to your original question, the XEP source might not be the worst thing in the world to parse? I mean, it's not ideal, but it's probably not too difficult to get the data out

I think the table layout is consistent between the various suites

mostly, I think

5×2×2 CS sub-suites :|

In regards to SCRAM support in SIP: I started looking at writing an IETF draft on this. (@Neustradamus was talking to me about this for quite some time now.) I can't say how much interest there would be in IETF for this.

I really need to rename my nick. I am Alexey Melnikov

Алексей: I keep meaning to ask you, are you thinking about submitting your SCRAM-SASL-3 and SHA-512 drafts to the working group or are you going the self-publishing route with those?

I'm not 100% what trolling is, but I fear I may have just done it.