Hi Anthony, On Fri, Aug 23, 2013 at 11:12 PM, Anthony Ferrara <ircmax...@gmail.com>wrote:
> > It's absolutely not wise to use it for anything security related, the >> > purpose of the function is simply to provide a unique value within a >> > system, not a random value, not an unpredictable value. >> > >> >> I agree. >> >> However, I suppose there are many applications that rely on uniqid() for >> critical features like payment or authentication. >> > > Sure, and people use `eval()` for conditionals and `goto` for code > structure. > > We shouldn't alter language design for people making bad decisions. > Instead, we should work on documentation and education to fix those kinds > of problems. > We definitely should do this. I agree. > > >> We need better function as basic feature of PHP. unique_hash() or >> hash_unique() might be good. UUID works and is much better but generating >> unique hash just like session ID is trivial to implement. >> > > What would this do? How would it work? Would it just be a statistically > unique hash? At which point why have it named on `hash` instead of just > being a large random number (and hence belongs as a random number > generator, not a unique hash thingy)... > Right. It would be statistically unique hash just like session ID without strict session mode. (Strict session detects collision, so it ensures uniqueness) Current session module uses /dev/urandom (or like in UNIX like environment) or crypt library for windows. We have been relied statistically unique session ID until now, since it's not too bad. hash_unique() would be much safer than uniqid(). We should still educate users that values are statistically unique values. Unlike session, collision detection is up to users since it's impossible to maintain generated hash values. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
