XSF Discussion - 2020-05-11

Metronome if the internal hashed auth backend is used just stores sha-1/256/384/512 server keys hash variants in the account credentials datastore whenever a password is generated

So it's more if you see DIGEST-MD5 offered to be a symptom that passwords are stored in plain

Just reading back, I'm not actually sure of the reason I made SASL2 use a distinct stream feature. But as I've previously said, anything that makes SASL2 have a namespace bump to urn:xmpp:sasl:2 is fine by me. :-)

Also: https://tools.ietf.org/html/rfc5802#section-6.1 does indeed say that servers MUST tls-unique, and that clients SHOULD. But all normative requirements can be altered by negotiation, meaning that clients implicitly MAY use anything that the server explicitly says it can support.

Thanks people to look SCRAM-SHA-256 and TLS Binding for -PLUS SCRAM variants.

larma, Final note - we're stuck with -PLUS because that comes from the SASL layer (or quite possibly the GS2 layer).

Maranda, DIGEST-MD% doesn't need to store a plaintext password, though it does essentially mandate a plaintext equivalent. CRAM-MD5 has to store plaintext passwords, though, unless you do really shady things with partially computed HMACs.

If you search more informations: Do not lost this link: https://github.com/scram-xmpp/info/issues/1

dwd: I don't read the SCRAM RFC as if there was no way to work without -PLUS.

Do not forget the RFC 8600: https://tools.ietf.org/html/rfc8600 which has been published 2019-06-21 (soon one year): "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]". ✏

Is there someone in here with administrative powers on tigase.org ?

Guus: tigase@muc.tigase.org

Given that I want to discuss connectivity issues, that's not ideal. 🙂

I have informed you some days ago ;)

I have invited people here

Thanks

Neustradamus_: RFC 8600 is not relevant for most XMPP software (especially anything chat related). It merely "defines how to use XMPP for the exchange of security notifications on a controlled-access network among authorized entities"

Maybe but SCRAM part is important.

And it is logic.

But it's largely a profile of XMPP for a specific purpose - specifically, it doesn't update RFC 6120.

Guus: Andrzej from Tigase here

And if it had tried to, I would have shot that one down.

It also says servers MUST support at least SCRAM or EXTERNAL. Which obviously should not apply to all XMPP usecases.

larma: XMPP server softwares do it: - Prosody IM: https://modules.prosody.im/mod_auth_external.html - Metronome IM: https://github.com/maranda/metronome/blob/master/plugins/mod_auth_external.lua - ejabberd: https://github.com/processone/ejabberd/blob/master/src/ejabberd_auth_external.erl - Mongoose IM: https://github.com/esl/MongooseIM/tree/master/src/auth

Neustradamus_: that doesn't make RFC8600 relevant in this context

Nobody is saying implementing SCRAM-SHA-256/-512 is a bad idea. But that doesn't mean it necessarily has the priority you are suggesting everywhere.

I bet that if you do a pull request to any software that doesn't implement it yet, it would be accepted. But you can't blame developers for not giving it the priority you'd like.

larma: the point is have the good order from best to worst SCRAM and RFC 8600 (stpeter is an author): "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

It is not SCRAM-SHA-256 = SCRAM-SHA-1 or SCRAM-SHA-1 is preferred to SCRAM-SHA-256...

We can understand: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1

It is like DIGEST-MD5 > CRAM-MD5

Of course if the XMPP server supports, we can see in XMPP clients: - if only SCRAM-SHA-1 it is easy - if SCRAM-SHA-1-PLUS and SCRAM-SHA-1 // SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if only SCRAM-SHA-256 it is easy - if SCRAM-SHA-256-PLUS and SCRAM-SHA-256 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 - if SCRAM-SHA-256 and SCRAM-SHA-1 // SCRAM-SHA-256 > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-256, SCRAM-SHA-1-PLUS, SCRAM-SHA-1 // SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 - if SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS // SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS ✏

dwd: I didn't say it does, I said that "in Metronome it does"

Maranda, Ah, gotcha.

The only auth backend that does provide DIGEST-MD5 is the internal plain one

Neustradamus_, I think it's clear to everyone that IF both server and client support both SHA-1 and SHA-256, SHA-256 should be preferred. And that IF both server and client support -PLUS, -PLUS should be preferred. You apparently left out the small sidecase where SCRAM-SHA-1-PLUS and SCRAM-SHA-256 are supported, because it's not obvious what is to be preferred then (IMO it's -PLUS).

(agreed on -PLUS over SHA2)

However the default today is a) servers typically don't offer SHA-256 because the password is hashed with SHA-1 in database, making it impossible to offer SHA-256. There is no proper upgrade path from SHA-1 to SHA-256. b) clients don't offer SHA-256 because servers typically don't and it's not worth the effort to implement it for the very few cases where servers do. Because basically in all cases one can just fallback to PLAIN anyway without significant loss in security (if users follow best practices for passwords)

