[Owasp-leaders] CSRF Password Change Function

Rogan Dawes rogan at dawes.za.net
Fri Mar 17 10:07:12 UTC 2017


Let's put it this way:

Having a CSRF token on the password change form would be "best practice",
as it ensures that an attacker cannot convince you to try change your
password while you are logged in, even if they do have to brute force your
current password in the process.

Note that any rate limiting implemented here would impact the legitimate
user, not the attacker! By this I mean, yes, the attacker would be slowed
down, but the actual user might be the one impacted, if the slow down
applies to more than just the password change function!

It would also not be unusual (at least, not surprising) to see rate
limiting implemented on the login page only, and not the password change
form, on the assumption that the password change form is only accessible to
authenticated users, and thus rate limiting is not required.

So, while in theory, the password itself IS a CSRF token, in that it is
something that the attacker does not know, it is entirely possible that the
password is easier to brute force than the CSRF tokens in other instances.
And this fact makes it weaker than a traditional CSRF token would be.

Thanks for the discussion, I have actually changed my position from "the
password is sufficient as a CSRF token", to "A purely random CSRF token is
still required".

Rogan

On Fri, Mar 17, 2017 at 11:46 AM Martin Knobloch <martin.knobloch at owasp.org>
wrote:

> All,
>
> I totally agree with Steven! Do not abuse the password for what it is not
> meant for!
> Why should you (ab-)use the password?
>
> Your CSRF token should be user and session specific!
> See the Cheat sheet information on CSRF:
> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
>
> Kind regards,
> -martin
>
>
> On Fri, Mar 17, 2017 at 10:23 AM, Steven van der Baan <
> steven.van.der.baan at owasp.org> wrote:
>
> Hi all,
>
> I disagree that you can use the current password as anti CSRF token.
> And here is why
> I see the anti CSRF token as assurance that it's really the user
> interacting with the application and not some script. An attacker can
> easily  go through the whole rockyou dictionary and uses all entries as
> current password to reset it to a known value. There will always be
> users that fall victim to this as they use insecure passwords.
>
> Just my £0.02
>
> Steven.
>
> On 17/03/17 07:49, Minhaz A V wrote:
> > Yes, current password can be used as anti CSRF Token, actually if there
> > old password is needed for changing password there is no need for anti
> > CSRF logic there, as it's much like login and cookies doesn't play much
> > role except for username. However if you were to use anti CSRF method
> > everywhere (let's say on POST request) you'd go for homogeneous method.
> >
> >
> ----------------------------------------------------------------------------
> > Kind Regards,
> > Minhaz
> > minhazav.xyz <http://minhazav.xyz> | Blog <http://blog.minhazav.xyz>
> > |Projects <http://github.com/mebjas> | LinkedIn
> > <https://in.linkedin.com/in/minhazav>
> >
> > On Fri, Mar 17, 2017 at 7:15 AM, Ralph Durkee <rd at rd1.net
> > <mailto:rd at rd1.net>> wrote:
> >
> >     I agree that requiring the current password is sufficient for
> >     anti-CSRF. If the attacker could provide the current password, then
> >     there would be no need for the attack.  Was there logic provided as
> >     to why the current password would not be sufficient?
> >
> >     -- Ralph Durkee, CISSP, GXPN, GPEN, GCIH, GSEC, GSNA, GCIA, C|EH
> >     Principal Security Consultant
> >
> >
> >     On 03/16/2017 09:24 PM, Carlos Sagrero wrote:
> >>     Hello, a few hours ago I had a discussion with several of my
> >>     co-workers (all of them are Application Security consultant) about
> >>     whether in a password change function is valid to consider the
> >>     current password as a anti-CSRF control.
> >>
> >>     There is an interesting point that was the main discussion point,
> >>     at the end the current password is not a control to avoid CSRF.
> >>
> >>     What do you think about it? It is required to have a specific
> >>     control to CSRF?
> >>
> >>     Best regards.
> >>
> >>     --
> >>
> >>     *Carlos Isaac Sagrero Campos*
> >>
> >>     *OWASP Mexico City*
> >>
> >>     Inline image 1
> >>
> >>
> >>     <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> >>      Libre de virus. www.avast.com
> >>     <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> >>
> >>
> >>
> >>
> >>     _______________________________________________
> >>     OWASP-Leaders mailing list
> >>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org
> >
> >>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >>     <https://lists.owasp.org/mailman/listinfo/owasp-leaders>
> >
> >
> >     _______________________________________________
> >     OWASP-Leaders mailing list
> >     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
> >     https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >     <https://lists.owasp.org/mailman/listinfo/owasp-leaders>
> >
> >
> >
> >
> > _______________________________________________
> > OWASP-Leaders mailing list
> > OWASP-Leaders at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
> >
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20170317/8ea9a69e/attachment-0001.html>


More information about the OWASP-Leaders mailing list