Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce overhead in Form Signing #839

Closed
Ciaro opened this issue Feb 27, 2013 · 11 comments
Closed

Reduce overhead in Form Signing #839

Ciaro opened this issue Feb 27, 2013 · 11 comments
Assignees
Milestone

Comments

@Ciaro
Copy link
Contributor

Ciaro commented Feb 27, 2013

Hello guys

The current implementation of CSRF protection in Lithium seems to have a lot of unneeded overhead. It uses sha512 by default, but even if you define md5 as a type, you are still getting tokens generated by 'php::crypt'. This can add up if you use a couple of forms one a page.

Could we not accomplish the same functionality by just using plain-old md5 tokens?

Please do correct me if I'm wrong about this :)

Best regards,

Ciaro

@nateabele
Copy link
Member

I would need to do more research into (a) what the real hashing needs are for CSRF tokens, and (b) the overall time difference of each hashing function.

If someone wants to help with a breakdown of these, that would be great.

@Ciaro
Copy link
Contributor Author

Ciaro commented Apr 20, 2013

(a) in http://shiflett.org/articles/cross-site-request-forgeries, the author uses md5 in his example.
(b) on a default nginx setup (dev and production) it's between 50ms and 100ms per token generated by 'php::crypt'. Using password::hash with an md5 salt is 16ms for the first, then around 7-8 for anything after it, so acceptable?

Hope this helps.

@nateabele
Copy link
Member

Thanks for mentioning that link. It's pretty old, so it's possible that the information is outdated, but I'll ask Chris about it the next time I talk to him.

  • Nate

On Saturday, April 20, 2013 at 7:01 PM, Ciaro Vermeire wrote:

(a) in http://shiflett.org/articles/cross-site-request-forgeries, the author uses md5 in his example.
(b) on a default nginx setup (dev and production) it's between 50ms and 100ms per token generated by 'php::crypt'. Using password::hash with an md5 salt is 16ms for the first, then around 7-8 for anything after it, so acceptable?

Hope this helps.


Reply to this email directly or view it on GitHub (#839 (comment)).

@Ciaro
Copy link
Contributor Author

Ciaro commented Dec 17, 2013

@nateabele Where you able to talk to Chris about this yet? Thanks.

@mariuswilms
Copy link
Member

@Ciaro I think the performance problem is not coming from using sha512 for the request token but from using blowfish for the form signing in:
https://github.com/UnionOfRAD/lithium/blob/master/security/validation/FormSignature.php#L39

Also see:
http://php.net/manual/en/function.crypt.php

$2a$10$ is blowfish with 10 rounds and $6$ would be sha512. The question now is if we really need BF which is meant to be slow?

@mariuswilms
Copy link
Member

Refs 60bbe47

@Ciaro
Copy link
Contributor Author

Ciaro commented Dec 20, 2013

@DavidPersson I don't see why plain md5 shouldn't work for CSRF?

@mariuswilms
Copy link
Member

@Ciaro I'd say the tiny performance improvement switching sha512 to md5 isn't worth what we eventually lose in security. Also as I mentioned the real problem here is the usage of blowfish.

@Ciaro
Copy link
Contributor Author

Ciaro commented Dec 21, 2013

@DavidPersson I was suggesting to bypass 'php::crypt' completely for the CSRF tokens and just use plain md5 for those.

@gwoo
Copy link
Contributor

gwoo commented Dec 22, 2013

Can we use hmac?

On Dec 21, 2013, at 8:35 AM, Ciaro Vermeire notifications@github.com wrote:

@DavidPersson I was suggesting to bypass 'php::crypt' completely for the CSRF tokens and just use plain md5 for those.


Reply to this email directly or view it on GitHub.

@mariuswilms mariuswilms added this to the 1.0 milestone Sep 29, 2014
@mariuswilms mariuswilms changed the title Reduce overhead in CSRF protection Reduce overhead in Form Signing Oct 5, 2014
@mariuswilms mariuswilms self-assigned this Mar 14, 2015
@nateabele
Copy link
Member

Fixed.

mariuswilms added a commit that referenced this issue Mar 31, 2015
The calculation logic now uses HMAC which requires a secret key. Such
a unique key must be set in userland before starting to use form
signature generation or verification.

The new logic is basically modelled after message signatures and its
purpose is to ensure integrity of the compiled form signature string.

Adding test to prove overflowing is prevented.
mariuswilms added a commit that referenced this issue Mar 31, 2015
Changing form signature calculation logic. Fixes #839, #998. BC-break.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants