[feature-proposal] Forgot password improvements

[Caio Tiago Oliveira]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/2013 10:30 PM, Ewout ter Haar wrote:
> 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?

One malicious user could do a brute force attack, changing the value
of the fields of some fake generated users, using multiple IP address.
With one request per second and 200 users for a given state in Brazil,
one could find a CPF collision within one day. For a community with
2000 users from a given state, one collision could be found within a
day with just a request for each 10 seconds in average.

What security measure would you take in this case?

A captcha would certainly help here. Rate limiting too, although
harder policies would have to be taken by the administrators in the
case the malicious requests take too long.

>> 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.

 - user A has a CPF 123
 - user B tries setting from 001 to 999 in the RG field, asking for
password confirmation after each change. After 123 tentatives, he
would find out the CPF of user A.

The statistics are listed above. There are 10 macro regions, with 8
digits of unique identifier for each person, 1 digit for the macro
region and 2 for verification.

> 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.

Meritocracy? What?
Something you don't understand is intimidation for you? Sorry.

> 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?

Thanks for praising me. That was a terrific point. I would argue that
the user would had to know its phone number or jabber id, if he didn't
know his email. Also, he could use any non sensitive data (such as his
name, birthday, nick, university ID).
Or I could tell you that if he looses access to the email, he won't be
able to recover the account and that's another topic.

But I'm done. The environment admin may be able to use any field
there, as long as the user is aware of that. Then one easily could
blame the admin if he made some shit.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSgZIGAAoJEMzgGcmGlt4BiA8P/3R5MMh608woCbWPBEtHk3s2
6nUyuL3Qb7yGYDvJEH+FFAFASQo7eejl1eu/zHmJskCTqjVn/eJh9W3+F2rSZUZm
NhORBMzRYv1ZGb9SRWxNH06U3TUfyAebNTia2LXcrHhwJI2YnlMGKCRSdugRRfi7
N00ZVRp0FbsLaA0EG3TPoN2ridxFY02iFO+NFwhswRXnKHj0ipVIxOWunlputyhk
JS6TrCVfPidi9oYAOZsVPGcFDY061Bm2Xd80OGRR95SAEKzqZB+XZZdtqBbHr2DM
zSRsuS+BrDLY/SteZU2Wd0A0CKcm1A3aLvtDHV+nxq2k76YU9K4X394tBxolXFLJ
e4bJ04SmMkwukx1qR0QF2/Q4uK1n0qzw3Bh2igvE1WgvPhfGS1NzK6SMXegMxfmI
xpsEE9wy1DYi5cYgGVYsaQPdlJ2MTqzoljfHCj3u9YdBVIr1rFweN8CETvehlsi9
D1JsWFn3lhACThfcy8LbWtRL2qBaP+gosO8ba98L6RyIPZxWa2RKaYx4F7Z4j5dR
dbEciAQ1+HKtFKK+E1o3ypmYfUOAB2Dqrj/tcQKIe3hPwyYWr2592FN1+Wg7U5N1
s/ENI9x0v50RDiVXHtp1UnPLHhOpUS5e8sfyGeVqxHuDerj7ZpGn4fqadbmVVcUp
fsXANc6kQ6hreJZj0aup
=Wurh
-----END PGP SIGNATURE-----