HolgerSamWhited: 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).
ZashRFC 6331 !
Ca_Gihas left
Ca_Gihas joined
SamWhitedHolger: 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.
pasdesushihas left
pasdesushihas joined
HolgerAll true of course, but this is about a client preference list, not about the question "should servers store clear-text", no?
HolgerI.e. are these reasonings relevant to the client in the situation where the server offers MD5 + PLAIN?
SamWhitedYes. The client should prefer the thing that gives the server the flexibility to drop MD5 later.
HolgerThat's the part I don't get, I guess :-)
SamWhitedAlso it says not to support MD5 at all, so plain just wins by default
HolgerI half-get that part.
SamWhitedWe'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.
HolgerHm k, fair enough.
SamWhitedI 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
jonas’with that line of argument, you should always use PLAIN, even if SCRAM is offered
HolgerThat reasoning sounds a bit twisted to my ears.
SamWhitedjonas’: for hash agility? I tend to agree with that, but I know most people won't.
HolgerI'm not sure I like such twists in documents that make security recommendations. Esp. if those twists aren't made very explicit.
SamWhitedI 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.
HolgerRight now the reasoning reads bogus to me and reduces the confidence I have into those documents.
jonas’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
jonas’assuming that PLAIN is not supported by clients because they always pick DIGEST-MD5 when faced with PLAIN + DIGEST-MD5 is not quite realistic
fuanahas joined
SamWhitedIt 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.
SamWhitedBut 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.
fuanahas left
fuanahas joined
NeustradamusSamWhited: We have already spoken about MD5 previously, I am very happy to see other people too :)
HolgerWhat 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.
HolgerI'm all for security improvements. But only if they actually improve security.
SamWhitedOh 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.
SamWhitedIf 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.
jonas’it’s not more broken than PLAIN though
pasdesushihas left
pasdesushihas joined
pasdesushihas left
SamWhitedIt is more broken than plain because if servers support it they can't do any other sort of hashing.
pasdesushihas joined
HolgerIn my scenario the client doesn't hold us back from anything. We just break auth for no reason at all.
SamWhitedWith 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.
HolgerIn my scenario the server has plain-text passwords.
jonas’SamWhited, ok, that’s not wrong, but that should go in server recommendations then, not client recommendations.
HolgerIf the server only has hashes, MD5 will just not work anyway. That's fine and in that case there's nothing to discuss.
HolgerWe're only talking about the scenario where the server has plain-text passwords.
SamWhitedThat'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.
rionhas joined
SamWhitedHolger: why does the server have plain-text passwords at all?
HolgerSamWhited: That question is entirely unrelated to the client preference list.
HolgerThere's reasons for having plain-text passwords. Other services needing them anyway or whatever. Unrelated.
HolgerI'm obviously all for suggesting server admins to prefer hashing passwords _if_ they don't need clear-text.
SamWhitedI 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."
SamWhitedThese are best practices, not overall global rules and I think that's the only practical way to write a document like this.
rionSamWhited: 👍
HolgerI 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.
pasdesushihas left
pasdesushihas joined
SamWhitedAgain, that's fine, I just don't think a best practices document needs to cater to that
HolgerI disagree with documents having to be written like this, but whatever.
SamWhitedIf it matters to you maybe it's worth bringing it up on the kitten list so the actual experts can weigh in?
HolgerDoesn't matter enough to me :-)
HolgerBut thanks for your feedback, I might disagree but get your idea now.
SamWhitedFor 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.
SamWhitedThanks for bringing it up
Holger👍 Removing it altogether makes more sense to me.
pasdesushihas left
pasdesushihas joined
adiaholichas left
ZashSCRAM-SHA-1 has been MTI in XMPP, and DIGEST-MD5 has been deprecated since 2011. I'm all in favor of considering it dead.
rionregarding Psi doesn't login anymore.
with which sasl mechanisms?
rionSCRAM-SHA-1 works for years there..
pasdesushihas left
pasdesushihas joined
Holgerrion: Yeah may well just be old versions affected.
HolgerAnd/or Tkabber?
HolgerForgot.
HolgerI remember "allow plaintext auth: no" knobs in both, and in the past this meant "no PLAIN, just MD5".
adiaholichas joined
Andrzejhas joined
rionbtw how to force ejabberd to offer other than scram-sha-1 scram mechs?
wladmishas joined
fuanahas left
fuanahas joined
rion> And/or Tkabber?
I guess this one is really dead for years.
HolgerOther SCRAM mechanisms weren't supported until very recently (committed during the past few days).
fuanahas left
pasdesushihas left
SamWhitedHolger: 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?
SamWhitedOr force dropping back to plain text storage?
rionI always use ejabberd for all my local tests. So this is somewhat important to me :)
andyhas left
Ca_Gihas left
Holgerrion: Use the current Git code :-)
Ca_Gihas joined
andyhas joined
HolgerSamWhited: So far we (the code isn't by me) only store a single hash.
ZashSame in prosody
HolgerSo the client can only use that mechanism. Unless the admin has plain-text storage of course (which is still the default).
SamWhitedOkay, 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)
jonas’THE DEFAULT?
jonas’SamWhited, it’s not so much about logging in as much as about what happens during initial account provisioning
HolgerSamWhited: I'm sure we'll run into those. Which is the reason I wasn't looking all that much forward to SRAM-XXX support.
SamWhitedYah, I'm not a huge fan of SCRAM for this reason among others.
jonas’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
Zashjonas’, don't look at prosodys defaults
jonas’Zash, I was under the impression that internal_hashed is the default nowadays?
Zashjonas’, you can store multiple sets of hashes
jonas’Zash, yeah, but you would’ve had to have those stored like 10 years ago
Holgerjonas': ejabberd support SIP by default, among other things :-)
SamWhitedI 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
jonas’Holger, how’s that an excuse for storing plaintext by default?
HolgerSIP needs it?
jonas’does it?
HolgerYes.
jonas’I don’t know SIP really, but I fail to imagine a protocol which forces plain-text credential storage on the server side
HolgerAnd so does TURN if you don't do XEP-0215, for example.
Zashjonas’, default/template config file doesn't necessarily match the built-in defaults...
jonas’Zash, ok, right, I judge by the default config file :)
SamWhitedOof, both of these things hurt me.
jonas’Holger, then again, I’m super tired and exhausted and maybe my imagination is just lacking
ZashSamWhited: Aha! Revenge for your anti-SCRAM propaganda!!!1! :P
Holgerjonas': Well any protocol which does MD5 auth or something like that.
SamWhitedhah, 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
ZashHolger, how do you deal with FIPS mode or whatsitcalled where even thinking "md5" gets you SIGKILL'd?
jonas’Holger, right m(
Holgerjonas': 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.
Andrzejhas left
Alexhas left
Alexhas joined
Andrzejhas joined
HolgerZash: Er, there's something where leaving it to the admin isn't good enough?
jonas’Holger, yeah, right, makes sense
jonas’especially for stuff like SIP
ZashHolger: 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.
ZashMuch fun.
HolgerAh eww.
APachhas left
xsfhas left
xsfhas joined
Andrzejhas left
Ca_Gihas left
Ca_Gihas joined
Kevhas left
Kevhas joined
Алексейhas joined
serge90has left
Ca_Gihas left
Ca_Gihas joined
paulhas left
Lancehas joined
krauqhas left
krauqhas joined
Ca_Gihas left
Ca_Gihas joined
APachhas joined
Guushas left
antranigvhas left
alameyohas left
alameyohas joined
alameyohas left
Ca_Gihas left
Ca_Gihas joined
Adihas joined
Andrzejhas joined
Lancehas left
Guushas joined
alameyohas joined
govanifyhas left
govanifyhas joined
Ca_Gihas left
Ca_Gihas joined
alex-a-sotohas left
alex-a-sotohas joined
Ca_Gihas left
Ca_Gihas joined
werdanhas joined
andrey.ghas joined
Ca_Gihas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
antranigvhas joined
LNJhas left
Ca_Gihas left
Ca_Gihas joined
LNJhas joined
Lancehas joined
Lancehas left
Lancehas joined
mdoschhas left
mdoschhas joined
Ca_Gihas left
Ca_Gihas joined
stpeterhas joined
stpeterhas left
SnowCodehas left
SnowCodehas joined
Andrzejhas left
krauqhas left
krauqhas joined
neshtaxmpphas left
SnowCodehas left
SnowCodehas joined
paulhas joined
neshtaxmpphas joined
Ca_Gihas left
Ca_Gihas joined
govanifyhas left
govanifyhas joined
lorddavidiiihas left
peetahhas left
peetahhas joined
lorddavidiiihas joined
xsfhas left
xsfhas joined
pasdesushihas joined
ZashDoes anyone happen to have machine-readable compliance suite data?
moparisthebestas we all know only XML is machine readable
moparisthebestor... everything is machine readable given the right regex
Zashdefine(brain, machine)
SamWhitedIf "readable" is qualified by "given the right regex", pretty sure that makes XML unreadable.
ZashSurely PCRE can do it
ZashA thing that reads a DOAP and tells you what compliance level you're at would be nice
SamWhitedFair. I'll move the goal posts and claim I always meant that "readable" includes "on a machine with finite memory" too then :)
moparisthebestyou can absolutely parse XML and even HTML with a regex
wurstsalatZash: Link Mauve worked on a DOAP parser afaik. For exactly that
moparisthebestcan != should though :)
SamWhitedmoparisthebest: 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
SamWhitedBut 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.
SamWhitedThe internet suggets that I am wrong, but what does the internet know?
moparisthebestI suspect you *could* fully support everything, you just wouldn't want to, but it works fine for simple cases
SamWhitedahh, 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)
SamWhitedAnyways, sorry, stupid academic tangent that doesn't matter but is kind of interesting. Like you said: "don't do it"
jonas’XML itself, namespaces or not, is not regular.
jonas’many "regular expression" engines are also not regular though :)
moparisthebestwe 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...
jonas’if only!
jonas’I do not interact with such crazyfolk!
Yagizahas left
Yagizahas joined
SamWhitedZash: 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
SamWhitedI think the table layout is consistent between the various suites
jonas’mostly, I think
Andrzejhas left
Andrzejhas joined
Ca_Gihas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
alex-a-sotohas left
Marandahas left
krauqhas left
krauqhas joined
Zash5×2×2 CS sub-suites :|
Ca_Gihas left
Ca_Gihas joined
Marandahas joined
APachhas left
Andrzejhas left
Andrzejhas joined
govanifyhas left
govanifyhas joined
Ca_Gihas left
intosihas left
Ca_Gihas joined
NosoyHacker404has left
NosoyHacker404has joined
stpeterhas joined
stpeterhas left
Ca_Gihas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
intosihas joined
Ca_Gihas left
Ca_Gihas joined
Kevhas left
Kevhas joined
alameyohas left
APachhas joined
edhelashas left
antranigvhas left
lorddavidiiihas left
lorddavidiiihas joined
Ca_Gihas left
Ca_Gihas joined
intosihas left
lovetoxhas joined
stpeterhas joined
stpeterhas left
lovetoxhas left
lovetoxhas joined
Алексей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.
intosihas joined
pasdesushihas joined
edhelashas joined
pasdesushihas left
pasdesushihas joined
pasdesushihas left
pasdesushihas joined
antranigvhas joined
pasdesushihas left
pasdesushihas joined
АлексейI really need to rename my nick. I am Alexey Melnikov
Ca_Gihas left
Ca_Gihas joined
Kevhas left
SamWhitedАлексей: 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?
pasdesushihas left
Kevhas joined
intosihas left
antranigvhas left
Andrzejhas left
Ca_Gihas left
Ca_Gihas joined
Алексейhas left
florettahas left
Kevhas left
pasdesushihas joined
mukt2has joined
Ca_Gihas left
Ca_Gihas joined
lorddavidiiihas left
Ca_Gihas left
Ca_Gihas joined
mukt2has left
pasdesushihas left
alameyohas joined
Ca_Gihas left
Ca_Gihas joined
lorddavidiiihas joined
Yagizahas left
pasdesushihas joined
florettahas joined
Andrzejhas joined
Andrzejhas left
Andrzejhas joined
Ca_Gihas left
Ca_Gihas joined
guus.der.kinderenhas joined
stpeterhas joined
stpeterhas left
Ca_Gihas left
Ca_Gihas joined
lorddavidiiihas left
Andrzejhas left
Ca_Gihas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
lorddavidiiihas joined
antranigvhas joined
APachhas left
APachhas joined
pasdesushihas left
Ca_Gihas left
guus.der.kinderenhas left
Ca_Gihas joined
Ca_Gihas left
Ca_Gihas joined
pasdesushihas joined
werdanhas left
pasdesushihas left
guus.der.kinderenhas joined
guus.der.kinderenhas left
guus.der.kinderenhas joined
pasdesushihas joined
Mikaelahas left
Ca_Gihas left
intosihas joined
Ca_Gihas joined
chronosx88has left
chronosx88has joined
guus.der.kinderenhas left
Ca_Gihas left
Ca_Gihas joined
deuillhas left
DebXWoodyhas left
deuillhas joined
pasdesushihas left
pasdesushihas joined
Ca_Gihas left
Ca_Gihas joined
intosihas left
lorddavidiiihas left
krauqhas left
krauqhas joined
pasdesushihas left
andrey.ghas left
Ca_Gihas left
Ca_Gihas joined
goffihas left
Ca_Gihas left
Ca_Gihas joined
pasdesushihas joined
Andrzejhas joined
Ca_Gihas left
Ca_Gihas joined
chronosx88has left
chronosx88has joined
pasdesushihas left
pasdesushihas joined
Ca_Gihas left
Ca_Gihas joined
waqashas left
pasdesushihas left
debaclehas left
Ca_Gihas left
Ca_Gihas joined
Andrzejhas left
Andrzejhas joined
stpeterhas joined
stpeterhas left
Ca_Gihas left
Ca_Gihas joined
pasdesushihas joined
Tobiashas left
pasdesushihas left
Andrzejhas left
Andrzejhas joined
Ca_Gihas left
Ca_Gihas joined
nycohas left
pasdesushihas joined
Ca_Gihas left
Ca_Gihas joined
pasdesushihas left
pasdesushihas joined
rionhas left
Ca_Gihas left
Ca_Gihas joined
Andrzejhas left
pasdesushihas left
jcbrandhas left
Ca_Gihas left
Ca_Gihas joined
Andrzejhas joined
NosoyHacker404has left
stpeterhas joined
stpeterhas left
Ca_Gihas left
Ca_Gihas joined
serge90has joined
Andrzejhas left
Andrzejhas joined
pasdesushihas joined
nycohas joined
pasdesushihas left
pasdesushihas joined
Andrzejhas left
Andrzejhas joined
peetahhas left
peetahhas joined
pasdesushihas left
Ca_Gihas left
Ca_Gihas joined
SnowCodehas left
mukt2has joined
chronosx88has left
chronosx88has joined
Kevhas joined
KevI'm not 100% what trolling is, but I fear I may have just done it.