|Recipients||ThomasAH, ber, ezio.melotti, luke, rouilj|
Hi Thomas: In message <email@example.com >, Thomas Arendsen Hein writes: > >Of course there is always the discussion of "do we want to confirm that >an account with this name exists?" Moin wikis just say "If this account >exists an email was sent.". There can be multiple emails associated with the account. We need to give the user some indication which email was used to send the recovery password so they can choose one of the alternate addresses associated with the account to receive the password reset email. (That was the feedback from the ticket that I closed to provide the ability to send a reset email to an alternate address.) Also the user has the option of specifying the email address they want the recovery password sent to. If they specified an email address, should we mask it? Should we return an error if the user supplies an invalid lookup email address rather than a username? I think my answer is no don't return an error but... However we probably should always provide a positive response even if the username they asked for is invalid. Asking for a reset for the user "donny" who doesn't exist should result in: Email has been sent to d**ny@rx*****.**m The domain part of the result can be made up from random words/chars. >This sometimes is really annoying, so I would prefer to only have this >as an option (if at all), not the default, as the default behavior of >roundup is a public tracker, even if we mostly use non-public trackers. Agreed, it will be an tracker option maybe: mask_recovery_email = yes/no or even: recovery_email_mask_character = * default not set and no masking happens. If set to a character, masking happens using that character. >To make the obfuscation yield more privacy, I suggest obfuscating more, >especially in the username part, as this often includes the real name of >people. > >What about replacing everything with dots, except for the first >character of the localpart, the @ and the last character of the domain >(and the dots :)), e.g.: > >firstname.lastname@example.org -> u...@..........m >email@example.com -> u...@..........t >firstname.lastname@example.org -> f........@..........m -> >email@example.com -> f.................@.......e I am worried that that is too little info. I was trying to find a mask that displays places where there is likely to be a lot of variation in the unmasked bits. But still making enough to prevent somebody who won't know the original input from making an email address from it. Hence trying to include a couple of bytes of info around both sides of the @ sign. I think if we can get a mask that allows for 5-10 plausible variations in email addresses we have done our job. If it's a targeted attack against a specific user where the attacker has a lot of background knowledge, anything that would be useful to the actual account owner will also be useful to the attacker so... Also I think losing the structure of the email address (i.e. what is a . in the address vs. what is a masking dot) is a problem as well, but setting a different "masking_character" config option allows the tracker admin to choose. Maybe firstname.lastname@example.org -> u.er@ex........m email@example.com -> u.er@ex........t firstname.lastname@example.org -> f......me@ex........m -> email@example.com -> f...............me@nt.....e I have the same username at most places. The start of the domain spec is where the high entropy bits are located for my addresses. Thoughts?
|2016-07-07 12:01:49||rouilj||set||recipients: + rouilj, ber, ThomasAH, ezio.melotti, luke|
|2016-07-07 12:01:49||rouilj||link||issue2550716 messages|