XSF Discussion - 2018-09-24

what would be the best approach to implement "carbons", but for the transport contacts? 🤔 (so the message sent directly through the legacy network can show up in the xmpp conversation)

dos: write a new XEP where the transport is allowed to send carbons to a user

dos: there was a thread at https://mail.jabber.org/pipermail/standards/2018-January/034224.html

f'up at https://mail.jabber.org/pipermail/standards/2018-February/034267.html

I implemented a, uh, client side transport that way

Kind of, it's a dumb echo component so carbons and mam and such just work for free

dos, https://xmpp.org/extensions/xep-0356.html might be interesting in that regard

dos: what kind of transport are you implementing? Will it be publicly available/libre ?

hm any client doing scram-sha256?

Maranda: Conversations does, also my dummy test client https://github.com/mellium/communique-tui

SamWhited, ok giving it a go then, the code *should* already work with it, I just need to change the hash algorithm function. ✏

(and store sha256 keys)

SamWhited, what Conversations does if one mechanism fails?

does it try another?

Maranda: sort of; it falls back but it's also more complicated than that. If it manages to connect successfully the first time it "pins" the auth mechanism used and will only use one with that or a higher level of security in the future to prevent downgrade attacks

So if it uses SCRAM-SHA-1 once it will use SCRAM-SHA-256 if support is added, but if that works and it logs in it won't use SCRAM-SHA-1 anymore.

Problem: How do you upgrade the hashes?

SamWhited, because obviously users will have to change their password to add SHA256 keys

Zash, you don't

Zash, I just save keys for both hashing algorithm figured it was much easier that way

Zash: do a rolling upgrade when users change passwords?

Indeed

I don't know what's conventional for servers

SamWhited, but you'll have to save keys for both SHA1 and SHA256

Maranda: if you want to support both, yes. Otherwise you can just advertise whichever you have keys for for that particular user.

You don't know which user it is until they try to auth

But yah, given that sha-256 isn't wide spread I'd probably keep both

SamWhited, huhu I'd not try with the "not supporting both"

They have to pick a mechanism first

Zash: oh yah, good point, setting "from" isn't required on streams.

Storing both for now is probably easy enough though

For now code just checks if there're keys for one algorithm if not it'll throw a temporary-auth-failure error.

that's why I asked what Conversations does :P

SamWhited, what's that tester code you mentioned again?

(for SCRAM)

Maranda: https://github.com/mellium/sasl/blob/master/client_test.go

That reminds me, I still really need to implement the server side of scram in that sasl library

SamWhited, I'm getting some shenanigan with BinaryXOR being performed on ClientSignature and Proof in final message.

le sigh.

So uh, isn't storing sha1 hash of password server side just as bad as plaintext?

And basically same deal with sha256 ?

Seems likely plain auth would be better so you could store it with scrypt or bcrypt?

moparisthebest: it's not a sha1 hash, sha1 is just used for data integrity in an hmac

So what's the talk about how it's stored?

PBKDF2

A lot of servers store an intermediate step in the SCRAM process or some other hash.

moparisthebest, https://stackoverflow.com/questions/4938906/is-sha1-still-secure-for-use-as-hash-function-in-pbkdf2

To verify bcrypt or scrypt as is, you need the plain text password. SCRAM doesn't require that

I have to read up on SCRAM

You do

It's not comparable with bcrypt. It uses PBKDF2 which does that kind of job, but then there is XOR magic.

moparisthebest: TL;DR when you want to upgrade, for example, a web apps password from bcrypt and salted to something else, say PBKDF2 or argon2, you wait for the user to log in, then you hash the password with bcrypt, compare to make sure it's the right one, then hash it with the new thing and save the new hash. However, with SCRAM you never actually send the password, you send a verifiable proof that you possess the password, but there's no way to upgrade that proof to a proof for a different scheme.

SCRAM is a pretty amazing thing

SamWhited, unless you force the user to change passwords

or downgrade to PLAIN only, which is what I did. (and which Conversations didn’t let me do painlessly)

(which is a good thing imo)

Right, we don't currently have a good way to force upgrades.

It could be done because SCRAM performs mutual authentication, so once the server is authenticated to the client it could send a "please send your password in plain and upgrade to SCRAM-SHA-256" message, but we don't have a way to do that currently.

