XSF Discussion - 2020-12-14

hello

anyone there?

@SCAM: FOSDEM call for stands is open, though hopefully nobody is actually relying on me to know that :)

hmm, online stands?

Yes, online stands

I think it would be good to issue (as early as possible) a call for content from projects

People may need time to prepare

How does an online stand even work?

Video chat with slides and the website shared?

Is there any "reset password" standard?

I was thinking of this: the user asks for "reset password", the server looks for emails in the VCard, and we send the "link", say via HTTP, OR a new password, to their specified email.

I'm not aware of a standard for that, no. Also using the vCard is unwise because it's typically not verified (so a typo could grant someone else access to the account, etc.)

would be nice to have a standard way of reaching the user as a service or admin though

Also I may not want to publish an email but still have one registered, or I may want to use a different email for my account but publish a different public email address

We often have to correlate the little data we have when we get a "lost password" request

For Prosody I'm planning to work on verified email (and possibly phone number) support, which would help a lot with that

:-O

It's not widely supported, but XEP-0389 handles password reset

Ah yes

So the future is hopeful :)

SamWhited: by asking for an email during EIBR?

MattJ, that would be nice, I run a mix of prosody and ejabberd, but the main jabber.am server is still prosody, and would love to see that.

Sure, that would be one way

You could also do it after registration. Eventually maybe define a URI to open the client and continue the reset process

In some scenarios it might make sense to tie the account registration to SMS verification anyway.

(eIBR can also do that; really this is the use case I had in mind when I designed it :) )

how do you get the URI after you lost your password?

Daniel: how is quicksy going btw?

Terribly

Ge0rG: eIBR works before login, so somewhere in your client you'd pick "I forgot my password" or something and it would just select the eIBR feature instead of the normal auth feature

SamWhited: ah well, doing oob authentication during password reset is probably not the challenging part ;)

I was looking into how to make the users define the oob channel in advance in a sensible way

Ge0rG: I guess I'm not sure what you mean? What is "define the oob channel?"

SamWhited: a user needs to give an email address / phone number / avian carrier coordinates at some time, and the server needs to verify that

it shouldn't be mandatory though

Ge0rG: if you're using eIBR you could use the dataform challenge and just ask for that stuff, or you could define your own more specific challenge if dataforms aren't desired

Ge0rG: I think you need to transport the actual carrier, not the coordinates

Like Mail it in or something

Ad-hoc command?

SamWhited: well, passing an email during IBR has been a thing for seventeen years now

I'm not sure if any server implementation will actually verify that email address

Prosody doesn't, currently

Sure, how the server actually implements things is up to them

Daniel: good point. I'm not sure if that's in scope for eIBR though

intergrated IM solutions can do nifty things like https://developers.google.com/identity/sms-retriever/overview

We did a password reset system for a failed product at Surevine. Built around two SASL mechanisms, one for the "I forgot my password" bit, and a one-time reset code one to handle the "Click here to reset your password" link.

Ge0rG: Metronome does, and also verify that the address is not a disposable one....

Maranda, how do you verify that it’s not disposable? :)

I pass the domain name to an external REST API which does that

If it's catched as DEA it will invalid the registration

> an external REST API That's how the internet works, right?

Ge0rG: if you want you can implement your own thing, and collect the data required... Tbh I found it more convenient to let someone else do the latter, and since.. Yes most ppl use a REST API.

😺

Maranda: not criticizing you, I understand the trade-offs

Oh non, those APIs are the bane of my existence since I use spamgourmet

... Had to lookup the DB I use in the code because it's years I don't touch it. Anyways it's https://www.nameapi.org/

If you are going to do it that's probably a fine way, but... Why prohibit disposable emails at all

moparisthebest, because that’s what spammers use

moparisthebest: they're used by spammers to circumvent verification

Spammers set up their own domains no problem

Spammers generally don't like to set up their own domains because other providers use domain reputation and if you setup a new domain you don't have a positive reputation to help you land in peoples inboxes even though the contents of your message looked kind of spammy.

You're right, it should be a simple whitelist of gmail.com, outlook.com, yahoo.com

moparisthebest: once they become detected and listed, nameapi will block those as well

They do several checks

Not just DEA

It served me well enough over the years

MattJ, make sure to whitelist their MX'es so everyone with custom domains aren't blocked!

this is probably bad, I know SamWhited does Go XMPP stuff, anyone else? https://mattermost.com/blog/coordinated-disclosure-go-xml-vulnerabilities/

moparisthebest: oh my

I'm not absolutely positive whether this is a deal breaker for XMPP or not , looks like attribute/element ordering isn't preserved

it is "unfixable" at the moment so they just dropped it

I'm not sure it's a security vulnerability, but it's definitely not irrelevant, e.g. data forms.

Also Atom over pubsub, I guess.

this is old but I just saw it today too, a case of bad XML comment parsing causing a major security bug in iOS https://siguza.github.io/psychicpaper/ / https://twitter.com/s1guza/status/1255641164885131268

https://i.imgflip.com/4qcxj6.jpg