search

sympa-community / sympa

Sympa, Mailing List Management Software
https://www.sympa.community/sympa
GNU General Public License v2.0
241 stars 95 forks source link

Feature request: a "delete my account" button #300

Closed ldidry closed 5 years ago

ldidry commented 6 years ago

There should be a "delete my account" button that unsubscribe you from all lists and remove your account immediatly.

To protect that feature, Sympa could

  1. asks for the user password
  2. send a mail with a link containing a token
qosobrin commented 6 years ago

I totally agree with this feature.

racke commented 5 years ago

Sounds a good idea to me ... what would be the workflow if the user is logged in to the web interface already?

ldidry commented 5 years ago

Well, ask him/her to enter its password to confirm the action.

ldidry commented 5 years ago

I could use some advices on how to do that properly. See my message on sympa-developpers ML: https://listes.renater.fr/sympa/arc/sympa-developpers/2018-12/msg00003.html

Currently, there is only a web interface, asking for the password to confirm identity. I'll test it today.

dverdin commented 5 years ago

This is a very useful feature. However, it is wrong to restrict it to native authentication. This feature is useful mainly in publicly available services, such as Framasoft, Riseup or Universalistes, where people use the service because they want to. It should not be allowed in enterpises instances where people are subscribed to mailing list because it is part of their job. Therefore, I think there should be a global control over the activation of this feature. An "on/off" parameter at the virtual host level. I think also that it should not be based on the authentication mechanism for a lot of reasons:

  1. some publicly available services, such as Universalistes, use SSO. Any instance run under Yunohost uses LDAP.
  2. at the opposite, some enterpise services use native authentication, for their guests,
  3. how to decide to enable / disable the service when using several authentication mechanisms, which is allowed by Sympa?
  4. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.
  5. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

To sum up, this feature could be generalized by:

OK. That's about it. What do you think?

ldidry commented 5 years ago

@dverdin I think it's good :+1:

ikedas commented 5 years ago

I've wrote why this feature should be enabled only with native (user_table) authentication. See https://github.com/sympa-community/sympa/pull/511#issuecomment-453741929

This is a very useful feature. However, it is wrong to restrict it to native authentication. This feature is useful mainly in publicly available services, such as Framasoft, Riseup or Universalistes, where people use the service because they want to. It should not be allowed in enterpises instances where people are subscribed to mailing list because it is part of their job.

I think of the services open to public, such as FramaListes, Slack etc., and focus on the control over personal data: Using those services naturally means leaving user's personal data (typically account information) in trust with these services. It is desirable that the users could control personal data of their own.

Conversely, it may not be allowed for the services (itself) dedicated to particular organization including universities, enterprise or other autonomous groups which manage personal data with their own policies by each.

Therefore, I think there should be a global control over the activation of this feature. An "on/off" parameter at the virtual host level. I think also that it should not be based on the authentication mechanism for a lot of reasons:

  1. some publicly available services, such as Universalistes, use SSO. Any instance run under Yunohost uses LDAP.
  2. at the opposite, some enterpise services use native authentication, for their guests,
  3. how to decide to enable / disable the service when using several authentication mechanisms, which is allowed by Sympa?

By reason I wrote in above, I agree to add an option to activate/deactivate this feature, while I still think that identity sources not controllable by Sympa should be excluded.

  1. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.

