#9687: Use more randomness in secret key generation
-----------------------------------------+----------------------------------
          Reporter:  [EMAIL PROTECTED]  |         Owner:  nobody           
            Status:  closed              |     Milestone:                   
         Component:  Core framework      |       Version:  1.0              
        Resolution:  wontfix             |      Keywords:  SECRET_KEY random
             Stage:  Unreviewed          |     Has_patch:  0                
        Needs_docs:  0                   |   Needs_tests:  0                
Needs_better_patch:  0                   |  
-----------------------------------------+----------------------------------
Changes (by mtredinnick):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => wontfix
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 You don't explain what the "design accident" might be. If you are
 referring to the particular choice of characters, that is hardly an
 accident.

 The question isn't whether the string is as random as possible (your
 alternative doesn't meet that requirement either), it's whether it's
 sufficiently random as to be effectively unguessable. The current code has
 50**50 different strings (around 10**85) that are possible and the choices
 are statistically uniformly distributed over that space. Your are
 proposing to extend the range of characters, but that doesn't change much.
 Since the chance of guessing the secret key string for a particular site
 is already unlikely (a billion guesses per second will take 10**68 years),
 the key weakness is the PRNG being used to gerneated the choices and that
 security isn't improved by increased the range of characters (if you can
 accurately determine the state at the start of the string, you can still
 determine the whole string, regardless of the number of characters used).


 At some point here, we just have to make a choice. Why not use more
 characters than your range? Why not switch to 150 characters in the
 secret, etc?

 If you want to use a longer secret key in your projects, that's certainly
 going to be possible, since it's just a string and you can create it
 however you like. The one that Django generates isn't inherently insecure,
 though.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/9687#comment:1>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to