Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #7180 > unrolled thread

Re: How good is security via hashing

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How good is security via hashing geremy condra <debatem1@gmail.com> - 2011-06-07 13:02 -0700
    Re: How good is security via hashing Paul Rubin <no.email@nospam.invalid> - 2011-06-07 13:42 -0700
      Re: How good is security via hashing Ian Kelly <ian.g.kelly@gmail.com> - 2011-06-07 14:58 -0600
      Re: How good is security via hashing geremy condra <debatem1@gmail.com> - 2011-06-07 14:41 -0700
      Re: How good is security via hashing Robin Becker <robin@reportlab.com> - 2011-06-08 10:13 +0100
        Re: How good is security via hashing Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-06-08 13:30 +0200

#7180 — Re: How good is security via hashing

On Tue, Jun 7, 2011 at 3:18 AM, Robin Becker <robin@reportlab.com> wrote:
> A python web process is producing files that are given randomized names of
> the form
>
> hhhhhh-YYYYMMDDhhmmss-rrrrrrrr.pdf
>
> where rrr.. is a 128bit random number (encoded as base62). The intent of the
> random part is to prevent recipients of one file from being able to guess
> the names of others.
>
> The process was originally a cgi script which meant each random number was
> produced thusly
>
>
> pid is process id, dur is 4 bytes from /dev/urandom.
>
> random.seed(long(time.time()*someprimeint)|(pid<<64)|(dur<<32))
> rrr = random.getrandbits(128)
>
>
> is this algorithm safe? Is it safe if the process is switched to fastcgi and
> the initialization is only carried out once and then say 50 rrr values are
> generated.

The advice you got about just using urandom seems to be the best
you're likely to get. Given how few values you have to pull out of
random.random to reconstruct its state, the progress that's been made
in the last few years on similar hidden state problems, and the
limited amount of entropy you're feeding it in the first place, I'd
probably stay away from this method. And besides,

# adds random junk to the filename- should make it hard to guess
rrr = os.urandom(16)
fname += base64.b64encode(rrr)

has to be easier to read and reason about than the process above.

Geremy Condra

[toc] | [next] | [standalone]

#7184

geremy condra <debatem1@gmail.com> writes:
> # adds random junk to the filename- should make it hard to guess
> rrr = os.urandom(16)
> fname += base64.b64encode(rrr)

Don't use b64 output in a filename -- it can have slashes in it!  :-(

Simplest is to use old fashioned hexadeimal for stuff like that, unless
the number of chars is a significant problem.  Go for a more complicated
encoding if you must.

[toc] | [prev] | [next] | [standalone]

#7186

On Tue, Jun 7, 2011 at 2:42 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> geremy condra <debatem1@gmail.com> writes:
>> # adds random junk to the filename- should make it hard to guess
>> rrr = os.urandom(16)
>> fname += base64.b64encode(rrr)
>
> Don't use b64 output in a filename -- it can have slashes in it!  :-(
>
> Simplest is to use old fashioned hexadeimal for stuff like that, unless
> the number of chars is a significant problem.  Go for a more complicated
> encoding if you must.

You can use base64.urlsafe_b64encode, or specify a custom altchars
argument that doesn't include '/'.

Definitely don't use base64 filenames on a case-insensitive
filesystem, though. :-)

[toc] | [prev] | [next] | [standalone]

#7189

On Tue, Jun 7, 2011 at 1:42 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> geremy condra <debatem1@gmail.com> writes:
>> # adds random junk to the filename- should make it hard to guess
>> rrr = os.urandom(16)
>> fname += base64.b64encode(rrr)
>
> Don't use b64 output in a filename -- it can have slashes in it!  :-(
>
> Simplest is to use old fashioned hexadeimal for stuff like that, unless
> the number of chars is a significant problem.  Go for a more complicated
> encoding if you must.

Eeesh, that completely slipped my mind. Thanks for pointing it out.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#7225

On 07/06/2011 21:42, Paul Rubin wrote:
> geremy condra<debatem1@gmail.com>  writes:
>> # adds random junk to the filename- should make it hard to guess
>> rrr = os.urandom(16)
>> fname += base64.b64encode(rrr)
>
> Don't use b64 output in a filename -- it can have slashes in it!  :-(
>
> Simplest is to use old fashioned hexadeimal for stuff like that, unless
> the number of chars is a significant problem.  Go for a more complicated
> encoding if you must.
we have been using base62 ie 0-9A-Za-z just to reduce the name length.
-- 
Robin Becker

[toc] | [prev] | [next] | [standalone]

#7228

Am 08.06.2011 11:13 schrieb Robin Becker:

> we have been using base62 ie 0-9A-Za-z just to reduce the name length.

Ugly concerning calculation. Then maybe better use radix32 - 0..9a..v, 
case-insensitive.


Thomas

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web