IBR doesn't even do SCRAM, which is something I wanted to tackle, but I'll pass the baton to whomever says a word about it :P

pep. feel free to provide feedback or implementations of https://xmpp.org/extensions/xep-0389.html

oh

It needs a lot more work, but part of the idea was to let IBR use regular SASL mechanisms

Thanks, I completely missed it

SamWhited, seems like a thing which SASL2 could do

(the upgrade thing)

yah, it's probably something we should think about.

Although, it could probably be backwards compatible by just defining a message the server can send to the client at any time that tells it "clear any pinned auth mechanisms" then the server could force a reconnect and only offer PLAIN the next time.

That kind of defeats the point of doing SCRAM no?

pep. no, because it would only happen after you've authed the server

What do you mean

You know you're talking to the correct server, so starting over and using something it can generate hashes from is fine

But the point of SCRAM for me is that the server doesn't know about your plaintext password. So if you do PLAIN ~

jonas’: thanks, haven't though about 356 for that :)

pep. I suppose that's fair

It seems much better to have a way to flexibly and rapidly upgrade auth mechanisms when an attack is discovered than to worry about a server secretly storing your password when it probably got it at some point when you registered anyways

It could also just be a "clear your SCRAM-bits cache and don't start from the intermediate step" message too though, I suppose.

You still need to use some protocol to set your password right with SCRAM, does that exist in 389? I haven't read through. TBH I don't mind doing PLAIN with clients that don't support, they should update, that's not my fault. But if possible I want to keep the assumptions the user has with me

goffi: so far I'm just looking at improving spectrum2; my goal is to have proper facebook, hangouts, discord and maybe matrix bridging for use by me and my friends

pep. no, 0398 just provides a way for you to define challenges. It was my intention to define a SASL one.

ok

But it does add the ability for us to do that

Actually, that one should probably just be one of the mandatory ones that's included in 0398 itself. Right now there's just one for submitting a form like in regular IBR

https://pastebin.com/s4usVWMZ

meh pep. I mean you use a different password with each service anyway, why does it matter if your server has it?

also lets me support same password for xmpp, email, and http auth easily, and with a strong hash on the server

moparisthebest, you do, yes

I am sure 90% of a public service like jabberfr.org doesn't

my question is, is whatever 'part of scram whatever' that your server stores hard to reverse or not?

I also do fwiw. It's not me I'm worried about

You have to trust the server for the most part anyways, that's part of XMPP's security model and you almost certainly had to send the server your password somehow when you first signed up, so it could have saved it then if it really wanted to

So if you're going to worry about other people reusing passwords and the server saving a plain copy of it, you have a lot more work to do.

SamWhited, yeah, which is why I also want SCRAM/IBR

step by step

Doesn't seem worth bothering with to me; just send the server your password on occasion. It's not significantly worse from a security standpoint, and might even be significantly better since it allows for more agile password hashing schemes in the event that the one you're using is discovered to be flawed.

But I dunno, I'm just thinking out loud. Maybe there's an easy way to make SCRAM upgrade-able too.

I wouldn't mind a force password reset fwiw

I guess we do all that to protect against offline attacks. So when for some reason we want to change hashes, we also don't want to keep $old_hash around, otherwise that defeats the point of why we keep hashes in the first place, which makes us lose the ability to authenticate users at all and certainly require another channel :/

moparisthebest: The stuff that SCRAM lets you store is hard to reverse, yes.

but compared to bcrypt/scrypt/?

like have cryptographers agreed it is *as* hard to reverse as those

moparisthebest: It uses a password stretching function called Password Based Key Derivation Function no 2

I'd put it in the same class of things as bcrypt and scrypt

I wouldn't consider that part all that important, I'm pretty sure you could switch it out for bcrypt/script/whatever and have the overall SCRAM construct still work

Thing is, those password stretching functions take a password and some salt and give you a key. SCRAM magic consists of adding two-three layers of hashes on that and some XOR in a way that lets you store the password *everywhere*

Ie Client can store hashed stuff. Server can store hashed stuff.

Hashed stuff on the wire.

SamWhited, I'm not sure what's wrong here... apparently bxor is broken by some additional x byte in the proof.

it just sounds very complicated, normally you don't want very complicated in your security proofs

