[Python-Dev] Hash collision security issue (now public)

Hynek Schlawack hs at ox.cx
Thu Dec 29 14:11:49 CET 2011


Hi,  

how about

Option d: Host based salt
 + Easy-ish to implement – how about basing it on the hostname for example?
 + transparent for all processes on the same host
 - probably unit test breakage

In fact, we could use host based as default with the option to specify own which would solve the sync problems.

That said, I agree with Armin that fixing this in the frameworks isn't an option.

Regards,
Hynek


Am Donnerstag, 29. Dezember 2011 um 13:57 schrieb Armin Ronacher:

> Hi,
>  
> Something I should add to this now that I thought about it a bit more:
>  
> Assuming this should be fixed on a language level the solution would
> probably be to salt hashes. The most common hash to salt here is the
> PyUnicode hash for obvious reasons.
>  
> - Option a: Compiled in Salt
> + Easy to implement
> - Breaks unittests most likely (those were broken in the first place
> but that's still a very annoying change to make)
> - Might cause problems with interoperability of Pythons compiled with
> different hash salts
> - You're not really solving the problem because each linux
> distribution (besides Gentoo I guess) would have just one salt
> compiled in and that would be popular enough to have the same
> issue.
>  
> - Option b: Environment variable for the salt
> + Easy-ish to implement
> + Easy to synchronize over different machines
> - initialization for base types happens early and unpredictive which
> makes it hard for embedded Python interpreters (think mod_wsgi and
> other things) to specify the salt
>  
> - Option c: Random salt at runtime
> + Easy to implement
> - impossible to synchronize
> - breaks unittests in the same way as a compiled in salt would do
>  
> Where to add the salt to? Unicode strings and bytestrings (byte
> objects) I guess since those are the most common offenders. Sometimes
> tuples are keys of dictionaries but in that case a contributing factor
> to the hash is the string in the tuple anyways.
>  
> Also related: since this is a security related issue, would this be
> something that goes into Python 2? Does that affect how a fix would
> look like?
>  
>  
> Regards,
> Armin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org (mailto:Python-Dev at python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/hs%40ox.cx





More information about the Python-Dev mailing list