• RaceProUK (disco)
    SELECT MAX(used_num) + 1 FROM used_num
    

    is itself a :wtf:, but at least its :wtf:-factor is measurable, unlike the code in the article…

  • abarker (disco) in reply to RaceProUK

    But how does the provided code's :wtf: factor compare to the :wtf: factor of leaking the front page article three days early?

  • HardwareGeek (disco) in reply to abarker
    abarker:
    the :wtf: factor of leaking the front page article three days early?

    You say this as if it were an unusual occurrence.

  • abarker (disco) in reply to HardwareGeek
    HardwareGeek:
    You say this as if it were an unusual occurrence.

    I intended it as if this should be an unusual occurance. The fact that it happens regularly around here doesn't change the fact that it is a :wtf:

  • JBert (disco) in reply to abarker
    Comment held for moderation.
  • Onyx (disco) in reply to JBert

    Maybe we keep breaking it by replying before it's published and the topic is listed? Who knows what Paula thinks is happening when that happens.

  • HardwareGeek (disco) in reply to Onyx

    I don't know what Paula thinks, but she has again created a second comment topic. Clearly, Paula is TRWTF.

  • Onyx (disco) in reply to HardwareGeek

    Maybe we should rename her to PaulaJumpingBean.


    Filed under: About as unpredictable

  • mikeTheLiar (disco)

    The random bolding in the syntax highlighting of the comments in this snippet is really confusing me.


    Filed under: markdown sucks and confuses me with flavors

  • hungrier (disco) in reply to mikeTheLiar

    According to the markup, it looks like whatever highlighter the front page uses thinks that code is Applescript.

  • Onyx (disco) in reply to mikeTheLiar
    <code class="applescript">
    

    Wait...

    [image]

    Well colour me surprisedjava

  • Gal_Spunes (disco)

    I flinched so hard I pooped a nugget

  • Vault_Dweller (disco) in reply to RaceProUK

    It won't give you a random number

  • RaceProUK (disco) in reply to Vault_Dweller

    It's not meant to be random :stuck_out_tongue:

  • Vault_Dweller (disco) in reply to RaceProUK

    The your code sucks because it does not comply to the specs :trolleybus:

  • Rob_Lemmens (disco)

    How a 4 digit number in any way can fill an array of 1000000 elements with unique numbers is beyond me....

  • thegoryone (disco) in reply to Rob_Lemmens
    Comment held for moderation.
  • redwizard (disco)

    //compact the job number to two digits by adding digits 1+2 and appending to the sum of digits 3+4

    I knew it was downhill from there.

  • Yazeran (disco)

    Marcus inherited a big-ol-ball-of-mud PHP application.

    Guess we could have just stopped there right :-)

  • Yazeran (disco) in reply to redwizard

    Yep.

    And as the already use a database. Why not ad a boolean 'confirm' field to the job table with a false default. The you wouold already have unique cinfirm numbers (meaning the job id) and if that should not be exposed, do a MD5 or similar on it and send that (Yes, I know there are risk of collisions when using hashing, but in this case I think the risk is less than the risk of the max+1 race condition....)

  • thegoryone (disco) in reply to Yazeran
    The you wouold already have unique cinfirm numbers (meaning the job id) and if that should not be exposed, do a MD5

    Seriously?

    I know there are risk of collisions when using hashing, but in this case I think the risk is less than the risk of the max+1 race condition

    Seriously? Come on, the point isn't to make things worse

    Why not ad a boolean 'confirm' field to the job table with a false default

    Because we have no context. At least this is plausible though.

  • AwesomeRick (disco) in reply to thegoryone
    Comment held for moderation.
  • RaceProUK (disco) in reply to AwesomeRick
    AwesomeRick:
    The case for random confirmation numbers is that you don't want people to be able to associate job number to confirmation number. If the values are always increasing incrementally, then a malicious user could craft an electronic or social engineering attack whereby they place an order, record the confirmation number, then try to get the orders for all following orders based on them knowing what the confirmation numbers would be.
    In that scenario, the sequential 'exploit' is merely a symptom of a bad security model :stuck_out_tongue:
  • Yazeran (disco) in reply to thegoryone

    Well obviously you should not use MD5 for cryptography, but for less sensitive things where you only need a pseudo-random string for comparison and where it should be possible to regenerate it from known data, MD5 will still do. (And if you are paranoid, you could use SHA-256/512 or similar, I was only using MD5 as an example)

    Regarding your second comment, I was NOT advocating the max+1 thing, that one is just horrible and waiting to blow up in your face. If you need sequences for anything, use a proper one supplied by your database engine ('serial' type in postgres for instance).

    I was merely saying that compared to that, even relying on MD5 with it relatively high risk of collisions would be a better solution.

  • foxyshadis (disco) in reply to AwesomeRick

    Sooooo.... Pick a card, any card, folks?

    AwesomeRick:
    No, everyone seems to be jumping past the "LIKE" clause in his select. What he's doing is picking out the confirmation numbers that start with that (stupidly constructed) job number prefix, and removing all of them from his candidate list. Then he shuffles the list so he can pick a random confirmation number. Finally he returns the final confirmation number, being the compacted job number pre-pended to the randomly chosen six-digit value.

    Pulling everything is still somewhat dumb, even if it's not insane. Attempting to insert (given a unique constraint) and retrying if necessary would be much faster, at least until the random space is nearly full, which is your early warning that everything's about to fall over on you anyway.

  • foxyshadis (disco) in reply to Yazeran
    Yazeran:
    I was merely saying that compared to that, even relying on MD5 with it relatively high risk of collisions would be a better solution.

    You know what happens when you try to stretch a keyspace of 100 digits by MD5'ing them? You end up with... 100 possible MD5 values. It's not a randomizer, it's a hasher.

  • dkf (disco) in reply to foxyshadis
    foxyshadis:
    You know what happens when you try to stretch a keyspace of 100 digits by MD5'ing them? You end up with... 100 possible MD5 values.

    100 digits or 100 values? That's an important difference. A key space consisting of strings of 100 digits has plenty of room for entropy, and MD5 will do a reasonable job on it. A key space consisting of 100 values (of any length) will just have the MD5 be a fancy expensive tagging (or you might get unlucky and get a collision) like a sort of mathematical designer label.

  • herby (disco)

    The adding of digits 1&2 to 3&4 reminds me of an assembler that decoded its control card. It needed to be "ASMB", but it was checked by subtracting "AS" from "MB", on a 16 bit machine. If the sum matched, it would be allowed. Knowing this, a user did a search and figured out that "FURD" would work just as well. Well, it did look funny on the listings, and I guess you had to be there.

  • Jerome_Grimbert (disco)

    What happen once the table has been filled with one million confirmation ?

    Hope that confirmation is not used to check for a popular social network, i heard there is more than one million people with Internet access, but I might have been misinformed.

  • Sorero (disco)

    Maybe I just did not see it, but the compacted job number ($c_jobno) is never used again in the script. Or am I wrong here. And it will be between 2 and 4 digits long.

    You do not need md5 or shuffle or something like that. Just fetch all confirmation numbers from the database starting with the jobnumer. Generate a random new confirmation number until you found one that is not in the list you fechted from the database. And you are done. If you want increased security, add a salt.

  • kupfernigk (disco)

    What I'm not sure about is this; do PHP developers have shares in server companies, and write code guaranteed to keep companies buying ever bigger servers? Or are they just useful idiots for the server vendors?

  • Sorero (disco) in reply to kupfernigk

    Good idea. I'll ask our hosting company about this ;)

  • kupfernigk (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    i heard there is more than one million people with Internet access, but I might have been misinformed.

    In fact (according to Terry Pratchett) there are only about 130 real people in the world, which is why we keep bumping into one another. The rest are illusions. 10^3 possible primary keys should be enough for anybody.

  • aliceif (disco) in reply to kupfernigk
    Comment held for moderation.
  • accalia (disco) in reply to aliceif
    Comment held for moderation.
  • dahaka (disco) in reply to Sorero
    Sorero:
    the compacted job number [...] will be between 2 and 4 digits long

    This was my first thought when I read this article. Did nobody notice that the confirmation numbers where between 8 and 10 digits long?

    Sorero:
    the compacted job number ($c_jobno) is never used again in the script

    Probably a copy-paste mistake, According to the last comment it should be used in the return statement.

  • AwesomeRick (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    What happen once the table has been filled with one million confirmation ?

    The confirmation number is at least 7 digits, and up to 10 digits, depending on the original value of the order number**. That gives up to 9,999,999,999 values for the confirmation number. Remember that it appends the 6 digit number selected from the array to the original order number (not the compacted one, regardless of what the comment for that line says.)

    ** The article is also wrong regarding what would is happening to the order number. It looks like the order number is 4 digits. The first two digits are added, the 3rd and 4th digits are added, then the two sums are concatenated. Since adding two digits can still yield a two-digit number (eg: 9+9 = 18), the order number isn't shortened to two digits in all cases. Instead it can still be 2, 3 or 4 digits. For example 1234 becomes 37, 3456 becomes 711, and 6789 becomes 1317.

  • HardwareGeek (disco) in reply to kupfernigk
    kupfernigk:
    there are only about 130 real people in the world

    There is only one real person; the rest of you are figments of my imagination. My imagination is ... demented.

  • Jaloopa (disco) in reply to HardwareGeek
    Comment held for moderation.
  • Onyx (disco) in reply to HardwareGeek

    Obfuscation fail, the true nerds still see what you did there.

  • HardwareGeek (disco) in reply to Onyx
    Onyx:
    Obfuscation fail, the true nerds still see what you did there.

    So, um, could you tell me what I did there? Because I wasn't trying to obfuscate anything, just engaging in a bit of solipsism.

  • Onyx (disco) in reply to HardwareGeek

    Wording was close enough, my nerd circuits got triggered.

    “It is known that there are an infinite number of worlds, simply because there is an infinite amount of space for them to be in. However, not every one of them is inhabited. Therefore, there must be a finite number of inhabited worlds. Any finite number divided by infinity is as near to nothing as makes no odds, so the average population of all the planets in the Universe can be said to be zero. From this it follows that the population of the whole Universe is also zero, and that any people you may meet from time to time are merely the products of a deranged imagination.” ― Douglas Adams, The Restaurant at the End of the Universe

    Deranged, demented, close enough.

  • HardwareGeek (disco) in reply to Onyx

    Ah. I have, of course, read that, and perhaps it was lurking somewhere in my subconscious, influencing what I wrote. My conscious thinking, however, was that my imagination must be demented to come up with you lot. :P

  • powerlord (disco) in reply to kupfernigk
    kupfernigk:
    What I'm not sure about is this; do PHP developers have shares in server companies, and write code guaranteed to keep companies buying ever bigger servers?

    SEE? PHP developers CAN learn something from Java developers!

  • kupfernigk (disco) in reply to Onyx
    Onyx:
    Deranged, demented, close enough

    If you think that the multiverse is just as much a "saving the appearance" as were epicycles, in this case to hide the fact that String Theory has nothing under its trousers, space is not infinite; there is a finite number of worlds, a finite fraction is inhabited and the average population of all the planets in the universe is non-zero.

    Alternatively we can just point to the error in saying that a fraction of an infinite number is finite. Even aleph-null divided by aleph-null is still aleph-null. So the whole argument falls down at that point.

    Douglas Adams was doubtless confused because his old 68040-based MACs thought anything over 2 billion was NaN. Nowadays even a crappy mobile phone knows that integer infinity starts a little way beyond 8 * 10^18.

  • Scarlet_Manuka (disco) in reply to kupfernigk
    kupfernigk:
    Even aleph-null divided by aleph-null is still aleph-null undefined.
    FTFY. Though in fact the argument just says that a proper subset of an infinite set must be finite, which of course is false (in fact a valid way to define infinite sets is that they are the ones which have a proper subset the same size as themselves).

    The other logic error is of course going from an average of 0 to a total of 0, particularly when he's just derived the average from a nonzero total. But I don't think the point of the passage was to construct an impeccable logical argument.

  • Onyx (disco)

    You know, I enjoy a good pedantic post as much as the next guy. But damn it, you guys pretty much managed to kill the original joke completely by this point.

  • dkf (disco) in reply to Onyx
    Onyx:
    you guys pretty much managed to kill the original joke completely by this point.

    It's not dead! It's just pining for the nulls…

  • kupfernigk (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    FTFY
    [edit - arrgh, that post was beyond stupid. I don't do drugs, it wasn't that, I can only speculate that it was total loss of blood sugar taking the dog for an extended walk. Or incipient senility. Or both. I can only apologise and run off and hide before conceding that, to the very obvious limts of my mathematical ability, I have to agree that aleph-null divided by aleph-null is undefined. ...sobs uncontrollably...]
  • Yazeran (disco) in reply to Scarlet_Manuka

    Considering who wrote the book I think we can safely assume that it was the exact opposite of trying to make a solid logical argument!

    Sure it sounds like a logical argument, but as with every other logical argument in 'The bible' / Guide, the individual bits seem ok, but the result is completely bonkers :smile:

Leave a comment on “One In a Million”

Log In or post as a guest

Replying to comment #:

« Return to Article