search

monal-im / Monal

Monal for XMPP (iOS and macOS)
https://monal-im.org
Other
504 stars 104 forks source link

iOS: QR code account setup (XEP-379, XEP-401, XEP-445) #172

Closed thenktor closed 8 months ago

thenktor commented 5 years ago

Hi,

to simplify account setup on iOS devices it could be done by QR code:

  1. Create a text QR code with jabber ID on first line and password on second line, e.g. here: https://www.nayuki.io/page/qr-code-generator-library 
    myuser@myserver.org
mystrongpasswordwithsymbols#&7%§!/()429XX
  2. Scan generated code on iOS device quick setup.

Code generator could be added to monal.im website.

anurodhp commented 5 years ago

I'm planning on a lot of QR code stuff actually, its something I will do in 2019. QR codes for account setup, contact exchange and key exchange.

dholl commented 5 years ago

And perhaps could the same QR functionality could be offered on the macOS version as well? :) (Our laptops have cameras built-in... so a friend could hold their phone up to your laptop's camera to exchange a QR code as well...)

Thank you!

Echolon commented 3 years ago

https://github.com/anurodhp/Monal/pull/516/commits/8efa7662b7c5b7c12599ffa5f966e55caea80ebf

https://github.com/anurodhp/Monal/pull/516/commits/13e84a6b5481f330c75963a951ecadcc825edefd

https://github.com/anurodhp/Monal/pull/516/commits/b99be271877dc9d7f92de32e7df4daa3e9cb345a

ge0rg commented 3 years ago

Sorry I'm late for this game, but please, pretty please don't do it this way. Showing the account password in a QR code is a security nightmare.

We have designed a very nice and useful token-based on-boarding mechanism for new accounts that's slowly getting integrated into different implementations, see here:

You should implement the following URI schemes for registration on the receiving end:

Echolon commented 3 years ago

127

tmolitor-stud-tu commented 3 years ago

we will do this later, don't worry :)

Am Donnerstag, 3. Dezember 2020, 10:27:32 CET schrieb Georg Lukas:

Sorry I'm late for this game, but please, pretty please don't do it this way. Showing the account password in a QR code is a security nightmare.

We have designed a very nice and useful token-based on-boarding mechanism for new accounts that's slowly getting integrated into different implementations, see here:

You should implement the following URI schemes for registration on the receiving end:

  • xmpp:example.com?register;preauth=3c7efeafc1bb10d034 - register a new account on example.com using XEP-0445, with a user-defined account name xmpp:romeo@example.com?register;preauth=3c7efeafc1bb10d034 - register as romeo@example.com using XEP-0445 xmpp:contact@example.com?roster;preauth=3c7efeafc1bb10d034;ibr=y - if no account is registered, register a new account on example.com using XEP-0445, with a user-defined account name, then automatically add contact@example.com to the contact list
mimi89999 commented 3 years ago

Conversations also added this, but they are using a JSON object for that: https://github.com/iNPUTmice/Conversations/issues/3796

I'm still against this feature.

licaon-kter commented 3 years ago

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

mimi89999 commented 3 years ago

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

@licaon-kter Add account with password in QR code also called provisioning. It was also implemented in Monal in https://github.com/monal-im/Monal/commit/8efa7662b7c5b7c12599ffa5f966e55caea80ebf, but it seems that they are using a different format.

thenktor commented 3 years ago

@mimi89999 against which one? The XEP based one by Ge0rg or the Conversations one?

@licaon-kter Add account with password in QR code also called provisioning. It was also implemented in Monal in 8efa766, but it seems that they are using a different format.

Well the better solution for provisioning would be to allow a MDM system to set the needed config variables. But most apps do not have this feature and devs are unwilling to add it.

mimi89999 commented 3 years ago

Do you have any documentation on how to add MDM support to apps?

thenktor commented 3 years ago

Apparantly the correct name is "managed configuration": https://www.appconfig.org/ios/ https://developer.apple.com/library/archive/samplecode/sc2279/Introduction/Intro.html

This is used by MDM systems to pre-configure apps. This is done by parameter/value pairs. Users then may only enter their password and are ready to go.

Here is an animated gif that shows the process for configuring Threema Work in a Sophos MDM: https://work.threema.ch/res/threema_mdm_sophos-ios.gif

ge0rg commented 3 years ago

I think onboarding via MDM is a fundamentally different approach for a fundamentally different user group.

MDM: the phone is a company phone and the app gets provisioned by a central account management service. This is only useful for corporate environments that centrally deploy the app to all users.

QR code onboarding: the phone is a private phone and you want to transfer an account from another device / register an account from a friend's invitation.

mimi89999 commented 3 years ago

I think onboarding via MDM is a fundamentally different approach for a fundamentally different user group.

I agree, but it might still be good to implement it if an enterprise wants to move from another platform to XMPP.

Echolon commented 3 years ago

I suggest all further MDM requests and discussions should go here: Add Managed AppConfig support [Buisness MDM] https://github.com/monal-im/Monal/issues/164

thenktor commented 3 years ago

MDM: the phone is a company phone and the app gets provisioned by a central account management service. This is only useful for corporate environments that centrally deploy the app to all users.

QR code onboarding: the phone is a private phone and you want to transfer an account from another device / register an account from a friend's invitation.

Yes, but we are using both in our enterprise environment, e.g. QR provisioning with the 3CX phone system, the "managed configuration" with Threema and some other stuff. Both works well for admins and users. Most important thing is to not waste your time with entering "1000" config options on your smartphone. Users do it wrong many times and call the admins. Admins get grey hair when entering all the stuff for all users. Never a system would be deployed if you know this beforehand 👎

The QR thing is something you can use at home, too. And also at home nobody wants to enter the stuff on the phone anymore. Just open the app, scan something and your done (Signal/Threema). Just my 2 cents ;-)

