Hi Thomas:

In message <1467883027.57.0.0387948914625.issue2550716@psf.upfronthosting.co.za
>,
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.:
>
>user@example.com -> u...@..........m
>user@example.net -> u...@..........t
>firstname@example.com -> f........@..........m ->
>firstname.lastname@ntvtn.de -> 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

  user@example.com -> u.er@ex........m
  user@example.net -> u.er@ex........t
  firstname@example.com -> f......me@ex........m ->
  firstname.lastname@ntvtn.de -> 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?