On 3/15/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> The point is: It's not possible to extend the session in a
> upwards-compatible way, because there's no way to make sure
> that INSERT is used when you need to set the pk before save().
Again, I'm not disagreeing with the INSERT/UPDATE sugg
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Do we really need to re-seed the RNG? What if we did something like:
> session_key = md5.new("%x%s%s" % (random.getrandbits(64),
> datetime.datetime.utcnow(), settings.SECRET_KEY)).hexdigest()
That works too :)
I'm just wanting anything w
On Thu, 2007-03-15 at 03:09 -0700, ak wrote:
> Malcolm, ofcourse I can rewrite it as a patch to current session
> module but I think you should understand that anyone who will do svn
> update would get broken session module because of extra field in
> django_session table.
> If it is ok, please an
I only get digest messages from this group, so I've responded to
several messages inline. Apologies in advance if this breaks
threading.
James Bennett said:
> On 3/13/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> > a) the client can sit behind a NAT that might hand out different IPs
> > b) t
On 3/14/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> What I don't understand is: Why the developers don't do the correct
> thing by providing separate insert() and update() in addition to
> save() ? All it requires is a trivial refactoring and actually
> simplifies the code (also clarifying the i
> Because doing so would introduce some backward incompatibilities.
Thats not true, if you provide a save()-method that calls either
update() or insert(). save() should not be removed, it makes many things
very easy. So only additional flexibility is added without removing or
changing any inter
On Wed, 14 Mar 2007 20:34:11 -0500, Arvind Singh <[EMAIL PROTECTED]>
wrote:
>
>> 1. Manually seeding the RNG with a value unique to the server process,
>> or to the request, would move the probability of key collision closer
>> to what it "should" be, thus dramatically reducing the problem.
>
>
> One reason it isn't there is because many of the use cases that require
> differentiating between updating and creating a new object can already
> be implemented without extra code. Requiring an application developer to
> always specify update or create anew when it can usually be inferred
> jus
On Thu, Mar 15, ak wrote:
>
> Malcolm, ofcourse I can rewrite it as a patch to current session
> module but I think you should understand that anyone who will do svn
> update would get broken session module because of extra field in
> django_session table.
> If it is ok, please answer and I will
Malcolm, ofcourse I can rewrite it as a patch to current session
module but I think you should understand that anyone who will do svn
update would get broken session module because of extra field in
django_session table.
If it is ok, please answer and I will prepare patch in an hour
(without ip ch
On Wed, 2007-03-14 at 22:44 -0700, ak wrote:
> Guys
> The only thing I don't understand at the moment is: everyone
> understands that current implementation of ORM together with current
> implementation of sessions table doesn't allow to force insert and
> throw exception if it fails. So I can sta
Guys
The only thing I don't understand at the moment is: everyone
understands that current implementation of ORM together with current
implementation of sessions table doesn't allow to force insert and
throw exception if it fails. So I can state this as a special case.
Every framework has limitati
On Thu, 2007-03-15 at 07:04 +0530, Arvind Singh wrote:
[...]
> What I don't understand is: Why the developers don't do the correct
> thing by providing separate insert() and update() in addition to
> save() ? All it requires is a trivial refactoring and actually
> simplifies the code (also clarify
On 3/14/07, James Bennett <[EMAIL PROTECTED]> wrote:
> 1. Manually seeding the RNG with a value unique to the server process,
> or to the request, would move the probability of key collision closer
> to what it "should" be, thus dramatically reducing the problem.
Do we really need to re-seed the
Malcolm Tredinnick wrote:
> It's a discussion worth having in a clam manner in another thread.
Did anyone else picture mollusks having a conversation when they read
that? ;-)
--
Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
> 1. Manually seeding the RNG with a value unique to the server process,
> or to the request, would move the probability of key collision closer
> to what it "should" be, thus dramatically reducing the problem.
Problem is reduced... but still remains.
> 2. Changing the session framework's behavi
On 3/14/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> If you have multiple processes which initialize their random
> module at exactly the same system time (how granular is it?, you'll get the
> same seed and therefore the same sequence of pseudorandom numbers in
> python2.3
>
> In python2.4, t
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> 2) James has suggested that the answer is, perhaps, better seeding. I
> really don't think that this is an issue. Regardless of the seed,
> there is still a mathematical chance that a collision will occur.
This is true, but given the rang
ak wrote:
> Ivan, although reseeding still not guarantees that there may be no
> duplicates as INSERTing does, isn't it ?
Yeah... I actually don't object to your approach at all, I'm just
guessing why random numbers could become... uhm... not that random.
--~--~-~--~~~--
Man, there's been a lot of movement in this thread.
I'd like to just throw out a few comments.
1) The current session framework unquestionably needs some attention.
The way in which sessions are being generated isn't terribly
efficient, and can certainly lead to collisions.
2) James has sugge
On Wed, Mar 14, Ivan Sagalaev wrote:
>
> Michael Radziej wrote:
> > Beginning with python2.4, the seed also uses os.urandom() when available, so
> > it starts to get safer.
>
> Uhm... But it still happens only once on first module import. So it's
> not safer at all.
If you have multiple proce
Ivan, although reseeding still not guarantees that there may be no
duplicates as INSERTing does, isn't it ?
And insert needs to be done only once at session start and is
performed ANYWAY at session start. The difference in my way is that
insert is done when new session is created and in django's w
Michael Radziej wrote:
> Beginning with python2.4, the seed also uses os.urandom() when available, so
> it starts to get safer.
Uhm... But it still happens only once on first module import. So it's
not safer at all.
> I'm not sure whether it's a good idea to add periodic reseeding.
Why not? I
Henrique Ser, you lost the fact that we are using lighttpd, not
apache, but our django works as preforked fastcgi.
I can only say that i will NEVER use a potentially vulnerable session
implementation where any not logged in user may get superuser's
permission, even if a chance for this to happen a
As I said, we restart our django fastcgi server a few times per a day.
I think it is more related to:
> Beginning with python2.4, the seed also uses os.urandom() when available, so
> it starts to get safer.
and our app runs under xen domU debian installation so may be there's
something related
Hello all,
I am quite new at django and I've been trying to get all the info I can
by, amongst other means, reading through django-dev and django-users. I
don't remember in which I read this but fastcgi, the way it is designed,
doesn't work well with threads. The actual details escape me but I
> 2. I have an ethernet connection @home and I sometimes log in to our
> private web apps from home. Any 'c00l hacker' is able to scan network
> traffic, get my session id and use it to join to my session too just
> because there is absolutely no checking who uses session. We added ip
> checking
On Wed, Mar 14, Ivan Sagalaev wrote:
> I've just recalled a case... I was using Django's randomly generated
> passwords and it worked fine under mod_python. Then I switched to
> FastCGI and from some moment *all* passwords started being generated
> absolutely equal. The thing was that mod_pyth
Btw, we use Debian with python 2.4 too
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this grou
Michael Radziej wrote:
> But something else must go wrong in your case, as the chance to get the
> same session ids should be so tiny that you really shouldn't reports
> from your users. Comments say that the random number generator is
> seeded when the server process starts, and it's seeded with
Michael, I really don't know how would it be possible, I only know the
following:
1. My production web server restarts a few times per day. Sometimes
twice (in a really short period ie 2-3 minutes)
2. I got a report from _new_ user that he received e-mail with login
and pass, clicked to link and b
Hi Anton,
ak schrieb:
>> so it doesn't get us any real improvement in security
>
> James, there is a concept of 'fool proof'. Real hackers may do many
> things. But current model allows even 10 year old kids to be hackers.
> This is just against them. There is no ability to protect all sites
> w
Default django installation uses session lifetime equal to 2 weeks
with no session expiration at browser close. Just calculate what
should be a default strength of session id generator to successfully
generate unique IDs within 2 weeks for a web app with 1 000 000 unique
visitors per a day. As far
> so it doesn't get us any real improvement in security
James, there is a concept of 'fool proof'. Real hackers may do many
things. But current model allows even 10 year old kids to be hackers.
This is just against them. There is no ability to protect all sites
with ssl and I would not like a nei
On 3/14/07, ak <[EMAIL PROTECTED]> wrote:
> 2. I have an ethernet connection @home and I sometimes log in to our
> private web apps from home. Any 'c00l hacker' is able to scan network
> traffic, get my session id and use it to join to my session too just
> because there is absolutely no checking
> I'm still wary of this -- again, it doesn't do anything to prevent
> man-in-the-middle, and it introduces complexity and -- if we're
> worried about session collisions -- introduces a whole new class of
> bugs when you have a bunch of people behind a NAT or firewall who all,
> from the POV of yo
On 3/13/07, ak <[EMAIL PROTECTED]> wrote:
> 1. REMOTE_IP. I think it is a good idea to check it. Load balancers
> acts as proxy servers. Every web server has a module that allow to
> restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is
> called mod_rpaf. And ofcourse it's very ea
Even more on remote ip checking: it can be done in a flexible way when
user is able to set either don't ever use it, check remote ip, check
user agent name or ever both remote ip and user agent for paranoids :)
I think everyone understands that it's about 2-3 more lines of code.
--~--~-~
Guys I would like to explain some things and decisions in my code.
1. REMOTE_IP. I think it is a good idea to check it. Load balancers
acts as proxy servers. Every web server has a module that allow to
restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is
called mod_rpaf. And ofc
On 3/13/07, Simon G. <[EMAIL PROTECTED]> wrote:
> There's also no reason for a
> "normal" user to change UA strings without needing to login again.
UA strings change on every minor rev of some browsers, plus various
tool versions (.net, etc.). Having those users logged out would suck
for my purp
I get this right the newsession-patch is trying to do so, but will
fail, beuase s.save() (django/contrib/newsessions/models.py, line 29)
will overwrite (SQL UPDATE) existing sessions instead of failing
creating it.
One tiny advantage remains: There is less code (=time) between
calculation the session k
I actually passed this onto the security mailing address, as I thought
it was better to be safe than sorry. Adrian's response was that tying
things to the IP address is not a good idea (for the reasons that
others have stated in this thread).
One thing that I would like to suggest is that we do l
On 3/13/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> a) the client can sit behind a NAT that might hand out different IPs
> b) the server can be behind NAT and not see the true IP at all. It
>might see different IPs for the same client over time.
> c) a crazy load balancer might get in the
Hi,
as far as I see, newsessions checks REMOTE_IP. Is this a good idea?
a) the client can sit behind a NAT that might hand out different IPs
b) the server can be behind NAT and not see the true IP at all. It
might see different IPs for the same client over time.
c) a crazy load balancer
On 3/13/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Anton Khalikov opened a new ticket pointing out a hole in the current
> session framework which can cause session id collisions.
The proposed solution for collision (more on that in a moment) seems
good -- the bug seems to happen solely because
Anton Khalikov opened a new ticket pointing out a hole in the current
session framework which can cause session id collisions.
He's put together a newsessions package which could be good, but
obviously needs some discussion (here). So, discuss away!
http://code.djangoproject.com/ticket
46 matches
Mail list logo