Echolon commented 3 years ago

Should this issue be connect to 4.9 ?

Echolon commented 3 years ago

@tmolitor-stud-tu @FriedrichAltheide what the status here - should this connected to 4.9?

FriedrichAltheide commented 3 years ago

No

lissine0 commented 1 year ago

As of right now, there's nothing that the Add account QR-code scanner would accept:

  1. xmpp:inviter@example.com?roster;preauth=TOKEN;ibr=y -> Wrong menu. The qrcode contains a jid. Rescan the qrcode in the add user menu.

  2. https://example.com/invite/#TOKEN -> invalid format. We could not find a xmpp related QR-Code

  3. xmpp:example.com?register;preauth=TOKEN -> invalid format. We could not find a xmpp related QR-Code

  4. xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp -> Wrong menu. The qrcode contains a jid. Rescan the qrcode in the add user menu.

So it seems like support hasn't been added yet (despite the QR code scanner being there) Anyway, the support for 2. should be added, in addition to the list of URI schemes @ge0rg wrote. I'm not sure using such link directly in the xmpp client is mentioned in the XEPs, but Conversations is able to do it, at least on first app use.

Also, as of now, in the Add Contact view, 1. and 4. work, but the jid is simply parsed, which means the other entity would get a roster subscription request. Instead, the token in the URI should be used for pre-authentication. That way, your roster subscription is immediately accepted. Moreover, 2. should be supported here as well.

lissine0 commented 1 year ago

In Add contact, the share button should use the iOS sharing functionality; It should probably also show a qr-code of the link/uri

FriedrichAltheide commented 1 year ago

Currently, the account scanner should accept a QR code containing the username and password

lissine0 commented 1 year ago

Currently, the account scanner should accept a QR code containing the username and password

I'm not sure that's a good idea. As said in https://github.com/monal-im/Monal/issues/172#issuecomment-737778289:

Showing the account password in a QR code is a security nightmare.

XMPP invites solve the same problem in a more secure way.

FriedrichAltheide commented 1 year ago

First of all, we did not propose the format. Instead, we implemented a protocol format that was already implemented by Conversations https://github.com/iNPUTmice/Conversations/issues/3796. As described in the referenced ticket the format was designed to be used directly after registering a new user e.g., using a command line tool.

Scenario: A family member wants an account. This member will - as always - forget his password. Hence, just create an account, let the family member scan the QR-code. In the future, when the family member has a new device: create a new password and let the member scan the new QR code. In this scenario I do not see a security nightmare.