in my arrogant developer opinion, if implementing SHA-256 is hard after you have the SHA-1 variant implemented, you are in dire need of refactoring.

jonas’, that is indeed true 😉

but it needs to be tested, which is already hard enough given there are so few servers in practice supporting it 😉

I’m a believer in test-driven development, and if my SHA-1 implementation passes the test vectors, I’m confident enough that the SHA-256 variant will work flawlessly.

IMO there is also a design fail in how we login that I have to present the mechanisms *before* knowing the login name.

Was that tackled by sasl2?

larma, presenting the mechanisms afterwards would be a security problem

you could test user existence then

as if that wasn't possible already through various ways...

also servers could answer with fake mechanisms if user doesn't exist...

larma, the fake mechanisms would still look different than some user’s real mechanisms

and AFAIK user enumeration is a problem we generally avoid *by default* if possible.

server could send the mechanisms that are send to the largest amount of users on the server. Than it's still possible to detect some users, but not all.

yeah, and expensive to figure that out.

However the advantage is huge as that would allow an upgrade path for the hash algorithm

could do that with SASL2 already, though it requires offering *only* the old mechanism until all accounts have been upgraded.

even in that case you have to store both password hashes for the time until all accounts upgraded. If it was per user, you could just do it per user. You could even decide server-side based on the clients that connected previously if you want to upgrade a user or not.

yes, but that’s not feasible unless you want to allow user probing. ✏

which RFC 6120 and RFC 6121 go a long way to avoid.

nevermind that vcard-temp and possibly other things allow it if the user explicitly published some data

IMO, user enumeration is when I can get a list of users, not when I can try out every possible JID.

but the default is that you can’t enumerate accounts.

larma, that’s why I /correct’d my message.

right.

s/enumerate/probe/

well there are a ton of XEPs where you can probe users

but only after the users did sometihng to allow that

not even sure if it's not possible by RFC, but certainly by CS2020

PEP for example makes users probe-able

I’m aware of that

but it shouldn’t be the default.

(and it isn’t)

that you have PEP?

that you have a PEP node which is world-readable

you don't need that

you don’t?

even if it's not readable, you get different errors

that’s a bug then

either in the standard or in the implementations

also pubsub nodes MUST be disco-able

I’m fairly certain that you can always return <forbidden/> if you don’t want to let someone read nodes

jonas’, you could but it wouldn't be XEP-compliant. Also that doesn't solve the pubsub must be disco-able. If it wasn't you couldn't have world-readable PEP nodes.

larma, then the XEP needs to be fixed

but I’m sitll fairly certain that you can do that without having to fix the XEP

ah, maybe only returning the items you can actually see would suffice already

my point is: those are issues which can and need to be fixed

that they exist is no reason to open more issues.

but if a user doesn't exist it also doesn't have a pep service on it's jid

larma, servers could easily pretend that there is an empty pep service. ✏

I think it's just plain ignorant to claim that users are not probe-able and thus we should design protocols such that this remains true.

that’s a valid opinion. I disagree.

Do you think it's likely we'll ever reach the state where user probing is not possible?

yes

ok, so how would you like to do the upgrade then?

as I wrote above

you’ll have to wait for all accounts to be upgraded

typically that’s done with a deadline after which users have to use a password reset facility to regain access

or their account is deleted

It is possible to have SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS) enabled on an XMPP server but some users with only SCRAM-SHA-1 passwords (if originally not in PLAIN). If the user change of password, SCRAM-SHA-1 and SCRAM-SHA-256 will be here.

Users love changing passwords for random reasons.

Neustradamus_, upgrade only makes sense when we don't support SHA-1 afterwards (or at least that's when it really makes a difference)

Currently: Jackal XMPP server, Metronome IM, Mongoose IM master (soon a release), Prosody 0.12-dev, Tigase are already good.

We should just switch *TODAY*.

Flag day?

