[Feature request] Do not allow users to fetch TOTP config

Exotrom commented

2021-05-23 13:37:11 +02:00

(Migrated from github.com)

Is your feature request related to a problem? Please describe.
For my use-case I allow users to login without any 2FA. However, some scopes require them to use 2FA (including WebAuthn, E-Mail and TOTP).
When a session is compromised (e.g. password is known or session is still valid on an compromised client) an attacker can enter the profile page, select "TOTP" and scan the TOTP QR-code even if TOTP registration is disabled for end-users.

Describe the solution you'd like
A solution would be to disable the retrieval of the TOTP QR-Code and TOTP secret via API and UI. Only during registration, those credentials should be visible by using the entered/generated data on the client and not by using the server API.

Additional context
I am using glewlwyd:2.5.3 using docker.

**Is your feature request related to a problem? Please describe.** For my use-case I allow users to login without any 2FA. However, some scopes require them to use 2FA (including WebAuthn, E-Mail and TOTP). When a session is compromised (e.g. password is known or session is still valid on an compromised client) an attacker can enter the profile page, select "TOTP" and scan the TOTP QR-code even if TOTP registration is disabled for end-users. **Describe the solution you'd like** A solution would be to disable the retrieval of the TOTP QR-Code and TOTP secret via API and UI. Only during registration, those credentials should be visible by using the entered/generated data on the client and not by using the server API. **Additional context** I am using glewlwyd:2.5.3 using docker.

babelouest commented

2021-05-23 14:35:13 +02:00

(Migrated from github.com)

Hello @HYMXDEV ,

Thanks for the feature request.

I understand the needs and it makes sense, although the idea in the first place was so the user to be able to configure TOTP in multiple devices (phone(s), tablet(s), etc.).

A possible workaround is to have at least 2 authentication factors to connect to the profile page for a user, not the password only. Because a similar issue exists with Webauthn and OAuth2/OIDC client: if an attacker gets access to the profile page of a user, it can easily adds another webauthn device or another external account to connect as the user.

I will add this feature in a next release for all the potentially dangerous schemes: OTP, Webauthn and OAuth2/OIDC client.

If you're willing, I'll let you know when the new feature will be available in beta so you can test it before the release.

Hello @HYMXDEV , Thanks for the feature request. I understand the needs and it makes sense, although the idea in the first place was so the user to be able to configure TOTP in multiple devices (phone(s), tablet(s), etc.). A possible workaround is to have at least 2 authentication factors to connect to the profile page for a user, not the password only. Because a similar issue exists with Webauthn and OAuth2/OIDC client: if an attacker gets access to the profile page of a user, it can easily adds another webauthn device or another external account to connect as the user. I will add this feature in a next release for all the potentially dangerous schemes: OTP, Webauthn and OAuth2/OIDC client. If you're willing, I'll let you know when the new feature will be available in beta so you can test it before the release.

Exotrom commented

2021-05-23 14:49:33 +02:00

(Migrated from github.com)

Hi @babelouest - thanks for the fast response and also for the great work and effort you have put into glewlwyd!

I would be more than happy to test the feature once available. For now, I decided to build my own version where I have removed the TOTP secret in the API response, which does the trick for now.

Best regards, Leonard

Hi @babelouest - thanks for the fast response and also for the great work and effort you have put into glewlwyd! I would be more than happy to test the feature once available. For now, I decided to build my own version where I have removed the TOTP secret in the API response, which does the trick for now. Best regards, Leonard

babelouest commented

2021-05-23 14:55:43 +02:00

(Migrated from github.com)

No problem, beware that webauthn is still vulnerable until the feature is implemented then

babelouest commented

2021-05-23 15:30:55 +02:00

(Migrated from github.com)

Also @HYMXDEV , in my vision, when the administrator opens the user's profile page in delegation mode, it can see the user's TOTP secret and QR-Code, like this, an admin can send back the QR-Code to the using a secured channel. Do you agree?

Also @HYMXDEV , in my vision, when the administrator opens the user's profile page in [delegation mode](https://github.com/babelouest/glewlwyd/blob/master/docs/GETTING_STARTED.md#user-profile-delegation), it can see the user's TOTP secret and QR-Code, like this, an admin can send back the QR-Code to the using a secured channel. Do you agree?

Exotrom commented

2021-05-23 18:12:45 +02:00

(Migrated from github.com)

No problem, beware that webauthn is still vulnerable until the feature is implemented then

Thanks for the heads-up. I have disabled the WebAuthn registrations for end-users, which is feasible for my use case. That should not reveal any sensitive data, right?