I think this behavior is a fault of design. Using user_table as cache of information about authenticated users might cause leakage of personal data beyond the different identity sources (You can see similar problem on #347).

I think information about authenticated users should be kept in volatile web session and should not be stored in any persistent spaces such as user_table without permission by the user themselves (I want to submit PR in near future).

  1. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

By the reasons above, I disagree to this suggestion.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

As I wrote in the comment at the beginning, this matters authorization instead of authentication.

  • replace password confirmation by email confirmation,

I also don't agree to it.

Edit: Insertion.

dverdin commented 5 years ago

Hi Soji!

I think of the services open to public, such as FramaListes, Slack etc., and focus on the control over >personal data: Using those services naturally means leaving user's personal data (typically account >information) in trust with these services. It is desirable that the users could control personal data of >their own.

Conversely, it may not be allowed for the services (itself) dedicated to particular organization >including universities, enterprise or other autonomous groups which manage personal data with their >own policies by each.

Ok, so we have the same opinion.

  1. When somebody authenticates using SSO, an entry is added to the user_table. This is the main reason that seems to justify the restriction to native authentication because we can't prevent it and therefore the user would be re-provisionned if he authenticates. I don't think it is such a big deal. We could certainly prevent this entry to be added. It is not usefull anyway, as long as the user has no subscription and is not admin of any list.

I think this behavior is a fault of design. Using user_table as cache of information about authenticated users might cause leakage of personal data beyond the different identity sources (You can see similar problem on #347).

I think information about authenticated users should be kept in volatile web session and should not be stored in any persistent spaces such as user_table without permission by the user themselves (I want to submit PR in near future).

Totally agreed! It is what I suggested when writing "We could certainly prevent this entry to be added."

  1. Currently, the workflow seems to ask for a password confirmation before accepting the account deletion. this is possible with native authentication only. It should be replaced by sending a mail with a link to click to confirm. And a last confirmation on the web interface for good measure. this way, no need to restrict to native authentication.

By the reasons above, I disagree to this suggestion.

I'm sorry, I don't see the reasons above that would lead to disagreement with this.

Finally, I think we should restrict unsubscription to the lists where it is allowed, namely base unsubscription on the unsubscribe scenario, which is the standard mechanism for unsubscriptions. If you think it is unfair, then you probably should not allow to close owners unsubscription on your server in the first place (reminder: any scenario - like unsubscribe.closed - can be made unavailable by adding ".hidden" in the end of its name).

As I wrote in the comment at the beginning, this matters authorization instead of authentication.

Indeed. But it is a matter directly related to the current topic. In the workflow used by @ldidry, the confirmation of account deletion is based on password. If the server uses external authentication, users don't have a Sympa-specific password.

That's why I suggest to use mail instead of password confirmation. In addition, it is also the usual mechanism in Sympa. I don't think we use password confirmation anywhere else. Which makes sense, as we never know which authentication mechanism will be used.

  • replace password confirmation by email confirmation,

I also don't agree to it.

Edit: Insertion.

So we agree for everything, except allowing for third party authentication (the email confirmation is a consequence of it).

Anyone else having an opinion?

ldidry commented 5 years ago

Well, @dverdin, as you say, email confirmation allows users using external authentication process to delete their account. It sure will be better. The reason I used password is… that I don't know how to create email confirmation :neutral_face:

Using email confirmation will, as a bonus, simplify my code.

ikedas commented 5 years ago

@ldidry:

Using email confirmation will, as a bonus, simplify my code.

If dverdin's idea is adding another authentication with another factor (verifying possession of e-mail mailbox/account along with verifying knowledge of login password), it makes sense.

Notes:

@dverdin, if you see I understood correctly, I'll agree to add e-mail confirmation (it may store a request into Sympa::Spool::Auth spool and authenticate it by Sympa::Request::Handler::auth handler). However, I'd like you to understand that the new feature will be available only with users authenticated by user_table by now.

And anyway, an option to activate/deactivate this feature looks required.

ldidry commented 5 years ago

e-mail confirmation itself is vulnerable authentication method

Well… you can ask to recover a lost password by mail, so asking for a password is not really a strong protection.

I mean, if an attacker has control of the mailbox of a user, he can ask for a new password, use the link in the password-recovery email, then delete the account with the new password.

dverdin commented 5 years ago

@ldidry:

Using email confirmation will, as a bonus, simplify my code.

If dverdin's idea is adding another authentication with another factor (verifying possession of e-mail mailbox/account along with verifying knowledge of login password), it makes sense.

Oh, no, I'm not that clever! ;-) I just wanted to get rid of an unorthodox confirmation method to use the one usually employed in Sympa.

However, I understand that it is a very specific query that requires specific security.

Email confirmation is, indeed, the same level of security as password because you get or renew your email using the mailbox. So if you get access to the user's mailbox, its password can be considered lost. But as Soji said:

Verifying password twice won't strengthen authentication by itself

By asking for the password, he only wants the user to realize how important the operation he is doing is. I think it is also a convenient way to prevent bad people to clear an account by simply finding an unlocked computer with an active Sympa session. A lot of systems do this: they use your current session until you ask for something private or drastic, then they ask for your password.

So the crucial part is not "how to check the user's identity." I think that web authentication plus email confirmation is indeed good enough to ensure that the person requesting the action is probably who he says he is.

The question would be : how to efficiently warn the user that he is about to delete all his subscriptions and list ownerships? Asking for a password works perfectly for native authentication. But it leaves the other authentication methods orphan, which is sad. I don't have the answer to this problem yet. Genuinely, I would display large warning with red background. That kind of thing. Which won't work for people with sight problems.

ikedas commented 5 years ago

e-mail confirmation itself is vulnerable authentication method

Well… you can ask to recover a lost password by mail, so asking for a password is not really a strong protection.

I mean, if an attacker has control of the mailbox of a user, he can ask for a new password, use the link in the password-recovery email, then delete the account with the new password.

Indeed it's possible. From the beginning, e-mail don't have high secrecy: Transmission channels are often unencrypted; Accounts are occasionally shared among users; ....

Since e-mail confirmation is vulnerable, one measure is restricting its effective range, for example: Sending random tokens by each message to be moderated, instead of sending one token to approve all messages; Surely expiring outdated token; Using it in combination with the other authentication method; Not sending token without confirmation by user; and so on.

Currently, Sympa overuses e-mail confirmations (for example see #156). However, it doesn't mean that e-mail confirmation is the potent measure for authentication.

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

dverdin commented 5 years ago

Since e-mail confirmation is vulnerable, one measure is restricting its effective range, for example: Sending random tokens by each message to be moderated, instead of sending one token to approve all messages; Surely expiring outdated token; Using it in combination with the other authentication method; Not sending token without confirmation by user; and so on.

Yes. e-mail confirmation must be focused on one precise action and limited in time. Like for one time tickets.

Currently, Sympa overuses e-mail confirmations (for example see #156). However, it doesn't mean that e-mail confirmation is the potent measure for authentication.

Maybe. Though honestly, we never had any problem with it. But it is not a reason not to question the mechanism.

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

Yes, the problem is deeper than expected. we need a bit of time to think it thoroughly.

ldidry commented 5 years ago

I suggest to release the next beta including PR #511, possiblly adding an option to activate/deactivate this feature. We would be better to begin with minimum feature.

Ok. I'll add an option, marked as "experimental", and disabled by default. I'll do it friday (my day dedicated to Sympa).

ldidry commented 5 years ago

Option added!

ikedas commented 5 years ago

Great job @ldidry!

dverdin commented 5 years ago

Very nice, Luc! Thanks! As far as I'm concerned, this PR is as good as it could be. So I agree with its inclusion to 6.2.42.

ilf commented 3 years ago

Thanks for this issue and the implementation!

It's been two years, maybe we can finish the "experimental" phase.

I propose to enable this by default. Allowing users to delete their personal data is a legal requirement of the GDPR.

It it can't be enabled by default, I propose to add this at least to sympa.conf so admins are aware of it and can easily enable it.

Thanks, and keep up the good work!

lucyferu commented 1 year ago

one more year has passed and it's still not straightforward the possibility to delete your account. 😢

racke commented 1 year ago

one more year has passed and it's still not straightforward the possibility to delete your account. cry

You can delete your account when allow_account_deletion is enabled in the configuration. It shouldn't be experimental any more though.