It was actually fixed in Python 3.4 with the switch to use SipHash, as the randomization introduced in Python 3.3 was still susceptible to some attacks. See https://www.python.org/dev/peps/pep-0456/
Still not secure if you can read out the seed. Brute forcing SipHash collisions with the known seed is also just a matter of seconds to minutes.
http://perl11.org/blog/seed.html
A proper security fix can only be to fix the collision resolution, never using a slower hash function. It's also 10x faster then.
With dynamic languages like python it's trivial. Calculate the position and peek it.
With static languages it's still easy when you got enough information: source code, timing info and ordering (e. g JSON). With a proper SAT solver doable.
Leaking by accident is e.g even more trivial in perl, just set a magic ENV var. But peeking the fixed offset is easiest.
It's all just security theatre. There's no real use-case for something so slow as Siphash.
Do you often give DoS threats arbitrary code execution or the ability to set environment variables? Because there’s no need to bother with hash collisions to DoS yourself.
while True: pass
As for finding the seed with a SAT solver: no, not doable. Not from actual hashes, let alone timing and order hints at actual hashes.
Only for hash tables which use all bits. (e.g. prime sized).
Almost nobody does. For normal power-of-2 hash tables finding collisions in the lowest bits leading to a successful amplification is trivial by brute-force. Since Siphash is so slow it can last up to 4 minutes, for smaller tables still < 5s.
A proper security fix can only be to fix the collision resolution, never using a slower hash function. It's also 10x faster then.