Also @HYMXDEV , in my vision, when the administrator opens the user's profile page in delegation mode, it can see the user's TOTP secret and QR-Code, like this, an admin can send back the QR-Code to the using a secured channel. Do you agree?

That would be okay for me. Personally, I think those secrets must not be revealed once set. Most TOTP solutions I have used so far allow to register multiple TOTP devices/secrets (similar to the WebAuthn plugin) and don't allow to retrieve the secrets after all. If an admin wants to send the secret or QR to the user in a secured channel, he should generate it and send it right away. That way it is ensured, that an attacker, who gains full access to an account is not able to get permanent access without "notifying" the user by cloning the already existing TOTP client - instead, he would have to create a new TOTP registration. But as stated, I am okay with both solutions.

> No problem, beware that webauthn is still vulnerable until the feature is implemented then Thanks for the heads-up. I have disabled the WebAuthn registrations for end-users, which is feasible for my use case. That should not reveal any sensitive data, right? > Also @HYMXDEV , in my vision, when the administrator opens the user's profile page in delegation mode, it can see the user's TOTP secret and QR-Code, like this, an admin can send back the QR-Code to the using a secured channel. Do you agree? That would be okay for me. Personally, I think those secrets must not be revealed once set. Most TOTP solutions I have used so far allow to register multiple TOTP devices/secrets (similar to the WebAuthn plugin) and don't allow to retrieve the secrets after all. If an admin wants to send the secret or QR to the user in a secured channel, he should generate it and send it right away. That way it is ensured, that an attacker, who gains full access to an account is not able to get permanent access without "notifying" the user by cloning the already existing TOTP client - instead, he would have to create a new TOTP registration. But as stated, I am okay with both solutions.

babelouest commented

2021-05-23 18:49:33 +02:00

(Migrated from github.com)

Thanks for the heads-up. I have disabled the WebAuthn registrations for end-users, which is feasible for my use case. That should not reveal any sensitive data, right?

No, even with the current setup, no sensitive data can be stolen from the webauthn registration, because is't based n a private key signature, and Glewlwyd stores the public key only. The private key is impossible to get, even for the user itself, because it's stored in the yubikey. But as I said, if an attacker gets access to the profile page, it can register a new yubikey in the profile, then log in, that's why I will make a similar upgrade to this scheme as well => forbid a user to view or change its registration if specified.

That would be okay for me. Personally, I think those secrets must not be revealed once set.

I disagree, but that's why there will be an option to make everyone happy ;)

The security issue with OTP is that the secret must be available unencrypted to the auth server or the client, because the code is generated using a combination that looks like that: take_6_digits_from(SHA1(shared_secret + counter)).

In Glewlwyd, the shared secrets are stored unencrypted. Because I assume that if an attacker gets access to Glewlwyd's database, the administrator will have bigger problems to solve than updating users OTP configuration.

The way I see it, for each sensitive scheme, 2 options will be added:

Allow a user to update this scheme registration on the profile page
Allow a user to update this scheme registration on the lost credentials page

> Thanks for the heads-up. I have disabled the WebAuthn registrations for end-users, which is feasible for my use case. That should not reveal any sensitive data, right? No, even with the current setup, no sensitive data can be stolen from the webauthn registration, because is't based n a private key signature, and Glewlwyd stores the public key only. The private key is impossible to get, even for the user itself, because it's stored in the yubikey. But as I said, if an attacker gets access to the profile page, it can register a new yubikey in the profile, then log in, that's why I will make a similar upgrade to this scheme as well => forbid a user to view or change its registration if specified. > That would be okay for me. Personally, I think those secrets must not be revealed once set. I disagree, but that's why there will be an option to make everyone happy ;) The security issue with OTP is that the secret must be available unencrypted to the auth server or the client, because the code is generated using a combination that looks like that: `take_6_digits_from(SHA1(shared_secret + counter))`. In Glewlwyd, the shared secrets are stored unencrypted. Because I assume that if an attacker gets access to Glewlwyd's database, the administrator will have bigger problems to solve than updating users OTP configuration. The way I see it, for each sensitive scheme, 2 options will be added: - Allow a user to update this scheme registration on the profile page - Allow a user to update this scheme registration on the lost credentials page

Exotrom commented

2021-05-23 19:27:14 +02:00

(Migrated from github.com)

No, even with the current setup, no sensitive data can be stolen from the webauthn registration

Thanks for the clarification.

Because I assume that if an attacker gets access to Glewlwyd's database, the administrator will have bigger problems to solve than updating users OTP configuration.

