[159747] in North American Network Operators' Group
Re: Suggestions for the future on your web site: (was cookies,
daemon@ATHENA.MIT.EDU (George Herbert)
Sat Jan 19 18:54:52 2013
In-Reply-To: <20130119035228.GG31028@hezmatt.org>
From: George Herbert <george.herbert@gmail.com>
Date: Sat, 19 Jan 2013 15:54:37 -0800
To: Matt Palmer <mpalmer@hezmatt.org>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 18, 2013, at 7:52 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
> On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:
>> On 17 January 2013 23:38, Matt Palmer <mpalmer@hezmatt.org> wrote:
>> ..
>>> By the way, if anyone *does* know of a good and reliable way to prevent C=
SRF
>>> 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 usefu=
l
>>> information.
>>=20
>> I think many people create <forms> with a secret code that is
>> different and hopefully can't be predicted by the attackers.
>>=20
>> <form method=3D"post">
>> <input type=3D"hidden" name=3D"id_user" value=3D"33">
>> <input type=3D"hidden" name=3D"action" value=3D"delete_user">
>> <input type=3D"hidden" name=3D"secret" value=3D"5ebe2294ecd0e0f08eab7690d=
2a6ee69">
>> <input type=3D"submit" value=3D"Delete user">
>> </from>
>>=20
>> 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.
>=20
> 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 middle=
ware, is routine...
George William Herbert
Sent from my iPhone=
