Current hash randomness isn't strong enough

[GoogleCodeExporter]

What steps will reproduce the problem?
I recently deployed 0.1.4 on a site that was getting a lot of spam
attempts. While testing, everything went through fine but in production, I
started noticing a lot of these in the server logs:

2010-02-01 20:30:54 UTC ERROR:  duplicate key value violates unique
constraint "captcha_captchastore_hashkey_key"
2010-02-01 20:30:54 UTC STATEMENT:  INSERT INTO "captcha_captchastore"
("challenge", "response", "hashkey", "expiration") VALUES (E'RMFM',
E'rmfm', E'15ae3c39233a53286d882a80f5442d7bce382196', E'2010-02-01
14:35:54.113022')

Please provide any additional information below.
In looking at the code, I couldn't figure out why this would happen. Then I
started to remember a long thread in django about session key issues. See
this ticket for the gory details:
http://code.djangoproject.com/ticket/1180

Basically, part of the problem with using str(random.random()) is that it
is seeded when the fastcgi script respawns so it's quite possible under
heavy loads to get the same hashkey. Which seems to be the case with my
situation.

So, if you look how Django generates the session key -
http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backe
nds/base.py#L131

You'll need something like that to truly make the hash key more robust.

I have submitted a patch based on the django code. This should be much more
robust.

Original issue reported on code.google.com by chris.mo...@gmail.com on 2 Feb 2010 at 4:06

Attachments:

• increased_random.diff

[GoogleCodeExporter]

Chris, thank you: great bug report and excellent patch.

This is fixed as of r46 and version 0.1.5

Original comment by mbonetti on 2 Feb 2010 at 11:16

• Changed state: Fixed