I agree, in case the database is compromised, there is no much hope in terms of security.
My concern was more towards the situation, that a single user session gets compromised. In that case the attacker can simply steal the current OTP configuration. So he does not only takes over the session, but he might also be able to get permanent access, as he can create OTP codes. But the user can't tell that something is wrong, as his generated codes will still work and he also does not see any additional registered OTP configs.

I guess it is a very unlikely scenario, but still, a "write-only" mode would help at least a bit (because the user can see new registration)

Nevertheless, I am very happy about your suggested features and the constructive discussion.
Keep up the great work!

> No, even with the current setup, no sensitive data can be stolen from the webauthn registration Thanks for the clarification. > Because I assume that if an attacker gets access to Glewlwyd's database, the administrator will have bigger problems to solve than updating users OTP configuration. I agree, in case the database is compromised, there is no much hope in terms of security. My concern was more towards the situation, that a single user session gets compromised. In that case the attacker can simply steal the current OTP configuration. So he does not only takes over the session, but he might also be able to get permanent access, as he can create OTP codes. But the user can't tell that something is wrong, as his generated codes will still work and he also does not see any additional registered OTP configs. I guess it is a very unlikely scenario, but still, a "write-only" mode would help at least a bit (because the user can see new registration) Nevertheless, I am very happy about your suggested features and the constructive discussion. Keep up the great work!

👍 1

babelouest commented

2021-05-30 05:38:59 +02:00

(Migrated from github.com)

Hello @HYMXDEV ,

I've added a new feature in the master branch to handle the so-called "forbidden scheme". It adds 2 options in the scheme configuration to allow the admin to forbid a scheme to be registered by the user on the profile page or on the reset credential page.

Before Glewlwyd's next version is released, if you can take a look at this to make sure it fits your needs and does not cause side effects, that would be appreciated.

2 new columns have been added to the SQL table g_user_auth_scheme_module_instance, so you need to update your existing database:

  guasmi_allow_user_register TINYINT(1) DEFAULT 1,
  guasmi_forbid_user_profile TINYINT(1) DEFAULT 0,

This is still a BETA though!

Also, if you are willing, could you help with the German translation with those new messages?

"mod-forbid-user-profile": "Forbid users to register on the profile page",
"mod-forbid-user-reset-credential": "Forbid users to register on the reset credential page",
"scheme-register-forbidden": "The administrator forbids to register or get the registration of this scheme"

Thanks in advance

Hello @HYMXDEV , I've added a new feature in the [master branch](https://github.com/babelouest/glewlwyd.git) to handle the so-called "forbidden scheme". It adds 2 options in the scheme configuration to allow the admin to forbid a scheme to be registered by the user on the profile page or on the reset credential page. Before Glewlwyd's next version is released, if you can take a look at this to make sure it fits your needs and does not cause side effects, that would be appreciated. [2 new columns](https://github.com/babelouest/glewlwyd/blob/master/docs/database/init.mariadb.sql#L85) have been added to the SQL table `g_user_auth_scheme_module_instance`, so you need to update your existing database: ```SQL guasmi_allow_user_register TINYINT(1) DEFAULT 1, guasmi_forbid_user_profile TINYINT(1) DEFAULT 0, ``` This is still a BETA though! Also, if you are willing, could you help with the German translation with those new messages? ```JSON "mod-forbid-user-profile": "Forbid users to register on the profile page", "mod-forbid-user-reset-credential": "Forbid users to register on the reset credential page", "scheme-register-forbidden": "The administrator forbids to register or get the registration of this scheme" ``` Thanks in advance

Exotrom commented

2021-05-30 13:25:16 +02:00

(Migrated from github.com)

Hello @babelouest ,

thanks a lot for providing this functionality that fast. I tested the new flags.
They do work as expected and also meet my requirements.

#186 contains the updated German localization with the new strings included. Maybe I will have some time in the near future to address some other untranslated strings as well.

However, I saw that the English locale does not work in my own build. 2b5bc5d28c has fixed the broken json, but maybe you can update the static webapp build as well?

Thanka a lot and best regards

Hello @babelouest , thanks a lot for providing this functionality that fast. I tested the new flags. They do work as expected and also meet my requirements. #186 contains the updated German localization with the new strings included. Maybe I will have some time in the near future to address some other untranslated strings as well. However, I saw that the English locale does not work in my own build. 2b5bc5d28c0e468f25c4d4de22beb19c79f52928 has fixed the broken json, but maybe you can update the static webapp build as well? Thanka a lot and best regards

babelouest commented

2021-05-30 13:28:37 +02:00

(Migrated from github.com)

The locales have been updated in the webapp/ directory, the english locale should be ok now, thanks for pointing out!

Rows
Columns

[Feature request] Do not allow users to fetch TOTP config #185