(kk I'll get coffee and quite trolling.)

quit

This will instantly make xmpp 256 times more secure

Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext

I'll get right to work hacking into every existing deployment and invalidating all credentials!

Zash, easy!

just publish mod_av which claims to enable A/V support immediately

larma, correct in the case of Prosody 0.12. Hashed credentials are stored in one or the other and can't be changed afterwards.

Zash, which means *proper* setups have no upgrade path to sha-256, which is exactly what I'd like to tackle somehow before we blame everyone for not implementing things that can't be upgraded on anyway

There's no upgrade path anyways

There could be, we just don't have one yet.

even if the upgrade only happens when you do your next password change, that's an upgrade path

or it happens when you next sign in with a device that does PLAIN

(which happens as soon as a client only supports PLAIN and SHA-256 and your server is still on SHA-1)

however the upgrade path requires a way for the server to signal that they currently don't have the sha256 hash and thus can't use SCRAM-SHA-256

and this should be per user.

which is indistinguishable from a downgrade attack, by the way.

this

a downgrade attack through an authenticated channel?

If I somehow steal your cert+privkey and get your clients to connect to me and I only offer PLAIN, I can steal their passwords.

only if they have the passwod in cleartext, which they shouldn't if your server supported scram

I was talking about a newly connecting client, and that would be fooled by such attack anyways

FTR, we do have: https://tools.ietf.org/html/rfc6120#section-6.5.9

also when I can get you to connect to me without -PLUS I can already steal all your messages from MAM which is probably worth way more than the password...

given that the initial data in SCRAM is enough to identify the user, servers could reply with mechanism-too-weak on a migrated account

not sure what to do with a non-migrated account though

Is there an "upgrade required"?

jonas’, but then I can probe users again

larma, yes

also mechanism-too-weak will probably fail on clients

can I swing my "arrogant developer hammer" again? ;)

assuming clients exist that only do plain and sha-1 and server supports plain,sha-1 and sha-256 in general, but for a specific account only plain+sha-256 (because account was upgraded), the client should try sha-1 and then would get <mechanism-too-weak/> which shouldn't be interpreted as "try plain instead"

= in this upgrade path a proper client would stop working for no good reason.

larma: if an XMPP client has only SCRAM-SHA-1 and server has PLAIN and SCRAM-SHA-256, it fails.

Note that an XMPP client can have in settings : force PLAIN password, ...

Screenshots: - https://i.ibb.co/RzgYTRS/psi-plus-allow-plaintext-authentication.png - https://i.ibb.co/n3vxnyT/psi-plus-encrypt-connection.png

Gajim via nbxmpp has SCRAM-SHA-256(-PLUS) and SCRAM-SHA-1(-PLUS) https://dev.gajim.org/gajim/python-nbxmpp/commit/f2a203387891455c052d44f8b1ceae711773cb81

lovetox: ^

Neustradamus_, I think you are missing the point here really. There is no client that does not support PLAIN. And it's unlikely there ever will be.

> Neustradamus_, they all store passwords in both sha1 and sha256? doubt that... They probably support sha1 and sha256 when password is stored in plaintext Why not that's what I exactly do larma ✏

Maranda: How it is done with Metronome and your XMPP server?

I just said that I generate server keys for each hashing algorythm I support for SCRAM

Maranda, but then you don't have the advantage of the more secure hashing algorithm to protect password from cracking (if password database is leaked). Because I can just attack the hash with the lowest security (sha-1)

which kind of is the point of using sha-256 over sha-1

And then most bussness infrastructures out there do still have the requirement to have at least reversible encrypted passwords, so the whole argument is kind of "a good purpose" one but again all it matters is safety and trust of the who deals with 'em.

Could someone find a cryptomath wizard and ask them to calculate the ratio of securityness between sha-256 and sha-1

... and then we just increase the minimum iteration count by that ratio!!!

bam, sha1 forever

.... that's not how this works...

larma: i'd ditch all other mechanisms for scram-sha-512-plus already just get all clients to support that and channel binding and we have a deal

Maranda, sounds like a great plan, except it doesn't work because legacy clients will always be around.

larma: oh really? 😘

😉

