I agree we shoud have this as an option.All we need is to add an
option to session.connect(...) Users can decide.
On 1 Ago, 03:07, Thadeus Burgess wrote:
> IP addresses can be faked... well anything sent to the server can be
> spoofed. It is much easier to hijack a session token and steal the
> u
IP addresses can be faked... well anything sent to the server can be
spoofed. It is much easier to hijack a session token and steal the
users login than it is to crack a signed cookie.
I agree we need both methods in web2py, with the ability to specify
which method we want.
--
Thadeus
On Sat
True, the PCI-DSS mandates things like that, such as tokenizing credit
cards and only passing the tokens, using a centralized secure database
to store the data, etc. WRT the site cookie, you'd have access to
what that user has been authorized to see, sure. There are other
standard-practice method
@Scott, I think your argument is based on assuming a bad programming
design. If you have any type of data that needs to be secure to that
detail, I hope to god your not storing them in the session in the
first place! I mean, if I somehow copy your sites cookie from a user,
I now have access to the
On Jul 31, 2010, at 5:09 PM, Scott wrote:
> In essence your argument is that it would take too much time and you
> could change the hmac key monthly to prevent an attack. I understand
> and respect that signed cookies are one way to solve the problem, but
> I do not believe they are the "most cor
In essence your argument is that it would take too much time and you
could change the hmac key monthly to prevent an attack. I understand
and respect that signed cookies are one way to solve the problem, but
I do not believe they are the "most correct" way.
My analogy would be the difference betw
To crack a signed cookie you need the secret hmac key that is usually
stored within the application. Brute forcing an hmac key will take
more time than any hacker has, especially if you change it once a
month or so.
--
Thadeus
On Sat, Jul 31, 2010 at 1:00 PM, Armin Ronacher
wrote:
> That is
That is incorrect. That is indeed true for a regular cookie, bit that
has all kimds of problems. I was referring to actual signed cookies.
On Jul 31, 9:56 am, mdipierro wrote:
> There is a difference.
>
> If you have a uuid sessions cookie and a serverside session and an
> attacker hijacks the co
There is a difference.
If you have a uuid sessions cookie and a serverside session and an
attacker hijacks the cookie, he can only get access to the account of
the compromised user.
If the session is stored client side and the attackers hijacks the
cookie, he can tamper with the data in the sessi
Hi,
On Jul 31, 2:38 am, Scott wrote:
> I do not agree with item 1. Session data should never be stored
> client-side as it opens a rather large attack vector.
Which attack vector exists for signed cookies with a signed timeout
compared to just session IDs in cookies? Both can be hijacked by a ma
I do not agree with item 1. Session data should never be stored
client-side as it opens a rather large attack vector. The only thing
which should be stored client-side is the session token in a secure,
HTTPOnly cookie (which web2py currently supports). If cookies are
disabled, a hidden POST fiel
3) black magic IMHO. Would be nice to have some well defined path for the
programmer to work on this, so
that it could be seen as a separate layer for db configuration/tuning so
that models can be left almost untouched
on architectural changes.
2010/7/29 mdipierro
> The speaker raises s
The speaker raises some good issue with Django and some do apply to
web2py
Aside for the many jokes which are indeed funny he complains about
scalability and make these valid points:
1) session should be stored client side for scalability (web2py and
Django both store them server side, although i
Django (the opposite of RoR) sucks likes RoR (the Denmark salesman vs
the desparate Kanzas Python programmers ambitions to create everything
out of nothing).
Probably you know what's the definition of the Nobel winners for
intellect - adequacy.
And in order to achieve adequacy we need compromises
14 matches
Mail list logo