Hi, I'm not really convinced that mktemp() should be made "more secure". To be clear: mktemp() is vulnerable by design. It's not a matter of entropy. You can watch the /tmp directory using inotify and "discover" immediately the "secret" filename, it doesn't depend on the amount of entropy used to generate the filename. A function is either unsafe or secure.
Why mktemp() only uses 8 characters? Well, I guess that humans like to be able to copy manually (type) a filename :-) Note: For the ones who didn't notice, "mktemp()" name comes from a function with the same name in the libc. http://man7.org/linux/man-pages/man3/mktemp.3.html Victor Le mer. 20 mars 2019 à 12:29, Anders Munch <a...@flonidan.dk> a écrit : > > Nathaniel J. Smith: > > Historically, mktemp variants have caused *tons* of serious security > > vulnerabilities. It's not a theoretical issue. > > All the more reason to have a standard library function that gets it right. > > > The choice of ENTROPY_BYTES is an interesting question. 16 (= 128 bits) > > would > > be a nice "obviously safe" number, and gives 22-byte filenames. We might be > > able to get away with fewer, if we had a plausible cost model for the > > attack. This is another point where a security specialist might be helpful > > :-). > > I'm not a security specialist but I play one on TV. > Here's my take on it. > > Any kind of brute force attack will require at least one syscall per try, to > create a file or check if a file by a given name exists. It's a safe > assumption > that names have to be tried individually, because if the attacker has a faster > way of enumerating existing file names, then the entropy of the filename is > worthless anyway. > > That means even with only 41 bits of entry, the attacker will have make 2^40 > tries on average. For an individual short-lived file, that could be enough; > even with a billion syscalls per second, that's over a thousand seconds, > leaving > plenty of time to initiate whatever writes the file. > > However, there could be applications where the window of attack is very long, > hours or days even, or that are constantly writing new temporary files, and > where the attacker can keep trying at a rapid pace, and then 41 bits is > definitely not secure. > > 128 bits seems like overkill: There's no birthday attack because no-one keeps > 2^(ENTROPY_BITS/2) files around, and the attack is running on the attackee's > system, so there's no using specialised accelerator hardware. I'd say 64 bits > is enough under those circumstances, but I wouldn't be surprised if a better > security specialist could make a case for more. So maybe go with 80 bits, > that's puts it at 15 or 16 characters. > > > Med venlig hilsen/Best regards > > Anders Munch > Chief Security Architect > > T: +45 76266981 * M: +45 51856626 > a...@flonidan.dk * www.flonidan.com > FLONIDAN A/S * Islandsvej 29 * DK-8700 Horsens * CVR: 89919916 > Winner of the 2018 Frost & Sullivan Customer Leadership Award > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
