-
Notifications
You must be signed in to change notification settings - Fork 238
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
Comments
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. |
(a) in http://shiflett.org/articles/cross-site-request-forgeries, the author uses md5 in his example. Hope this helps. |
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.
On Saturday, April 20, 2013 at 7:01 PM, Ciaro Vermeire wrote:
|
@nateabele Where you able to talk to Chris about this yet? Thanks. |
@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: Also see:
|
Refs 60bbe47 |
@DavidPersson I don't see why plain md5 shouldn't work for CSRF? |
@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. |
@DavidPersson I was suggesting to bypass 'php::crypt' completely for the CSRF tokens and just use plain md5 for those. |
Can we use hmac?
|
Fixed. |
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.
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
The text was updated successfully, but these errors were encountered: