• Hasseman (unregistered)

    Are the frist number not pseudorandom generated?

  • Tinkle (unregistered)

    This is a big RTFM as well as a WTF.

    The documentation for uniqid tells you not to use it if you want the id to be unguessable, and what to use instead.

  • Mike Taylor (unregistered)

    what, no ROT13, posers..

  • RLB (unregistered)

    Also, the default arguments to mt_rand() already are 0 and mt_getrandmax().

    That said, I've used something like (only) the first loop myself - but in that case, the requirements did not involve security and did involve guaranteed, checkable uniqueness. They were stored in a database and used to identify certain devices easily and with some typo resistance (i.e., much larger keyspace than needed). For that, this method is fine. For session IDs? Not so much.

  • FTB (unregistered)

    It's not cryptographically secure but it meets the need for "a unique session ID value that can't easily be guessed".

    It took an awful long time for an MD5 collision to be discovered in real life, and it was generated on purpose. 2^128 is an awfully big space for collisions to happen accidentally.

    If it's an ID for a database you can generate one, see if it exists, then generate another one if it does. I'd bet a LOT of money that it never would though (assuming there was a way for me to collect that bet after a certain time limit).

  • (nodebb)

    I note also the mt_rand(0, mt_getrandmax() which is exactly equivalent to mt_rand()...

    And yes, this one is a fairly high level of WTF.

  • (nodebb) in reply to Tinkle

    The documentation for uniqid tells you not to use it if you want the id to be unguessable, and what to use instead.

    And the documentation for mt_rand() is pretty clear on the same subjects.

  • Tim Ward (unregistered)

    "A random number generation algorithm chosen at random is likely to be crap."

    Not sure where I got this from, but I've known it since the 1970s.

  • (nodebb)

    Honestly the md5() isn't really that terrible of a thing here. Sure, there are absolutely better choices, and adversaries can construct collisions with chosen prefixes, but those attacks don't appear to a concern here since there's no external user input being consumed in this function.

    The rest of the function is indeed a steaming pile of WTF.

  • (nodebb)

    @FTB ref:

    but it meets the need for "a unique session ID value that can't easily be guessed".

    In general I'm on your side here. But it depends heavily on what "guessed" means. And on who came up with that requirement & why. If the guesser to defend against is a bored high schooler or clerk in your firm that's one thing. if it's a "malicious state actor" or whatever euphemism DoD prefers for "China" these days, that's rather another.

    The usual problem with these kinds of requirements is the PHB that thinks of them is thinking about Sarah in accounting. Meanwhile that annoying guy in your IT security department (or who is your IT security department), is thinking "malicious state actor" is the minimum adversary to defend against.

    Reality is probably in the middle. Incompetence, however, is everywhere.

  • Randal L. Schwartz (github) in reply to Tim Ward

    "A random number generation algorithm chosen at random is likely to be crap."

    Knuth, in (I think) Volume 2 of Art of Programming. Classic

  • (nodebb) in reply to adamantoise

    Honestly the md5() isn't really that terrible of a thing here.

    It doesn't help, but it looks like it helps, so it's bad because it makes people feel safe.

    For example, let's say generation one of some session is mechanism is simply an increasing integer. The site gets hacked. The programmer simply MD5's the sessionid and says "There, that's unguessable now". An adversary with more than two brain cells will recognize an MD5 hash and then simply add a "and then MD5 hash it" as the last step of their process that guesses session ids. All you did was make a script kiddie add a line of code to his hack script.

  • Bill T (unregistered) in reply to Tim Ward

    In Donald Knuth's "The Art of Computer Programming", the section on Random Number starts with the quote from John Von Neumann, "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."

    He then goes through different algorithms for this...

  • sudgy (unregistered)

    On the bright side, this won't be easily guessed because attackers won't be expecting something this dumb.

  • I must be doing it wrong then (unregistered)

    Would it be possible that the MD5 Operation is there to disguise the result?

  • Fordom Greeman (unregistered)

    TRWTF is reimplementing sessions when PHP already has that built in

  • (nodebb) in reply to I must be doing it wrong then

    Would it be possible that the MD5 Operation is there to disguise the result?

    Yes. However, any security that adds an obfuscation layer has basically admitted that it need to be obfuscated and therefore isn't "secure enough for purpose" as is. Unfortunately, obfuscation only requires one person to figure out what obfuscation technique is being used and then it becomes worthless. This is the thought process that leads to Kerchoff's principal (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle): "A cryptosystem should be secure, even if everything about the system, except the key, is public knowledge"

  • airdrik (unregistered) in reply to WTFGuy

    hmm.. I actually wonder if it may be the other way around: the PHB is thinking "malicious state actor" but the IT guy knows that it isn't exposed publicly and doesn't need that level of security, so this is all security theater to convince the boss that it's "extra secure" by using md5 to "randomize the bits" even more. (not that doing it the right way is all that hard either; so it's not like the security theater saves them anything, besides accommodating their malicious compliance)

  • (nodebb) in reply to WTFGuy

    Reality is probably in the middle. Incompetence, however, is everywhere.

    Reality is that your run-of-the-mill bad actor looking to get into your system is probably using tools and techniques developed for state actors five years ago. No one trying to forge a session token/cookie is actually guessing with their brain and typing by hand. As long as you are doing something that is reasonably cryptographically sound and your components are getting patched, the technical angle isn't going to work and they will switch to attacking the weaknesses in your process rather than your technology. Most likely, they'll try to use any chat help that you make available to try to get you to reset credentials for them. They'll try chat first because no can sniff out a mismatch between a person's last name and their accent over chat.

  • John (unregistered)

    Aside from the good id or not, the first thing I find odd is that even though the conversion will work they know they are dealing with strings, the initialization is the number zero.

  • Officer Johnny Holzkopf (unregistered)

    Personally, I like the line "$id = md5(uniqid($id, true));" where $id starts as a "random" number string, then becomes a "unique" ID, and ends up as a MD5 hash. So the $id is the hash of a unique number string $id. Of course that's nonsense, it's like saying "$hamburger = cow; $hamburger = fry(defrost(unpack(freeze(mince($hamburger, true))));".

Leave a comment on “My Identification”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article