Skip navigation

CreateUUID

Feb 23, 2012 8:41 AM

  Latest reply: 12Robots, Mar 2, 2012 7:29 AM
Replies 1 2 3 2 Previous Next
  • Currently Being Moderated
    Mar 2, 2012 5:31 AM   in reply to Adam Cameron.

    Adam, Dave,

     

    Sorry about the trouble with the download link. It took at least 5 attempts to upload it at acobat.com before I could get it to work. It is likely that you tried to download it during the process.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Mar 2, 2012 5:32 AM   in reply to Adam Cameron.

    Not that it helps you Dave, but I could see it fine (albeit it took an absolute age to load).  So - BKBK - perhaps the perms are set for some users but not others?

     

    Or Dave, are you clicking just from the email from the forums?  I went into the web UI and clicked the link from there (so I was alrady authenticated before clicking the link)?

     

    I was clicking the link in the email, rather than going into the forums and clicking from there. Once I did that I could see it just fine, so there's no permissions issue.

     

    BKBK, on first glance, I must say that you have certainly put a lot of effort into this. Probably more than it really deserves, since I can't really pay you for that effort. But in the end, I still disagree. I will try to address the core of this disagreement after my noon deadline, but for now, suffice it to say that I don't think we agree on what "equivalence" means, and the reduceability of words to logical operands.

     

    All that said, I congratulate you on the most thorough response I've ever seen to a forum post.

     

    Dave Watts, CTO, Fig Leaf Software

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 2, 2012 6:03 AM   in reply to Dave Watts

     

    Not that it helps you Dave, but I could see it fine (albeit it took an absolute age to load).  So - BKBK - perhaps the perms are set for some users but not others?

     

    Or Dave, are you clicking just from the email from the forums?  I went into the web UI and clicked the link from there (so I was alrady authenticated before clicking the link)?

     

    I was clicking the link in the email, rather than going into the forums and clicking from there. Once I did that I could see it just fine, so there's no permissions issue.

     

    BKBK, on first glance, I must say that you have certainly put a lot of effort into this. Probably more than it really deserves, since I can't really pay you for that effort. But in the end, I still disagree. I will try to address the core of this disagreement after my noon deadline, but for now, suffice it to say that I don't think we agree on what "equivalence" means, and the reduceability of words to logical operands.

     

    All that said, I congratulate you on the most thorough response I've ever seen to a forum post.

     

     

    Agree with everything you say there, the most important bit being how good the doc is (TBH, I didn't read it all - I'm at work - but I will later).

     

    My point of contention is this... what BKBK initially said was this:

     

    BKBK wrote:

     

    12Robots wrote:

     

    The random string is not meant to make the token more unique, it is meant to make it random. 

    Actually, more unique means random!

     

    So was making a connection between uniqueness and randomness being related.

     

    And this is what Jason, Dave and I have been disagreeing with. "Unique" does not mean "random", and "random" does not mean "unique".

     

    BKBK also said this:

     

    In the above context (of CFToken) uniqueness and randomness are synonymous.

     

    This is not correct either.  I would accept that "in the context of a CFToken value, either approach would be OK for all intents and purposes", but that's not the same as them being synonymous.  They are still distinct concepts (I think we can all agree on that), it's just that either concept will suitably meet the requirement CFToken has.

     

    And that's what the doc seems to discuss: that for the purpose of a CFTOKEN value, a random value will be - for all intents and purposes - as good as a specifically unique value.

     

    I don't think anyone would quibble with that.

     

    Indeed this all started with me questioning the merit of adding an additional random element to a UUID to construct the CFToken value, because it seems like pointless egregiousness (if that's a word).  The UUID by itself already fulfils the requirement, and has the benefit of being an-industry-accepted approach to such things.  What Adobe seems to have done is to invent their own little solution, where the industry-accepted solution is already just fine.  And that - IMO - is a bit thick of them.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 2, 2012 7:12 AM   in reply to Adam Cameron.

    I don't think Adobe is being thick at all. Nor are they going against any industry standard.

     

    Session tokens need to be unique and sufficiently random. CF's UUIDs provide the uniqueness and the Random long integer at the end provides the sufficient randomness. I believe you said earlier in your thread that based on what you saw in the source code that the CF UUID by itself provided abotu 96-bits of randomness (Do any of us have any idea what the entropy limitations are on that method, cause that could reduce the bits of randomness).

     

    The industry standard ( turn to OWASP for that) is *at least* 128-bits of randomly generated numbers created by a cryptographically strong PRNG. https://www.owasp.org/index.php/Insufficient_Session-ID_Length

     

    So what I see is Adobe living up to (and possibly exceeding and future-proofing) the industry standard. The UUIDs by themselves are not sufficient to meet OWASP recommendations.

     

    Jason

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 2, 2012 7:23 AM   in reply to 12Robots

    I don't think Adobe is being thick at all. Nor are they going against any industry standard.

     

    Session tokens need to be unique and sufficiently random. CF's UUIDs provide the uniqueness and the Random long integer at the end provides the sufficient randomness. I believe you said earlier in your thread that based on what you saw in the source code that the CF UUID by itself provided abotu 96-bits of randomness (Do any of us have any idea what the entropy limitations are on that method, cause that could reduce the bits of randomness).

     

    The industry standard ( turn to OWASP for that) is *at least* 128-bits of randomly generated numbers created by a cryptographically strong PRNG. https://www.owasp.org/index.php/Insufficient_Session-ID_Length

     

    So what I see is Adobe living up to (and possibly exceeding and future-proofing) the industry standard. The UUIDs by themselves are not sufficient to meet OWASP recommendations.

     

     

     

    That doc says "128 bits" not "128 bits of randomness".  A UUID is 128-bit.  Just that only 96-bits of the CF ones are random.

     

    That OWASP is saying 128-bits and a UUID is 128-bits is not coincidence.

     

    By my reading of the doc, CF's 128-bit UUID provides 96-bits of entropy.  1.5x the amount they suggest in their calculations.

     

    So what I see is Adobe living up to (and possibly exceeding and future-proofing) the industry standard.

     

    But, yeah, fair enough.  It makes sense on this basis.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 2, 2012 7:29 AM   in reply to Adam Cameron.

    OK, that makes sense. And I better understand entropy now. Thanks for that.

     

    Jason

     
    |
    Mark as:
1 2 3 2 Previous Next
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points