• (cs)

    So someone couldn't figure out how to restructure their code to allow for a private or protected function? Odd solution.

  • (cs)

    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    Note from Alex: Sorry, this was a transcription error. I fixed it. The original code was identical with the exception of using string.compare(). I changed it to != (well actually == by mistake) b/c it made the WTF a lot easier to immediatley see.

  • (cs)

    I don't buy this. Whoever wrote this had to be a complete retard to not understand how private/protected/internal methods work with C# (assuming the language was not changed to protect the incompetent); what, did they think everything HAD to be made public, and then use this "password" shit to restrict access?

    This is a bit hard to believe, that someone with a job as a developer (who presumably understands the language), doesn't understand how access modifiers work. If this bit needed access by an external module (which is bad in and of itself), and for whatever reason said module couldn't be included in the same assembly (to make use of the Internal keyword) then there's a bigger WTF than shitty code.

  • Mike5 (unregistered)

    Hmm, I have to start using that, since at the moment any idiot can call my methods.

    Mike5

  • passer-by (unregistered) in reply to KattMan

    If you pass in the proper password it fails and raises an exception, 

    but any other string as password allows it to happen? WTF?!
    I bet the API users never saw that coming. Must be very secure.

  • (cs) in reply to passer-by
    passer-by:
    If you pass in the proper password it fails and raises an exception, 
    but any other string as password allows it to happen? WTF?!
    I bet the API users never saw that coming. Must be very secure.
    Precisely! And such an obscure password, at that! <tic> I take "an exception" to that comment!
  • (cs) in reply to KattMan
    KattMan:
    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    That is assuming that the '==' operator does what the author thinks it does.

    That is not true for Java, or C++, but I don't know about C#.

  • (cs) in reply to Mcoder
    Mcoder:
    KattMan:
    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    That is assuming that the '==' operator does what the author thinks it does.

    That is not true for Java, or C++, but I don't know about C#.

    No, it'll work in C++, provided you're using a string class with an overloaded == operator, which the standard string class provides.

  • Eric (unregistered)

    It's C# code, obviously, so the == operator does what we think it does.

    Mixing up == and != in critical if-clauses is bad, no matter if that method is declared private, public or "skript kiddiez please look here".

    Nice password anyway.

  • snoofle (unregistered) in reply to Mcoder

    Hmmmm, X-windows was written in C, where there isn't really any concept of public/private (well, ok, there's static), but declared, by convention, that you shouldn't touch certain fields in the data structures ("handles") it passed back to the caller because they were private to X-windows.

    Maybe this person was trying to follow the same paradigm? twitches

  • rip (unregistered) in reply to bstorer
    bstorer:
    Mcoder:
    KattMan:
    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    That is assuming that the '==' operator does what the author thinks it does.

    That is not true for Java, or C++, but I don't know about C#.

    No, it'll work in C++, provided you're using a string class with an overloaded == operator, which the standard string class provides.

    C++ tends to use public: as a block rather than giving individual access control to each member. In addition, throwing an object allocated with new is a bad idea for C++.

  • (cs) in reply to TheRubyWarlock
    TheRubyWarlock:
    I don't buy this. Whoever wrote this had to be a complete retard to not understand how private/protected/internal methods work with C# (assuming the language was not changed to protect the incompetent); what, did they think everything HAD to be made public, and then use this "password" shit to restrict access?

    This is a bit hard to believe, that someone with a job as a developer (who presumably understands the language), doesn't understand how access modifiers work. If this bit needed access by an external module (which is bad in and of itself), and for whatever reason said module couldn't be included in the same assembly (to make use of the Internal keyword) then there's a bigger WTF than shitty code.

    Private, Protected and Internal are nice.. But if you need to expose the function to an external consumer, then you need to make sure no one can cheat that way (Well actually you should make sure that the flag gets set correctly on all occasions).

    Also private does not protect your function from unauthorized access... It just makes it more annoying ;) But the "secure" string passwod, hardcoded inside the functon, makes it reallllly hard to figure what password to use to FINALLY get the exception

  • Josh (unregistered)

    Yeah, "==" works great for object comparisons .... sheesh. There's the WTF.

  • Josh (unregistered) in reply to Eric
    It's C# code, obviously, so the == operator does what we think it does.

    Not so obviously. It's perfectly valid Java syntax as well.

  • Josh (unregistered) in reply to Josh
    Josh:
    It's C# code, obviously, so the == operator does what we think it does.

    Not so obviously. It's perfectly valid Java syntax as well.

    No, nevermind, I'm dumb. Here's my WTF, there's not return type on the method.

  • (cs) in reply to Josh
    Josh:
    No, nevermind, I'm dumb. Here's my WTF, there's not return type on the method.

    Except that there is.

  • asegstro (unregistered) in reply to Josh

    You sir are correct...

    ...as to how that's a WTF i don't know though...

  • Look at me! I'm on the internets! (unregistered) in reply to Josh
    Josh:
    It's C# code, obviously, so the == operator does what we think it does.

    Not so obviously. It's perfectly valid Java syntax as well.

    Except for the comments. Clearly C#

  • Neerav (unregistered) in reply to Josh
    Josh:
    Josh:
    It's C# code, obviously, so the == operator does what we think it does.

    Not so obviously. It's perfectly valid Java syntax as well.

    No, nevermind, I'm dumb. Here's my WTF, there's not return type on the method.

    Actually, there is: "void". What makes it "not java" is the "bool" type parameter, the "ArgumentException" exception, and the comment block.

    Although those could be in-house developed types and documentation systems for java to avoid using those untrustworthy "boolean", "IllegalArgumentException", and "javadoc" stuff provided by those completely undependable folks at sun...

  • (cs) in reply to TheRubyWarlock

    Technically, internal and private methods/properties can still be accessed using reflection. Assuming that they obfuscated the string, then this would guarentee that only someone who knew the password could call it.

    That doesn't mean it's a horrible example of code though ;-)

  • Gir (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    Josh:
    It's C# code, obviously, so the == operator does what we think it does.

    Not so obviously. It's perfectly valid Java syntax as well.

    Except for the comments. Clearly C#

    And java has not ArgumentException and it doesn't declare the method as throws ArgumentException.

  • (cs) in reply to TheMagic8Ball
    TheMagic8Ball:
    Technically, internal and private methods/properties can still be accessed using reflection. Assuming that they obfuscated the string, then this would guarentee that only someone who knew the password could call it.

    That doesn't mean it's a horrible example of code though ;-)

    s/could/could not/ s/doesn't mean/means/ s/though/to/

  • Joe Grossberg (unregistered)

    Jeebus ... can we just retire the "hard-coded, plain-text password" WTF already?

    This site is getting repetitive, and it was only funny the first 100 times.

  • (cs)

    This is how it should be done:

    public: int SecretFunction(int arg1, int arg2, AuthorizationCallback callbackfn) { if (callbackfn("Please present your credentials to access this function", "P4$$w0rD")) { error("You don't have authorization to call this function!!! The password should have been P4$$w0rD. Please don't tell this password to anybody else. And don't call this function again."); return -63; }

    bool authorized = random(2);

-- snip --

    }

  • Anonymous (unregistered)

    This is totally dumb. They should have done something along the lines of:

    public void OverrideIsUpdated(String password, bool status) 
{
    if (md5(password) != "e1e8fe2e3e77f30640cf66a47d06fe4f") 
    {
        throw new ArgumentException("Invalid password specified!"
          + " This method is for internal use only!", "Password");
    }

    _IsUpdated = status;
   ... snip ...
}
  • (cs) in reply to rip
    rip:
    bstorer:
    Mcoder:
    KattMan:
    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    That is assuming that the '==' operator does what the author thinks it does.

    That is not true for Java, or C++, but I don't know about C#.

    No, it'll work in C++, provided you're using a string class with an overloaded == operator, which the standard string class provides.

    C++ tends to use public: as a block rather than giving individual access control to each member. In addition, throwing an object allocated with new is a bad idea for C++.

    I speak only to the fact that == will work for string comparison in C++. I do not think that this is C++ by any means.

  • FDF (unregistered)

    Code written by pure genius.

  • Dave B (unregistered) in reply to Joe Grossberg
    Joe Grossberg:
    Jeebus ... can we just retire the "hard-coded, plain-text password" WTF already?

    This site is getting repetitive, and it was only funny the first 100 times.

    For me the wtf isn't that the password is in plane text, but that a "set" method has a password at all.

  • (cs) in reply to TheRubyWarlock
    TheRubyWarlock:
    I don't buy this. Whoever wrote this had to be a complete retard to not understand how private/protected/internal methods work with C# (assuming the language was not changed to protect the incompetent); what, did they think everything HAD to be made public, and then use this "password" shit to restrict access?

    Would you buy it if I told you that I'd seen something identical (well, except that it did the string check correctly) in some C++ code on my last project?

    Edit: add quote

  • rob (unregistered)

    I with TheRubyWarlock, this is a fake.

  • Anonymouse (unregistered)

    This sort of thing happens in the hardware world all the time. Microcontrollers password protect the flash write registers, and the manufacturer lists the password (a simple string of 0xAA's and 0x55's, usually) in the datasheet.

    This keeps broken code from burning out the flash memory by randomly writing to registers until the cells wear out.

  • pho (unregistered)

    agreed with the two other chaps; fake!

  • Tamm (unregistered)

    The comments are worse than the article :D Is it just me or should there be a rule against writing too obvious code? seriously... "P#$$w0rd"?!

  • Zygo (unregistered) in reply to Anonymouse
    Anonymouse:
    This sort of thing happens in the hardware world all the time. Microcontrollers password protect the flash write registers, and the manufacturer lists the password (a simple string of 0xAA's and 0x55's, usually) in the datasheet.

    This keeps broken code from burning out the flash memory by randomly writing to registers until the cells wear out.

    In the Linux kernel API, after you have root privilege and whatever security capabilities you need, you also have to supply special parameters to the system reboot() and halt() system calls. The parameter value required is one of the birth dates of Linus Torvalds or his descendents, encoded in hexadecimal.

    Never mind that supplying invalid parameters to half a dozen other system calls, sometimes while not root or not holding any special privileges, will often achieve the same effect as halt() in Linux.

    (ducking)

    I've seen data sheets that go on for pages (the "data sheet" is really a phone-book-sized document) about how to change RAM voltage on a system board. No real password here, but an obscure set of address space overlays and non-standard I/O registers that would be impossible to discover without a data sheet or by reverse engineering existing software that could already talk to the device.

    Then there's TPM, which is an API that has not only password protected methods, but methods with cryptographically secure authentication schemes.

  • (cs) in reply to Joe Grossberg
    Jeebus ... can we just retire the "hard-coded, plain-text password" WTF already?

    You're missing the point. This one would be no less a WTF if the password were looked up from a database in which it is stored in a hashed format.

    In fact, it would be even more so.

  • Patrick (unregistered) in reply to TheMagic8Ball
    TheMagic8Ball:
    Technically, internal and private methods/properties can still be accessed using reflection. Assuming that they obfuscated the string, then this would guarentee that only someone who knew the password could call it.

    That doesn't mean it's a horrible example of code though ;-)

    Are you serious? By that same argument you could do something similar in C++ by taking a pointer to a class and modify its private members if you knew the structure of the object's layout in memory. It would rely on knowing a bit about the implementation of the compiler etc, but still possible. The access levels provided by the environment are more than sufficient in providing proper encapsulation of data. If somebody is using reflection to actually call code they're obviously doing something wrong.

  • Look at me! I'm on the internets! (unregistered) in reply to Gir

    But I wrote ArgumentException extends RuntimeException so I didn't have to screw around with all that trying and catching.

  • Look at me! I'm on the internets! (unregistered) in reply to Look at me! I'm on the internets!
    Look at me! I'm on the internets!:
    But I wrote ArgumentException extends RuntimeException so I didn't have to screw around with all that trying and catching.

    That was a reply to : "And java has not ArgumentException and it doesn't declare the method as throws ArgumentException."

    throw new UserIsAMoronException("Look at me! I'm on the internets");

  • ub0rr0b (unregistered) in reply to KattMan

    The programmer really just wanted to keep themselves from ever using the function. ;-)

  • Artemus Harper (unregistered) in reply to Anonymous
    Anonymous:
    This is totally dumb. They should have done something along the lines of: 
    public void OverrideIsUpdated(String password, bool status) 
{
    if (md5(password) != "e1e8fe2e3e77f30640cf66a47d06fe4f") 
    {
        throw new ArgumentException("Invalid password specified!"
          + " This method is for internal use only!", "Password");
    }

    _IsUpdated = status;
   ... snip ...
}

    That works until you get some library that calls that function. Then you could just reverse engineer it to determine what password was used. If all of the override uses were only distributed internally then the preprocessor should have been used instead to remove the method in external releases.

    If this was Java instead then using the != might just have worked since passing in a String from a different Classloader may be a different reference.

  • mh (unregistered)

    I could buy this being real. I've seen similar being done before by in-house small app developers who either (a) didn't understand security, or (b) didn't want to have a reliance on the networks guys and so went and wrote their own security layer.

    Of course, you could just go digging in the binary with a hex editor and pull out the password that way...

  • (cs) in reply to TheRubyWarlock

    I've seen much worse. I've seen remote systems downloading ALL of the system's passwords to check a user login. And I mean unencrypted passwords. That was much, much, much worse. The same company would usually take 1 week to authorize the installation of any "free software". Yes, they mostly blocked all the free software because of "security issues".

  • (cs) in reply to Anonymous
    Anonymous:
    This is totally dumb. They should have done something along the lines of: 
    public void OverrideIsUpdated(String password, bool status) 
{
    if (md5(password) != "e1e8fe2e3e77f30640cf66a47d06fe4f") 
    {
        throw new ArgumentException("Invalid password specified!"
          + " This method is for internal use only!", "Password");
    }

    _IsUpdated = status;
   ... snip ...
}

    Haha...best response yet.

    That is truly doing the wrong thing the right way.

    Countdown to somebody responding to this post with the made-up word "dehash": 10...9...8...

  • Hans (unregistered) in reply to Patrick
    Patrick:
    Are you serious? By that same argument you could do something similar in C++ by taking a pointer to a class and modify its private members if you knew the structure of the object's layout in memory. It would rely on knowing a bit about the implementation of the compiler etc, but still possible.

    You know, you think people would get it - but at one point I actually ran into an idiot that challenged me that "C++ was broken because you could just smash your way through the flimsy protection mechanism" (using the mechanism you describe). Of course, he also insisted on calling it "C--", no doubt believing that made him look all smart and grown up.

    The really shocking thing is this, though: this didn't happen on the internet ("Where Trolls Roam Free"), this was a real person in a face to face discussion...

  • James (unregistered)

    Actually, the MD5 version above could be a less-than-terrible idea, especially if the password is taken from user input at runtime (and not stored anywhere on disk in plaintext).

    Sure, you'd be better off pulling the hash from someplace external (with write access controlled by the OS). But the OP didn't say whether this was for an "enterprise" system or just something used in-house. Plenty of times, I've written an in-house app where myself and a small team are using e.g. a tracking database where I, as the developer, can do some "power user" things with which I don't want the worker-bee users to shoot themselves in the foot. In such cases -- where it's not critical security, but rather an elaborate "are you sure" prompt -- I might find myself using a trick like this.

    I guess calling it "a trick like this" kind of admits that it's a WTF, though.

  • Matthew Purdon (unregistered)

    The scary thing is that's close to what is considered "best practices" to implement a singleton in PHP4...

  • (cs) in reply to Matthew Purdon
    Matthew Purdon:
    The scary thing is that's close to what is considered "best practices" to implement a singleton in PHP4...
    What?
  • Sharkie (unregistered) in reply to bobday

    This programmer is obviously a junior programmer.

    1. He didn't make the function stop working or lockout should the exception be thrown 4 or more times in a single run. This would reduce rogue programmers from writing password buster callers and eventually figuring out the password.
    2. The password should be forced to be changed at least once every week. This can be easily facilitated through the use of a database query and interface program to maintain the method's password.
    3. Password used should have higher strength.
  • Xeno (unregistered) in reply to pho
    pho:
    agreed with the two other chaps; fake!

    It's a 'shop. I can tell by the pixels.

  • (cs) in reply to Mcoder
    Mcoder:
    KattMan:
    umm wait a minute, please tell me this is a transcription error.

    If you pass in the proper password it fails and raises an exception, but any other string as password allows it to happen? WTF?! (in it's original meaning)

    That is assuming that the '==' operator does what the author thinks it does.

    That is not true for Java, or C++, but I don't know about C#.

    Actually, it will work for C++, and 99% of the time it will work for Java. As long as the calling function also uses a String literal (which I imagine it would, this seems to be something they have hard coded into the method and such strings are normally declared as string literals), the two String refrences will refer to the same object in the string pool iff they are the same string.

Leave a comment on “Protected Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article