SecureRandom cache_id generation

[t-tera]

As a security tester, I have seen developers who assume cache_id is unpredictable, but that's not actually true in the strict sense.

Would you be able to make it truly secure random?
The following is a quick but dirty fix for generate_cache_id method.

  def self.generate_cache_id
    [Time.now.utc.to_i,
      Process.pid,
      # ->  '%06d' % Process.pid + Integer('0x' + SecureRandom.hex).to_s,
      '%04d' % (CarrierWave::CacheCounter.increment % 1000),
      # ->  Do you mean % 10000? This bug increases collision probability.

Thanks.

[t-tera]

Thank you. But a number less than 10000 is considered predictable.

[mshibuya]

How much is enough?

[t-tera]

128bit is enough.

If fixed length is desirable, how about using the following?

'%032x' % SecureRandom.random_number(1 <<128) # 128bit hex

One thing to be noted here is that when I looked into the source code of carrierwave some months ago, I found some regexps in carrierwave that assumed the random number being consisted of 4 decimal digit and that's why I suggested a weird solution in the first post.

So, to make the part longer and use hex chars, some change might be necessary somewhere else.

[t-tera]

I'm not quite certain but maybe the regex I found was this.
https://github.com/carrierwaveuploader/carrierwave/blob/v1.3.1/lib/carrierwave/uploader/cache.rb#L193

[t-tera]

There are some more regexs.
https://github.com/carrierwaveuploader/carrierwave/blob/v1.3.1/lib/carrierwave/storage/file.rb#L114
https://github.com/carrierwaveuploader/carrierwave/blob/v1.3.1/lib/carrierwave/storage/fog.rb#L142

[mshibuya]

My concern is changing the format of cache id may break compatibility for existing installations. I guess it will not so, but I must think deeper before I'm certain.
I think initial implementation of generate_cache_id didn't have consideration for unpredictability, the only concern was collision avoidance.

[mshibuya]

I've decided not to change cache id format because of compatibility concern.
A random number up to 10^(15+4) is almost equivalent to 64 bits of entropy, it should be hard enough for this use case...