[feature-proposal] Forgot password improvements

[Ewout ter Haar]

This email made me really mad. I needed to write it to make a
statement about this community. The take-away message is: "I don't
care about displaying the disambiguation info. Forget about it then.
Just send the two emails."

>
> On 11/11/2013 08:08 PM, Ewout ter Haar wrote:
>> Only for those users who share (the value of) two identifiers that
>> the admin of the noosfero instance chose to activate.
>
> No, it won't. One user may abuse the system trying values for one of
> the fields and asking for the password reset instructions for each value.
> Even showing public information in this case, that would mean a data
> leakage, since the matched value of the field could be private.

I think you are condescending, explaining things to me that are
obvious. Didn't you understand our previous discussion that this would
only be done in that case that n>1? How can I explain it better than
that? What part of "implement that solution just for "User.count >
2"." was not clear? I even conceded a bit of your (obvious) point
mentioning rate-limiting, which would be a nice security enhancement.
But isn't it completely obvious because of the extremely small
fraction of users potentially affected (in most instances, 0), this
risk of "data leakage" is a complete non-issue?

That said, I don't care about displaying the disambiguation info.
Forget about it then. Just send the two emails.

>
> In other words, one attacker could get a name matching some CPF and
> use that in some illicit transaction.

Scaremongering just to impress the less technically inclined. Could
you please do the calculation what are chances in a typical noosfero
userbase that we have two people, one with "The user A has a cpf 123
and the user B as an rg 123" (as in Rodrigo original example). What is
you attack model exactly? It just doesn't make sense.

I see a few positive contributions in this thread: one from Daniel,
who started the discussion and alerted us to the negative usability
implications of the naive solution, and some brainstorming about
potential solutions. I was just going to point to this thread as an
example how a diverse group of people with different strength and
perspective collectively can come up with a good solution to a
(admittedly simple) problem. But unfortunately I also see a lot of
technical intimidation ("intersection of sets", "RG collide with
CPF"). Meritocracy, if you really want that, should oblige you to make
an attempt to include all people in the discussion. Don't use
technical arguments just to score points or as the end-all of the
discussion.

>
>> Can we get some perspective, please? Some clear-headed balancing
>> of the trade-offs?
>
> Privacy and data security are more important than additional ways to
> reset the password, since the email is already required.
> How it would be possible to receive an email for password reset
> without knowing the email in the first place?
> If the user has multiple emails, he can make one try for each one.
>

You obviously have never managed users in a large system. Or thought
about it. Users forget which email they used to sign up. Users loose
access to their emails. Users forget their emails.  Users use emails
of their ex-girl-friends. That is why we want to be able (in the
future) to send email to an institutional email. Or send and SMS. Or
send something to their jabber address. Who knows?

> I am not against allowing other fields, but I am strongly against
> leaking private data.

Oh really.

>
> But I would ask: if the user knows his email and he will have to check
> it, why then ask for anything other?

Because they don't remember the email with which they signed up!
Please... try all of their emails one by one? *That* is your
suggestion?

I'm getting really tired of Colivre people not having the faintest
idea what is like to be admin or helpdesk for real, live network. This
is what you people do! Go talk to some users of your software.

> The username is nice, because it is usually shorter than the email and
> it's usually easier to remember the username when the user has more
> than three or four emails. But username disclosure is something which
> won't add any security concern.

Well I agree, but according to your reasoning it would be a privacy
disaster. Because (this must be news to you) some people happen to use
their CPF as username! Ha! Didn't think of that? Stupid users, right?
Still, there must be at least as many users in this situation as the
case we discussed above ("intersecting sets" remember?), so I guess we
can't publish usernames. Oops, they're in the URL...

>
> Adding sensitive data to the allowed recovery fields and mapping it to
> any information, even public, will expose that sensitive data.
>
> Any kind of disclosure of sensitive data will have negative impacts on
> the community and on the software. IMHO, that's a pretty bad trade-off.

I don't think you have given a fair picture of the trade off.

Ewout