Reduce overhead in Form Signing#839

Labels

Milestone

Assignee

4 participants

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?

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

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.

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.

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.

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.
Adding changelog entries.

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.
Adding changelog entries.

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.
Adding changelog entries.