jdev - 2021-02-12

hey question regarding SASL fallbacks

i have a server that offers GSSAPI and PLAIN

GSSAPI login seems broken for the user

right now i have no fallback behavior for any SASL methods

out of fear of downgrade attacks

i wonder how other clients handle this

lovetox: I implemented the fallback in Conversations. It ranks the mechanisms based on some percieved "level of security". You can always log in with anything higher than a login method you've used before, but if the server stops offering it and you only see lower mechanisms log in fails and it's up to you to decide what to do (contact the server admin, wait and see if it resolves itself, allow the less secure mechanism, etc.

In this scenario if GSSAPI is considered "more secure" (for some handwavey definition of "more secure") than PLAIN, if login had succeeded with it once the user wouldn't be able to log in and would have to decide to reset the pinned mechanisms. If they had never been able to log in with it plain would be used happily and if GSSAPI started working one day they'd be silently upgraded.

I wrote this up in more detail in https://xmpp.org/extensions/xep-0438.html#pinning

(or in https://www.ietf.org/archive/id/draft-ietf-kitten-password-storage-02.html#name-mechanism-pinning which is more or less the same thing)

ok sounds like a lot of work ...

Not really, it was a couple of lines of code, but maybe I'm explaining it badly

my library doesnt even offer fallback yet

it simply aborts on the first failure

so i would need to start with that

and then i need in the client the mechanism recording

and the UI to reset it

The whole thing is sort of unrelated to fallback actually, the fallback part is just "try the mechanisms in order from highest to lowest". The pinning can actually be done even if there is no fallback

Conversations doesn't actually have a UI to reset it, which may or may not be a problem

But yah, if you don't have fallback at all yet the docs I linked recommend some fallback orderings (but don't include GSSAPI, sorry)

actually im of the opinion that no fallback is needed

its just that i forgot about GSSAPI

because its not in client hand if it works, it needs some additional setup on the machine

yah, I tend to agree

i dont see why i should fallback between scram methods

if the server offers a method that simply does not work, i tend to think admin should get informed by user reports right away

and not we fall silently back and problem is not discovered for eternety

same story with direct and start tls

I was thinking more "if the client offers SCRAM-SHA-1 and SCRAM-SHA-256, which should it use?" but if you mean "auth failed" I agree, fallback isn't necessary

there are servers out there that simply have not working connection methods, and never know it because all clients fall back to something else

(or rather, I thought you meant fallback in that way, trying another if something fails, but I agree it's probably not something I'd do personally if that's not what you meant)

(and that's why adding some fallback for websockets is bad!)

Sam Whited, i think we mean the same

if i try SHA-256 and get back ANY error

lovetox: yes, sorry, I was confused about what you meant at first but I agree with you that fallback is not necessary, if you get an error, report it :)

it does not matter which, i would not fallback

Which one you select first and which one you select if the server list changes is the important thing to think about.

i have a orderd list of prefered methods in the client right now

but i dont pin them

so i dont record what the server offers right now one day and the next

i agree now that i think just about pinning and not about fallback

its probably trivial to implement

At least in my implementation I don't record the server list either, I only store what the last successful login used (well, I store the priority, not the exact mechanism) and then compare to whatever we selected this time

So it's more or less a single if statement before every login and storing a value in the database after a successful login :)

yeah i agree thats trivial

though its also really ... edge edge edge case

i mean thats really paranoid

i think

Yah, the idea is to protect against a server compromise and someone downgrading you to plain to steal your password (which you have unwisely re-used for your email and bank accounts), but it's probably not a super high priority issue to patch or anything

anyone knows a public server with some transport where i can test the register flow

lovetox, jix.im and jabber.linuxlovers.at have a few transports available

thanks