• Bobby T. (unregistered)

    So he should have just checked for articleID.contains("x")?

    P.S. First time I've encountered "hex" crypto!

  • benc (unregistered) in reply to Bobby T.
    Bobby T.:
    So he should have just checked for articleID.contains("x")?

    P.S. First time I've encountered "hex" crypto!

    It's quite normal when an encryption process returns binary data, to encode it in hex format for display. This is not "hex" crypto.

  • Gandor (unregistered)

    I guess that the prefix came in after the function was written. With no (or insufficient) unit tests, it is easy to overlook the difference.

    Than again - why "ciphering" it with using Hex? Not to mention the obvious WTF of wrong detection...

  • Bobby T. (unregistered) in reply to benc
    benc:
    Bobby T.:
    So he should have just checked for articleID.contains("x")?

    P.S. First time I've encountered "hex" crypto!

    It's quite normal when an encryption process returns binary data, to encode it in hex format for display. This is not "hex" crypto.

    Yes, but I needed an innocuous reason to say "first".

  • Andrew (unregistered)

    Hexadecimal numbers != encryption

  • Kryptus (unregistered)

    Hex crypography is the best and has always been !

  • (cs)

    Catching java.util.Exception — check.

  • (cs) in reply to Andrew

    Which is why I specifically said it was encrypted and represented as a hexadecimal number. To put it another way, it was encrypted and then base-16 encoded (as opposed to base-64). It was not converted into a hexadecimal as if that were encryption.

    Although, if it were, that would definitely be a WTF. I've seen people use Base-64 as if it were an encryption algorithm.

  • Honnza (unregistered) in reply to Gandor
    Gandor:
    I guess that the prefix came in after the function was written. With no (or insufficient) unit tests, it is easy to overlook the difference.

    Than again - why "ciphering" it with using Hex? Not to mention the obvious WTF of wrong detection...

    Hex-encoding is good in that it allows you to use only URL-safe characters. Sure, you could use the URL-safe Base64 variant, or base-62, or base-32, but hey, base-16 is sure enough. At least it looks like a number (while in fact it's a binary string).

    Captcha: abbas - We once organized a band mockup contest. Several Queens arrived, one or two Princes, and even a few Abbas.

  • (cs)

    I want to look at the file "DEADBABE" but it keeps telling me it's encrypted ...

  • (cs) in reply to QJo

    A name like that? I'm sure somebody cracked the encryption and posted it to 4chan.

  • GrammarNazi (unregistered)

    "it’d be difficult to tell an integer from a hexadecimal"

    at least decimal integers.

  • Aris (unregistered)

    As someone with a clue in security and in cryptography, I anticipate a WTF every when I hear a sentence begining in "For security, we encrypt". 50% chance they just encoded it. 1/5 chance it contains crictical data for the session. 99% chance they don't check the integrity of the decrypted information before using it.

  • foo (unregistered) in reply to Remy Porter
    Remy Porter:
    Which is why I specifically said it was encrypted and represented as a hexadecimal number. To put it another way, it was encrypted and then base-16 encoded (as opposed to base-64). It was not converted into a hexadecimal as if that were encryption.

    Although, if it were, that would definitely be a WTF. I've seen people use Base-64 as if it were an encryption algorithm.

    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

  • Some Nagesh (unregistered)

    I shall try to recreate the mental process that may lead to such code WTF:

    "Oh, I see, some IDs have to be decoded right? Well I'll start with a function that decodes them!"

    int decode(sting id){
  if (not id.startswith('0x'))
      throw exception #extra check
  strip_first_two_digits(id)
  return decode_hex(id)
}

    "Well that was easy! Now to write the main code. Hmm how can I tell if I should pass the ID to the function or not... it's important not to repeat any code. DRY, always follow that... doing the same thing twice is clearly not efficient. And the other function already processes the 0x, so I'll check if it's an hex directly, by seeing if it has letters! Brilliant! Now what is the best way to implement that..."

  • foo2 (unregistered) in reply to foo
    foo:
    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

    ...and...?

    ROT3 is an encryption algorithm (as is ROT13).

    Whether it's sufficient for the intended purpose is another matter.

  • (cs)

    Another Remy article with no html comments and no sparkly ponies. I am really let down today.. :(

  • Terry (unregistered) in reply to Aris
    Remy Porter:
    I've seen people use Base-64 as if it were an encryption algorithm.
    Well if the salesbabe can't read it, that should be good enough for the demo.
    Aris:
    99% chance they don't check the integrity of the decrypted information before using it.
    Crypto is "secure", which means it is magic and cures all ills. No one can tamper with crypted data because they can't read it (see above). Besides, it decrypted successfully, so it must be clean.

    (Bonus points if the code actually checks for successful decryption. Double-double if the programmer figures out a way to create a test case for that code path.)

  • some pony (unregistered) in reply to foo

    Ridiculous. At that in the time when writing it down would be encryption enough!

  • My name (unregistered) in reply to Quango
    Quango:
    Another Remy article with no html comments and no sparkly ponies. I am really let down today.. :(

    I'm calling it a fake!

  • (cs) in reply to QJo
    QJo:
    I want to look at the file "DEADBABE" but it keeps telling me it's encrypted ...

    I'm not into that stuff. I prefer plain B00B1E5.

  • foo (unregistered) in reply to foo2
    foo2:
    foo:
    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

    ...and...?

    ROT3 is an encryption algorithm (as is ROT13).

    Whether it's sufficient for the intended purpose is another matter.

    How is ROT-n more of an encrytion algorithm than Base-n? In both cases you just need to guess one number out of a small range. Just because one was meant for encryption and the other for encoding doesn't actually make it so.

  • (cs) in reply to Remy Porter
    Remy Porter:
    I've seen people use Base-64 as if it were an encryption algorithm.

    I've seen sites that ROT13 and then BASE64 the plaintext. Extra double happy fun encryption that one!

  • What's a Remy anyway? (unregistered) in reply to Zemm
    Zemm:
    QJo:
    I want to look at the file "DEADBABE" but it keeps telling me it's encrypted ...
    I'm not into that stuff. I prefer plain B00B1E5.
    You perv! That's not a proper hex number. Try maybe 0B00B1E5.
  • foxyshadis (unregistered) in reply to Terry
    Terry:
    (Bonus points if the code actually checks for successful decryption. Double-double if the programmer figures out a way to create a test case for that code path.)
    Well, it's not like encrypted MACs are some newfangled thing. They go back about as far as DES itself, specifically to solve that particular problem.
  • foo2 (unregistered) in reply to foo
    foo:
    foo2:
    Whether it's sufficient for the intended purpose is another matter.
    How is ROT-n more of an encrytion algorithm than Base-n? In both cases you just need to guess one number out of a small range. Just because one was meant for encryption and the other for encoding doesn't actually make it so.

    Is the end result plain text? No? Well, I guess it's encrypted.

    As before, YMMV depending on what you consider "sufficient for the intended purpose".

  • Caesar, Julius (unregistered) in reply to foo

    Just look up the history of cryptography. ROT-n WAS (one of?) the first ciphers used in practice.

    captcha "luctus" - I feel at home

  • (cs) in reply to foo2
    foo2:
    foo:
    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

    ...and...?

    ROT3 is an encryption algorithm (as is ROT13).

    Whether it's sufficient for the intended purpose is another matter.

    For better results, you may use ROT13 twice...

  • (cs) in reply to What's a Remy anyway?
    What's a Remy anyway?:
    Zemm:
    I'm not into that stuff. I prefer plain B00B1E5.
    You perv! That's not a proper hex number. Try maybe 0B00B1E5.
    So, you're a fan of Irish Girl?
  • refoveo (unregistered) in reply to Quango
    Quango:
    Another Remy article with no html comments and no sparkly ponies. I am really let down today.. :(

    You're not the only one. I for one enjoy looking through the html for comments.

    esse

  • poogles (unregistered) in reply to Bobby T.

    Duh. He should have made it lower case first. Sheesh! So stupid.

  • justsomedudette (unregistered)

    "based on the integer ID passed" isn't this breaking the rule about integers and IDs?

    Unless it's used for mathematics it's a string.

  • (cs)

    Don't forget though that just because it contains digits or hex digits and therefore looks like a number, doesn't mean it is one or should be stored as one. Unless you plan to do numeric calculations or operations with it, it is really a string and should be stored and handled as one....

  • Herr Otto Flick (unregistered) in reply to foo
    foo:
    Remy Porter:
    Which is why I specifically said it was encrypted and represented as a hexadecimal number. To put it another way, it was encrypted and then base-16 encoded (as opposed to base-64). It was not converted into a hexadecimal as if that were encryption.

    Although, if it were, that would definitely be a WTF. I've seen people use Base-64 as if it were an encryption algorithm.

    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.

    You sure it wasn't ROT-13? Are you dizzy blud?

  • gangdam style (unregistered)

    Did anyone else find the comment at the top misleading? I assumed that the commented out line was the code being replaced, and it looked as if the author checked for [A-Fa-f], then did the exact same thing as the previous implementation, otherwise it did nothing. Did I miss something?

    RE: encryption / authentication, unfortunately, without a huge surface area for attack, a motivated attacker, or having your vulnerable site posted here, security by (even the most minimal obscurity) seems to have worked just fine for every freelance client i warn about the SQLI vulnerabilities in their login form (which was developed by some other freelance guy from the subcontinent, not me).

  • (cs) in reply to Quango
    Quango:
    Another Remy article with no html comments and no sparkly ponies. I am really let down today.. :(
    I know! It's the only reason I read TDWTF now!

    Remy, do you like mmmmmbananas?

  • (cs)

    ok, the "real" WTF for those who don't get it:

    They are looking at your "number" and deciding whether or not it is hex by whether it contains any hex digits but forgot that not all hex numbers contain hex digits. So 1f is thirty-one but 20 is always twenty, never 20 hex which is thirty-two.

    It seems subsequently they decided using 0x as a prefix was a better option for writing hex literals.

  • B00B1E5h (unregistered) in reply to What's a Remy anyway?

    0B00B1E5 doesn't work on most systems because leading zero means octal. Try 0xB00B1E5, but that doesn't sound nearly as fun.

  • (cs)

    184594917

  • Yonder be Nagesh (unregistered) in reply to Some Nagesh
    Some Nagesh:
    I shall try to recreate the mental process that may lead to such code WTF:

    "Oh, I see, some IDs have to be decoded right? Well I'll start with a function that decodes them!"

    int decode(sting id){
  if (not id.startswith('0x'))
      throw exception #extra check
  strip_first_two_digits(id)
  return decode_hex(id)
}

    "Well that was easy! Now to write the main code. Hmm how can I tell if I should pass the ID to the function or not... it's important not to repeat any code. DRY, always follow that... doing the same thing twice is clearly not efficient. And the other function already processes the 0x, so I'll check if it's an hex directly, by seeing if it has letters! Brilliant! Now what is the best way to implement that..."

    I've always hated sting data types...so painful to deal with!

  • (cs)

    And don't forget CBEEB1E5 - that young kids TV channel.

  • (cs)

    I can just hear echoes of him justifying this face-palm monstrosity: "Well they might remove that '0x' in a future release. Then how would we identify a hex number? I'm the best because I plan ahead!"

    Sigh

    And yet another "encryption" process in the same class as ROT-13 or base-64...

    Sigh

    Neither security nor quality programming died: Both were clearly stillborn.

  • foo (unregistered) in reply to foo2
    foo2:
    foo:
    foo2:
    Whether it's sufficient for the intended purpose is another matter.
    How is ROT-n more of an encrytion algorithm than Base-n? In both cases you just need to guess one number out of a small range. Just because one was meant for encryption and the other for encoding doesn't actually make it so.

    Is the end result plain text? No? Well, I guess it's encrypted

    If thet's your only condition, than both ROT-n end besa-n era ancryptions, just lika this ona (swepping e's end a's).

  • some pony (unregistered)

    ROT is an encryption algorithm because it works like an encryption algorithm; you give it a plaintext and a key (3 or 13 in our archtypical examples), and out comes a cyphertext.

    BASE64 is not an encryption algorithm because it does not work like an encryption algorithm. You can give it plaintext, and you can call the output 'cyphertext', but there is no key.

    ROT, on its own is not an encoding algorithm. Because ROT itself requires a key to be used at all. If we pick a special instance of ROT, namely ROT13 (which is just ROT, but with they key fixed on 13), it is an encoding algorithm, although I cannot think of much use for this particular encoding.

    The archtypical emperor did not use '13' as its key. Some people think so because rot13 has this special property that it is its own reverse algorithm (decoding or encoding ROT13 gives the same result). However, this is not true for latin because its alphabet is not 26 characters. Don't ask me how this is a valid argument for a certain person having used it or not though.

    All together, however, that is not to say that ROT is a good encryption algorithm.

  • You're bovinist (unregistered) in reply to B00B1E5h
    B00B1E5h:
    0B00B1E5 doesn't work on most systems because leading zero means octal. Try 0xB00B1E5, but that doesn't sound nearly as fun.

    and what exactly is wrong with Ox boobies?

  • justsomedudette (unregistered) in reply to B00B1E5h
    B00B1E5h:
    0B00B1E5 doesn't work on most systems because leading zero means octal. Try 0xB00B1E5, but that doesn't sound nearly as fun.
    0xB00B1E5 also known as udders
  • foxyshadis (unregistered) in reply to Cbuttius
    Cbuttius:
    ok, the "real" WTF for those who don't get it:

    They are looking at your "number" and deciding whether or not it is hex by whether it contains any hex digits but forgot that not all hex numbers contain hex digits. So 1f is thirty-one but 20 is always twenty, never 20 hex which is thirty-two.

    It seems subsequently they decided using 0x as a prefix was a better option for writing hex literals.

    But apparently forgot to tell the guy consuming the links. (Or just called it a job well done and got drunk after closing the ticket without testing beyond loading a random page.)
  • urza9814 (unregistered) in reply to some pony
    ROT is an encryption algorithm because it works like an encryption algorithm; you give it a plaintext and a key (3 or 13 in our archtypical examples), and out comes a cyphertext.

    BASE64 is not an encryption algorithm because it does not work like an encryption algorithm. You can give it plaintext, and you can call the output 'cyphertext', but there is no key.

    So...then ROT is encryption, ROT13 is not? It's encryption until you select a key?

    Or...BASE64 is encryption -- the key being 64.

  • (cs) in reply to some pony
    foo:
    I've seen (well, not literally) emperors use ROT3 as if it were an encryption algorithm.
    some pony:
    The archtypical emperor did not use '13' as its key.
    Whatever lunacy this is, it's contagious.
  • Aris (unregistered) in reply to gangdam style
    gangdam style:
    RE: encryption / authentication, unfortunately, without a huge surface area for attack, a motivated attacker, or having your vulnerable site posted here, security by (even the most minimal obscurity) seems to have worked just fine for every freelance client i warn about the SQLI vulnerabilities in their login form (which was developed by some other freelance guy from the subcontinent, not me).

    If this is my work, I will find the vulnerability in both use cases. How damn easy it is to be exploited by script kiddies is not relevant. When you get your database dumped only once, the harm is done.

Leave a comment on “Hexed Id”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article