Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)

Sun Jan 20 19:51:13 UTC 2013

On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote:
> On Jan 18, 2013, at 7:52 PM, Matt Palmer <mpalmer at hezmatt.org> wrote:
> > On Fri, Jan 18, 2013 at 09:41:41AM +0100,  . wrote:
> >> On 17 January 2013 23:38, Matt Palmer <mpalmer at hezmatt.org> wrote:
> >> ..
> >>> By the way, if anyone *does* know of a good and reliable way to prevent CSRF
> >>> without the need for any cookies or persistent server-side session state,
> >>> I'd love to know how.  Ten minutes with Google hasn't provided any useful
> >>> information.
> >> 
> >> I think many people create <forms> with a secret code that is
> >> different and hopefully can't be predicted by the attackers.
> >> 
> >> <form method="post">
> >> <input type="hidden" name="id_user" value="33">
> >> <input type="hidden" name="action" value="delete_user">
> >> <input type="hidden" name="secret" value="5ebe2294ecd0e0f08eab7690d2a6ee69">
> >> <input type="submit" value="Delete user">
> >> </from>
> >> 
> >> The easy way to do this is to generate secret from the md5 if time in
> >> miliseconds + a salt string, and store the secret generated
> >> serverside.
> > 
> > Storing any state server-side is a really bad idea for scalability and
> > reliability.
> 
> ?
> 
> Doing that - into a user state DB of sone sort, either external or in
> middleware, is routine...

It may be routine, but it is an additional point of failure, and it is also
an additional scaling bottleneck.  If all you ever run are tiny sites with
little chance of ever seeing big loads, sure, stick it in a DB somewhere. 
But if you ever think (or even hope) that your site will take off one day,
it pays to think about these things and reduce the number of fires to put
out by one.

- Matt