(and scram-sha-512-plus is undefined and doesn't exist)

can we do scram-argon2d-plus please?

sure

*Argon2id

The SCRAM construct doesn't depend that much on PBKDF2 ✏

any ƒ(password, salt, iterations) → blob would do in theory

Gets weird if it takes other parameters than those tho

well, it already does that

SCRAM-SHA-256 has ƒ(password, salt, iterations) = sha2(32, password, salt, iterations)

You mean PBKDF2(hmac-sha-256, ..., output size)

Hi() is a special case of PBKDF2 with some predefined parameters

whatever 😉 sha-256 already is sha-2 + 32 byte. So any SCRAM-ARGON-X could do the same

but probably not gonna happen soonish anyway 🙁

probably never

Not with that attitude :P

would be too good if we weren't discussing upgrading to something that's already outdated...

SHA-2 isn't outdated?

there is SHA-3, so by definition SHA-2 is outdated

SHA-2 isn't broken yet afaik

yeah, wasn't saying broken

sha-1 also isn't broken for our usage

I thought the point of picking a SHA-3 was to have something in case the very foundational concepts that SHA-2 (and SHA-1) are built on were broken, and that's not happen yet

Yeah, so why the push to SHA-2?

We gain nothing but pain atm

It's not me who is pushing 😉

I am just pushing for an upgrade path, so we can handle it should it become necessary

plan the upgrade now so it can happen in 10 years or so

don't do another 12-byte IV 😀

Invent a better SCRAM, one that can tell the client in a secure manner "yo, you gonna need to reset your password for security upgrade reasons"

Zash, you can do that with SASL2 after successfully authenticating with SCRAM first

Sure

SCRAM SHA-3 is planned yes

And SCRAM Argon2id?

It's tricky since you don't know at the time when you're offering mechanisms whether the user supports them.

we’ve been at this point two hours ago

:)

And weeks/months ago.

maybe we should have clients propose mechanism to the server not the other way round

I'm just copying from a script actually :P

larma, and then what? you can still probe by looking at the mechanisms accepted for $randomUUID vs. $guessedUsername

it adds complexity to the attack

not much though

Oh heaven so this is about brute forcing SCRAM?

maybe we need a stateful authentication protocol and abandon passwords after first login

Maranda, no

larma, like the thing dave wrote?

And/or possibility of

also, I’m all for it

Maranda, no

jonas’: better

jonas’, not sure about the exact protocol, but yeah something that gives you a per-client token that can be stored by the client and also can be revoked if necessary.

OAuth?

Alternatively we could only announce PLAIN in mechanisms, than get told the mechanisms supported by server *after* succesful login and be able to use SCRAM-* on later logins, ignoring that only PLAIN is announced.

What was that combined auth and stream resumption token spec called?

larma, haha

Zash, 397?

That's the one

https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00 that’s the one I meant

E_TOO_MANY_PROTOCOLS

Bring back https://xmpp.org/extensions/xep-0078.html !!!!11! /s

Zash, IIRC in OAuth the client has to register a-priori with the service to receive the client-key, no?

It Depends!

which is also why OAuth for email got no traction. email clients only support Google and Microsoft for OAuth

If you use deprecated parts of OAuth you can get a token using a password.

Ah, right. But that's not how it's supposed to be.

Because you can't make use of service specific login pages that do 2fa and alike then.

If you're going to use OAuth "as it's supposed to be" then you can't have nice things, only browser and web services.

well non-browser clients can open a web browser to authenticate than callback to the client

that's how thunderbird does googlemail

from another part of my script, I say "if I have to open a browser then I hate it"

that's ok, you can still do PLAIN

with a single-use password you somehow retrieved from your service

(probably using a browser)

XEP-0397 is CLIENTKEY, but the SASL bits live in the I-D. The other thing you could do is XEP-0257 (or similar).

dwd, xep-0397 doesn't have the counter part built-in. And it's also not asking for TOTP (which probably shouldn't have been in clientkey anyway)

Oh, wait. Wrong XEP.

oh, and xep-0397 also doesn't have expiry

XEP-0399.

I kind of wonder why all the TOTP is part of those XEPs

seems kind of arbitrary to put it in there, as it could be completely ignored

I see it makes things easier if TOTP is required, but it also works and makes sense without TOTP

but in general, I'd rather see 399 being pushed than SCRAM-SHA-256

For '399? That was the driving factor for Surevine, as it happens.

I mean TOTP is obviously non-normative in '399, so I am fine with that, but I'd probably want to get rid of that before moving it to draft.

So we had a requirement from the market for second-factor, based on TOTP. So we had SASL2+TOTP (in Openfire, code public), but it was a browser-based client, so we needed to avoid forcing the user to re-enter TOTP every time they refreshed, hence '399.

Also CLIENT-KEY and CLIENT-KEY-PLUS would need to be IANA registered first, right?

The '399 code is also public, but it's an earlier design.

dwd, yeah I guessed that TOTP was the driving force here 😉

larma, Sorta. Eventually. But they're in I-D form now.

larma, But I wouldn't remove 2FA entirely from '399 - while CLIENTKEY isn't dependent on it, it feels important that a client shouldn't ordinarily get a TOTP challenge when using CLIENTKEY, since the client installation has become the second factor, sort of.

Yes, I am fine with mentioning that, basically the 4th sentence in §2.

Also probably the other way round, mention it in 400, no?

*mention '399 in '400