moparisthebest: It's not all that complicated

it's 21 iterations instead of 20, the 21th is truncated and breaks XOR

moparisthebest: Not sure if you need to understand how it works to understand this description: https://prosody.im/pastebin/6f7b2c8b-8952-458b-a1d2-36d29bacd345

moparisthebest: PBKDF2 is still considered secure, yes. I beleive OWASP recommends it over scrypt and it's usable if you're looking for FIPS compliance

yea just wasn't sure if PBKDF2 was what was stored or not

Its weakness is that it can be implemented with very little RAM, scrypt does a better job there

Yah, you can store the salted password after passing it through PBKDF2 or you can take an hmac of the salted password and a server or client KEY and store that (the "scram bits"). This is what I always store (for no particular reason other than it's one less thing to do later)

"StoredKey" is H(HMAC(PBKDF2(password, salt, i), "Client Key"))

ah yah, forgot you re-hash it too

moparisthebest: https://tools.ietf.org/html/rfc5802#section-3

OWASP recommendations, FWIW: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Hmm, I haven't looked at my SASL implementation in a while, this reminds me that I also need to add some mechanism for caching keys or resuming a calculation so that the user can build a mechanism for caching keys

That's going to be a pain to come up with a good API for

SamWhited, moparisthebest, fwiw I'd prefer to avoid passwords at all and use client certs I generate. That can leak I don't actually care.

how do you sign in with a new client then?

if you say password I'm going to ask what the point is :)

I'd like something like that where when you sign in with a new client it shows a pop-up on your old client and if you hit yes, you're signed in.

yeah, I was going to say something similar

Not that I have really researched on the subject

It's hard to get a good UX that way (see OMEMO which is a pain in the ass to use), but I do think it can be done with a lot of work.

Also you still need another channel for recovery

We should probably get a basic password flow working reasonably well first though.

Yah, recovery is more or less the same no matter what you have. If you want to be able to recover, you need some other channel. Email or what have you.

What if you have some kind of shared secret that you can remember in your brain?

Somebody said passwords?

(IBR2 also supports recovery specifically, FWIW)

This I really like in 389: A client SHOULD be able to register an account without requiring the user to leave the client. A client MUST be able to use the same mechanism to register an account and to recover a forgotten password (subject to server policy).

Is there a ordering of XEPs that is not by number btw?

By category, by..

Ah there's the page on xmpp.org to filter a bit

That SHOULD should probably be relaxed actually; that really heavily depends on the type of service and probably shouldn't be 2119 language.

meh, I think that's the most important part for easy-onboarding

Yah, but only if you're doing a purely-XMPP personal server. Specs shouldn't be tailored to those.

right

purely-XMPP-public-Jabber-network, that is.

But then you have to make everything optional in specifications if you want to support every use case

I don't want to support every use case, I just don't want to put stupid hard limits in that serve no purpose that everyone will just ignore anyways

The recommendation is good, but RFC 2119 language isn't really suitable here

In other words: we can have a design considerations section, but it shouldn't be normative.

I was saying that more as a general rule, as in, "it's indentally what happens the more use-case you want to support"

I agree with that, but that's not what's happening here

k

Even if the spec were deliberately an XMPP-only/public jabber spec for some reason, design considerations that are only tangentially related to the spec probably shouldn't be normative 2119 language

(I'm not suggesting that entire line should be removed, in case I'm not being clear: just that it should say "should" instead of "SHOULD")

I don't think 2119 mandates CAPS does it

pep. it does (or at least, an update does, I forget exactly where it says that)

"These words are often capitalized"

So, no

8174

oh

I'm saying 2119 out of habit

hah, I see

Just for this exact use case :P

But yah, however it's done I just mean that the language in that sentence should not be normative. I assume lowercase does that, but maybe it would just need to be rephrased.

My preference as a spec author is to use MUST, SHOULD, MAY etc. only in caps, and to use other words (ought, might, can, etc.) if the normative force is not intended.

Agreed; that's probably a good thing to do to reduce confusion.

Precisely.

Signature 32 bytes, Proof 20 bytes

>.>

SamWhited, that doesn't look right

(what Conversations does)

I'm not at my desk right now but I did test it against a server impl, it's quite possible something is still wrong though (I'm assuming that's in the scram-sha256 code somewhere?)