For other scenarios invite links are the way to go. But I strongly disagree to say that showing a password in a QR code is directly a security nightmare. (e.g., If I want to add a device manually: I open my password manager on my pc, open the XMPP account entry in the password manager and then manually typing my username and password in my phone. It does not matter if the password was shown in plaintext or if it was encoded in a QR code. In both cases I would need to ensure that nobody / or only trusted people are in the room with me and my password) Or if I follow an invite link, I still need to set a password. This password should better be saved inside the password manager of my choice. Therefore, I will type the password into that software. To make sure that the saved password is the same as set on my phone, I will probably check if the password is correctly saved in the manager. Hence the password is again shown in cleartext on my screen. No difference to generating a password on my computer and scanning it using my phone as again I must ensure that nobody or only trusted people are near my screen.

lissine0 commented 1 year ago

Okay, fair point.

tmolitor-stud-tu commented 1 year ago

Regarding invites: this is already implemented, monal reacts on all of ge0rg's urls just fine if you tap on such urls. Only the qr-code usecase is not implemented yet.

tmolitor-stud-tu commented 1 year ago

Invites are already in monal stable, btw.

lissine0 commented 12 months ago

I made a mistake while generating the qr codes (I was using qrencode and didn't enclose the uri's in double quotes. So, the parts after a semicolon weren't included) I am sorry. I tested again, using alpha build Oct 9 2023: 20:45:29 UTC (it would be helpful if the alpha version string shows the first 7 characters of the last commit, but in this case I believe it's 0a908b62) Now, everything I tested in https://github.com/monal-im/Monal/issues/172#issuecomment-1751680205 works, (with the exception of registering an account using xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp But that's the correct behavior, because it's an invite for just a roster subscription.)

The current invites support in Monal is really satisfying! Thank you for the great work!

Nevertheless, here's some feedback (I think the two points are related):

It would be nice if these things could be skipped when processing an invite.

Bonus points if at some point Monal is able to extract the invite uri from the landing webpage, without the user having to browse it, like Conversations does (at least when C's account list is empty) =]]

lissine0 commented 12 months ago

By the way, I'm not sure but I think these XEPs should be marked as complete in the doap file ( 0379, 0401 and 0445)

tmolitor-stud-tu commented 12 months ago

yes, the xeps should be marked as complete, thanks for the hint.

regarding your first point: not all servers auto-add the contact when registering, checking if the contact is already there before opening the add contact gui involves quite a bit of shuffling code around since the login and roster retrieval must be finished before opening the add contact gui.

regarding your second point: this notification is in place because the token for roster pre-approval could be invalid or not processed by the server at all. the incoming notification telling asking you to accept the remote contact is right, too: that is the server sending monal a contact request. if the server had auto-accepted it, it would not have sent this.

your bonus point will never be implemented, because every invite website could in principle invent their own format to transport the xmpp uri inside the http link. extracting something and hoping that it includes everything that was intended to be part of the xmpp: uri is error prone and I don't want to do this.

tmolitor-stud-tu commented 12 months ago

but a quick question: what servers did you try the invite feature with? yax.im on both accounts?

lissine0 commented 12 months ago

I used a self hosted Prosody 0.12.4 If you need a test account, or want me to test with another configuration, let me know.

lissine0 commented 12 months ago

About the earlier points, I was merely suggesting to improve the UI, from an end-user perspective, because it might be confusing.

tmolitor-stud-tu commented 12 months ago

About the earlier points, I was merely suggesting to improve the UI, from an end-user perspective, because it might be confusing.

I know, but unfortunately it's not that easy.

Could you check if your findings are still true, if all accounts involved in the test are *@yax.im accounts?

lissine0 commented 12 months ago

I was going to suggest to remove the Already present. This contact is already in the contact list of the selected account alert. Then I found out that using prosody trunk, when creating an account using an invite, Monal doesn't show the Add Contact view. The inviter is automatically in your contacts' list.

About yax.im, they have allow_user_invites = false, which breaks roster preauth for some reason (tested in Monal as well as in Conversations) I already mentioned this in the prosody channel, they said it could be https://github.com/snikket-im/snikket-server/issues/105

tmolitor-stud-tu commented 9 months ago

@lissine0 Am I right that this issue can be closed now?

lissine0 commented 9 months ago

To my knowledge yes. From an earlier comment of mine:

The current invites support in Monal is really satisfying! Thank you for the great work!

By the way, it may be the time to mark XEP-397 as complete. Is there some unimplemented functionality related to it? I noticed that you marked XEP-401 as complete in 6.0 but not XEP-379