[feature-proposal] Forgot password improvements

[Ewout ter Haar]

Thanks, this response shows the value of making explicit your thread
model. Everybody can now judge for themselves how important a threat
to potentially reveal a CPF is, when the attack involves the
generation of fake users. Me, I would say that if your site allows the
creation of fake users, you have bigger problems.

Ewout


On Tue, Nov 12, 2013 at 12:27 AM, Caio Tiago Oliveira
<caiotiago at colivre.coop.br> wrote:
> -----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-----
> _______________________________________________
> Noosfero-dev mailing list
> Noosfero-dev at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-dev