username == localpart is recommended and the most common I imagine, outside some rare special deployments
Zash
Hm, there are some authentication backends for Prosody that use the database of some web forum software, which allows usernames that aren't valid JID nodeparts, so there's some mangling going on there.
strarhas joined
lovetox
funny IBR does not even return the jid registered
kikuchiyohas left
lovetox
so the server could register another localpart and tell me while binding
Zash
And the email ecosystem often use the entire email address as username, which makes it a massive pain to use
Zash
Does IBR2 fix that?
Zash
Hm, https://xmpp.org/extensions/xep-0389.html looks kinda unspecified in that area
Danielhas left
lovetox
this also fails at almost any xmpp client
lovetox
almost any client specifices a jid and pass field
Zash
Sure
lovetox
obviously the client can never guess the username from the jid if its not the localpart
Zash
True
Danielhas joined
lovetox
so it would need to be a username field
pulkomandyhas left
lovetox
and a second field specifing the server
lovetox
in a walled garden the second field would not be needed
lovetox
funny that gajim has exactly that UI right now
lovetox
which most people feel is a pain
Zash
Can you type user@host as username?
lovetox
no, because Gajim puts both username and server together afterwards and it would yield an invalid jid
Zash
It's probably okay to not support username ≠ localpart deployments, or hide away the connection details for that in some advanced settings section
Zash
Gajim Enterprise Edition? 😀
lovetox
what really hurts is that the jid is our main key for everything account related
kikuchiyohas joined
lovetox
and with anonymous this changes on every connect
lovetox
maybe i just make the domain the key for anon accs
lovetox
and just allow one anon acc per domain in Gajim
bhaveshsguptahas left
pulkomandyhas joined
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
debaclehas left
asterixhas left
asterixhas joined
Danielhas left
pulkomandyhas left
Danielhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
kikuchiyohas left
bhaveshsguptahas joined
sonnyhas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
kikuchiyohas joined
sonnyhas left
bhaveshsguptahas left
pulkomandyhas left
asterixhas left
asterixhas joined
pulkomandyhas joined
kikuchiyohas left
lovetox
we dont have any XEP for password resets or?
kikuchiyohas joined
lovetox
we should really get IBR2 going
rionhas left
Zash
Everything2 😀
pep.
0389?
pep.
Or a new one?
Zash
XMPP2
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
lovetox
yes 0389
lovetox
though actually 0389 is missing the mutli stage functionality
Zash
lovetox, can I interest you in poking Sam or possibly taking over as author? 🙂
lovetox
ah i see its a little sentence at the end
lovetox
the server MAY send another challenge.
Zash
> If the client successfully completes the challenge, the server MAY return an empty <success/> element qualified by the 'urn:xmpp:register:0' namespace,
MAY? What else would it do?
lovetox
yeah it seems a bit weird, it seems like this is a XEP that is reused by other XEPs
Zash
SASL2, IBR2 and .. BIND2?
lovetox
and it lacks examples
lovetox
and Zash now i know why IBR uses IQ before bind
lovetox
because all libs support callbacks on IQ responses, which you dont have with nonzas
Zash
Hack 🙁
lovetox
so implementing the whole process with nonzas is a bit harder
Zash
But they need to for SASL
lovetox
at least it would be nice to have ids on these nonzas
lovetox
so we can add callbacks for these in the future
Zash
I don't see the point. Pre-resource binding shouldn't have more than one thing anyways.
Zash
There should be no async or out of order events.
asterixhas left
asterixhas joined
rionhas joined
Zash
The point of id attrs are that you can send many requests and the answers can come back in any order.
lovetox
hm true
lovetox
but the same thing must work in a after-bind situation also
lovetox
hm or does it
lovetox
ah yes, for the change-password flow
lovetox
though this is maybe excluded here
lovetox
and should rightfully excluded out of IBR
lovetox
as it mixes, pre-bind and after-bind use cases
Zash
agree
Zash
Hm
lovetox
change password should be just a adhoc flow
lovetox
there is no need to invent something new here
lovetox
adhoc has everything you would ever need for a change password flow
Zash
You might need some way to signal that a password change is mandatory tho
lovetox
adds too much complexity in my opinion
Zash
Like, right after password recovery
lovetox
just send a email out to your users
lovetox
or a xmpp message with a weblink
lovetox
but if you would do this
lovetox
this would also be a pre-bind deal for me
lovetox
right after auth
lovetox
present a must change password flow
Zashwas just looking for that in https://xmpp.org/extensions/xep-0388.html
pulkomandyhas left
lovetox
yeah its under 2.6.3
lovetox
so yes SASL2 would support that
Zash
Hm
lovetox
ok so we have multistage pre-bind ibr with ibr2
Zash
If password change can be either required or optional, then an user-initiated password change could be done by logging out and logging in+changing password
lovetox
we have pre-bind password changes with sasl2
lovetox
leaves a simple xep that has after-bind password changes via adhoc
Zash
I wonder if that makes things easier for servers, as you rather want to kill/reset other sessions when the password is changed.
asterixhas left
asterixhas joined
pulkomandyhas joined
lovetox
problem is migration
lovetox
i was just thinking about 2FA
lovetox
but servers could offer both SASL as long as no 2FA is set
lovetox
and afterwards only SASL2
Zash
Sure
lovetox
ah no
lovetox
the server does not know the account before SASL :D
lovetox
so it cant just leave SASL2 out
Zash
Hm
lovetox
so you can always make a downgrade attack
lovetox
except for server who only support SASL2, which makes migration a pain
Zash
Hm, like the problem of upgrading stored hashes to SCRAM-SHA-256 or so
Zash
So you can't enable 2FA until everyone supports SASL2
Zash
or someting
Zash
I started on a SASL2 impl but I don't think it's complete
Zash
Would be good to have a client to test with tho
kikuchiyohas left
lovetox
its not an attack i misspoke
lovetox
after enabling 2FA server has to fail the SASL1 flow obviously
lovetox
so no its not that big of a problem i guess
lovetox
users just have to be warnded if they activate 2FA they can only connect with clients that support 2FA
lovetox
obvious
Zash
But it affects everyone on the server
Zash
Or does it?
lovetox
no, 2FA can be set per account i guess
lovetox
could be a simple option in the register flow
Zash
So SASL1 would succeed for those
lovetox
yes
Zash
.. .that hasn't enabledit
Zash
I suppose you can make it so that the server doesn't let you enable 2FA from a client that used SASL1
Alexhas left
Alexhas joined
Zash
Then they can't lock themselves out as easily, and there's some incentive to upgrade
lovetox
how would you activate 2FA
Zash
Dunno
lovetox
only via IBR2
lovetox
so that must be a client that does support IBR2 but not sasl2
lovetox
in normal ibr there is no multistage
lovetox
which you need for any 2fa setup
Zash
Not being able to upgrade an existing account to 2FA seems like meh tho?
lovetox
yeah i guess there needs to be a own xep for that
Zash
You'd want to do that in connection to password change or something
Zash
XEPlosion!
Zash
😀
lovetox
2FA upgrade can be done again via adhoc
lovetox
no need to invent something there
lovetox
great
lovetox
SASL2 offer a stream feature of <mechanisms/>, qualified by the "urn:xmpp:sasl:1" namespace
lovetox
fits
Zash
heh
Zash
Well if you come up with a reason to bump the namespace, and then never again...
Zash
or it could be ...:sasl2:1
pulkomandyhas left
pulkomandyhas joined
lovetox
hm theoretically it should be easy to implement SASL2 in nbxmpp