Non-human-friendly TOTP identifier

[salmart-dev]

Steps to reproduce

1. Use a recent Nextcloud version
2. Enable this app
3. Enable the Guest app
4. Create a guest user
5. Log-in with the guest user
6. Enable TOTP and inspect the HTTP request of the update or scan the QR

Expected behaviour

The identifier of the TOTP secret is: Nextcloud:user@email.xy@ncinstance.xz

Actual behaviour

The identifier of the TOTP secret is: Nextcloud:[SHA256]@ncinstance.xz

App version

No response

Nextcloud version

No response

Additional info

Caused by the guests app changing the uid, depending on a setting, which is enabled by default.

nextcloud/guests#1335

[ChristophWurst]

This app uses the federated cloud ID of the user. So this is either an issue of server or the guests app.

[salmart-dev]

This app uses the federated cloud ID of the user. So this is either an issue of server or the guests app.

Is the user's uid always a human-readable value?

There was a change in the guests app to hash the email for privacy reasons, which changes the return value of getCloudId, which in turn affects this app.

So either the change in the guests app needs to be rolled-back or the new behaviour needs to be adapted in this one. WDYT?

[ChristophWurst]

It's probably not. With LDAP and UUID mapping to Nextcloud UID it's the same messy situation.

I don't know how this could be solved to have a happy outcome for all user backends.

[ernolf]

Anyone who needs this feature; this is solved in twofactor_oath, a separate OATH provider app with TOTP functionality (besides HOTP and OCRA)

https://github.com/ernolf/twofactor_oath

Since v0.3.0 the provisioning label falls back to the email address when the user ID is an opaque identifier (the guests app's SHA-256 email hash or an LDAP UUID), and the label can also be edited right next to the QR code before scanning. So every account gets a short, recognizable name in the authenticator app, no matter what the user backend does to the user ID.

h.t.h.

ernolf