• (cs) in reply to WTF Batman
    WTF Batman:
    Anonymous:

    Hank - "We ship products with backdoor passwords. They are 10 random digits, and only internal support knows them - we don't tell customers."

    That is a really bad idea - If I was a customer and I found out you had a backdoor I would be really, really upset.



    Bah, people have suspected Microsoft of having backdoors in Windows for years. Supposedly, there's also government code in Photoshop to prevent counterfeiting.

    Dunno how true this stuff is, but it seems at least plausible. Backdoors may already be a fact of life in the products you use every day. Don't like it? Use FOSS. Don't like FOSS? I guess you're stuck. *shrug*

    I would say the Photoshop rumor is probably a legitimate one. Y'know, considering that it was a featured story in Wired last year and you can read all about it on the Adobe website here.

  • (cs) in reply to ptomblin
    ptomblin:
    At one job I had, we had a backdoor password that was the first three letters of the current day of the week, backwards.  We had to change it to '*' because the idiot field circus couldn't remember the original backdoor.  Or couldn't spell the days of the week, more likely.

    You didn't have to jump straight to making it that simple -- you could have tried using the last three letters of the day-of-week.

  • maht (unregistered) in reply to Maurits
    Maurits:
    A good backdoor should require something stronger than a password.  Say, physical access to the machine, and a certificate signed by the program manufacturer.


    hear, hear

    The secruity of your data is proportional to the strength of your doors.
  • (cs) in reply to Manni
    Manni:
    WTF Batman:
    Anonymous:

    Hank - "We ship products with backdoor passwords. They are 10 random digits, and only internal support knows them - we don't tell customers."

    That is a really bad idea - If I was a customer and I found out you had a backdoor I would be really, really upset.



    Bah, people have suspected Microsoft of having backdoors in Windows for years. Supposedly, there's also government code in Photoshop to prevent counterfeiting.

    Dunno how true this stuff is, but it seems at least plausible. Backdoors may already be a fact of life in the products you use every day. Don't like it? Use FOSS. Don't like FOSS? I guess you're stuck. *shrug*

    I would say the Photoshop rumor is probably a legitimate one. Y'know, considering that it was a featured story in Wired last year and you can read all about it on the Adobe website here.



    Just because the corporations say it's true doesn't mean it is.  It's all a scare tactic, designed to keep you from printing your own money.  There's not really any protection there.  It's like in middle school when they told you that you could get AIDS from unprotected sex.  We all know now that you can only get it from unprotected gay sex.  And don't get me started on the holocaust, moon landing, trail of tears, and 9/11.  All government lies!

    (that's satire, not a serious comment)
  • (cs) in reply to .*

    I reckon that tomorrow will repeat itself. I don't remember it from the first time though, so I don't mind. But I guess I'll avoid browsing this site with images on. Thanks for the warning!

  • Sam (unregistered)

    Alex Papadimoulis:

     if (request.getParameter("backdoor") != null
          && request.getParameter("backdoor").equals("secret"))

     

    I like how he makes sure it's secure by first checking if "backdoor" is null, and only then going on to check if it's "secret"

  • (cs) in reply to Sam
    Anonymous:

    Alex Papadimoulis:

     if (request.getParameter("backdoor") != null
          && request.getParameter("backdoor").equals("secret"))

     

    I like how he makes sure it's secure by first checking if "backdoor" is null, and only then going on to check if it's "secret"



    Indeed. The performance implications must be stupendous! He should have written it in assembler!
  • XPSucks (unregistered)

    Come on, guys - you are just jealous because he is an expert and you are not.

  • SkyHeaven (unregistered) in reply to Sam

    If that check for null wasn't there, you would get a null pointer if the backdoor parameter wasn't present.
    He got that part right ;)

  • mkb (unregistered) in reply to WTF Batman
    WTF Batman:
    Supposedly, there's also government code in Photoshop to prevent counterfeiting.


    I'm pretty sure they admitted to that.
  • (cs) in reply to SkyHeaven
    Anonymous:
    If that check for null wasn't there, you would get a null pointer if the backdoor parameter wasn't present.
    He got that part right ;)


    But this should work null-or-not, right?

    if ("secret".equals(request.getParameter("backdoor")))
  • (cs) in reply to mkb
    Anonymous:
    WTF Batman:
    Supposedly, there's also government code in Photoshop to prevent counterfeiting.


    I'm pretty sure they admitted to that.


    Ah hah!! Vindication!  I'm never taking off my tinfoil hat again!

  • David (unregistered)

    We bought an ERP system that breaks if your database login is anything other than Master, master. And the admin login (also hardcoded) is supervsr, supervsr. And the frontends must have read/write access to the folder on the server containing the ERP and database, even though all database access is client-server. The secure method they recommend is to setup the frontend with the UNC path rather than mapping it as a drive.

    My next year will be spent fixing this thing, without any access to the source of course. It's our first ERP, and we made the mistake of paying upon install. The demos looked alright, and the feature list exactly matched what we were looking for. But I could go on for days explaining all the stupid things that are wrong with it. If I had the source (we discovered it's written in COBOL), I'm sure there'd be a few WTF's. It's using the database as a set of flat text files. It's not normalized, having child records that repeat nearly every field from the parent record. The DBMS reports index corruption, which they say is normal because they tricked it into putting many tables into a single file intended to store one table. They filter out the extra tables by creating a view on each. Somewhere it's keeping a list of customers sorted by name, not in any tables, which gets out of sync with the customer table and must be rebuilt with a batch.

  • SkyHeaven (unregistered) in reply to Maurits
    Maurits:
    Anonymous:
    If that check for null wasn't there, you would get a null pointer if the backdoor parameter wasn't present.
    He got that part right ;)


    But this should work null-or-not, right?

    if ("secret".equals(request.getParameter("backdoor")))


    Yes, but the other poster seemed to be implying that the null check was unnecessary even though it was in that particular statement.
    I guess it really depends on the poster's intention.

    I personally wouldn't do "secret".equals(...), but that's only because I prefer to always have the variable as the lvalue.
    This way is safer, but once people do things a certain way for a long time they get used to it and start to resist change. (That's where I stand on this probably and I think there's other people who do this, even if unintentionally)
    This is especially true of C/C++ where a missing '=' in a conditional can produce interesting results. Putting the constant as the lvalue avoids the whole issue...
  • Tony Morris (unregistered) in reply to Maurits
    Maurits:
    Anonymous:
    If that check for null wasn't there, you would get a null pointer if the backdoor parameter wasn't present.
    He got that part right ;)


    But this should work null-or-not, right?

    if ("secret".equals(request.getParameter("backdoor")))


    Yes, assuming the type (in this case java.lang.String) supports the Object.equals contract, which it does. Those who babble about performance implications from multiple invocations of a method are yet to learn about HotSpot compilation and premature optimisation (HotSpot is better at inlining method invocations than you).

    On that note, today is my last day working on the Java spec. implementation for The Filth (<insert-large-corporation-name-here/>). Expect some mind-blowing submissions to thedailywtf soon.
  • funnythat (unregistered) in reply to Sean

    Yeah, I have to agree... I know pleanty of not-so-sensitive places where things like this are used. As a matter of fact the best security is obscurity, I've had wide open boxes that were named strangly that never got so much as a port scan for YEARS.

    Microsoft stuff is easy to hack because it's everywhere and thier 'features' are wll published and easy to find. I have to say, this post and all the replies just show what ignorant newbs you all are.

  • (cs) in reply to George
    Anonymous:
    No.. sadly I think he really thinks this is OK - you'd probably be surprised how many developers out there really believe their system will never be subjected to any hacking attempts...


    I've found a good cure for that, have logwatch mail them every morning with all the alerts generated by the firewall and all authentication failures in the last 24hours on a live, world facing, server. Should scare the fucking crap out of them enough to realise that the big bad world is just that, very big and very bad!
  • (cs) in reply to funnythat
    Anonymous:

    Yeah, I have to agree... I know pleanty of not-so-sensitive places where things like this are used. As a matter of fact the best security is obscurity, I've had wide open boxes that were named strangly that never got so much as a port scan for YEARS.

    Microsoft stuff is easy to hack because it's everywhere and thier 'features' are wll published and easy to find. I have to say, this post and all the replies just show what ignorant newbs you all are.


    It is odd, but adding 1 to your database port will usually be sufficient to guard against any potential worms, port scans, and script kiddies (if for some ungodly reason you have to have it open at the firewall), same for rdp and such. Full-range scans are extremely rare for attention-deficit kiddies. Then you can get back to the real work of guarding against insider hacks.

    And you're all wrong about what this is. The guy is a soul man, he's got the blues and isn't afraid to sing it in code! Why he's a backdoor man, and all you ladies know what he means.
  • (cs) in reply to David
    David:
    We bought an ERP system that breaks if your database login is anything other than Master, master. And the admin login (also hardcoded) is supervsr, supervsr. And the frontends must have read/write access to the folder on the server containing the ERP and database, even though all database access is client-server. The _secure_ method they recommend is to setup the frontend with the UNC path rather than mapping it as a drive.

    My next year will be spent fixing this thing, without any access to the source of course. It's our first ERP, and we made the mistake of paying upon install. The demos looked alright, and the feature list exactly matched what we were looking for. But I could go on for days explaining all the stupid things that are wrong with it. If I had the source (we discovered it's written in COBOL), I'm sure there'd be a few WTF's. It's using the database as a set of flat text files. It's not normalized, having child records that repeat nearly every field from the parent record. The DBMS reports index corruption, which they say is normal because they tricked it into putting many tables into a single file intended to store one table. They filter out the extra tables by creating a view on each. Somewhere it's keeping a list of customers sorted by name, not in any tables, which gets out of sync with the customer table and must be rebuilt with a batch.


    Why does your company need you to fix these idiocies?
    Didn't your company purchase yearly maintenance together with the license to use this piece of junk program?
    Since you do not have the source code and the people who sold it to you do, why can't you submit these issues to them as bugs and get a version that works properly.
    These sound like the type of things that a lot of other clients would complain about anyway so isn't it in the seller's best interest to solve these issues?
    At my company we could never get away with telling our clients to live with these types of issues.
  • (cs) in reply to kipthegreat
    kipthegreat:
    Manni:
    WTF Batman:
    Anonymous:

    Hank - "We ship products with backdoor passwords. They are 10 random digits, and only internal support knows them - we don't tell customers."

    That is a really bad idea - If I was a customer and I found out you had a backdoor I would be really, really upset.



    Bah, people have suspected Microsoft of having backdoors in Windows for years. Supposedly, there's also government code in Photoshop to prevent counterfeiting.

    Dunno how true this stuff is, but it seems at least plausible. Backdoors may already be a fact of life in the products you use every day. Don't like it? Use FOSS. Don't like FOSS? I guess you're stuck. *shrug*

    I would say the Photoshop rumor is probably a legitimate one. Y'know, considering that it was a featured story in Wired last year and you can read all about it on the Adobe website here.



    And don't get me started on the holocaust, moon landing, trail of tears, and 9/11.  All government lies!

    (that's satire, not a serious comment)


    I know you're just kidding around about this last part but to the best of my knowledge, governments didn't do a damn thing about the holocaust. They knew it was going on at least since 1942 and could've easily dropped a few bombs and derailed some of those trains and at least slowed those nazi maniacs down a little bit. Not only that, the US and other countries also sent people who managed to escape back to where they came from so that they could get killed.
  • Anderson (unregistered) in reply to R.Flowers
    R.Flowers:
    Anonymous:

    What do they do when they forget "<font color="#800080" size="4">secret</font>" as the password!?!?

    Then they have to type in <font style="background-color: rgb(255, 255, 0);" face="Courier New">'OVERRIDE PASSWORD'</font> and proceed.



    or they could just rerout the encryption, just like they do in the movies!!
  • (cs)
    Alex Papadimoulis:

    ... At my last place we always did this all the time, the new expert responded ...

    <FONT face=Georgia>And it worked 50% of the time, all the time...</FONT>

  • (cs) in reply to Manni
    Manni:
    WTF Batman:
    Anonymous:

    Hank - "We ship products with backdoor passwords. They are 10 random digits, and only internal support knows them - we don't tell customers."

    That is a really bad idea - If I was a customer and I found out you had a backdoor I would be really, really upset.



    Bah, people have suspected Microsoft of having backdoors in Windows for years. Supposedly, there's also government code in Photoshop to prevent counterfeiting.

    Dunno how true this stuff is, but it seems at least plausible. Backdoors may already be a fact of life in the products you use every day. Don't like it? Use FOSS. Don't like FOSS? I guess you're stuck. *shrug*

    I would say the Photoshop rumor is probably a legitimate one. Y'know, considering that it was a featured story in Wired last year and you can read all about it on the Adobe website here.

    Some time ago, Dutch computer magazine PCM used Euro notes to test scanners, which means that the issue containing the review on those scanners contained several images of a portion of a €20 bill.

    Naturally, they got complaints from the European Central Bank. :)

  • Daruku (unregistered) in reply to OneFactor

    You could look for the pi symbol in the lower right hand corner of every web page.

  • Nitpicker (unregistered) in reply to SkyHeaven

    I'm kinda confused why you call the "secret" literal an lvalue.  Doesn't the term lvalue really only apply to assignment expressions.  I.e., the lvalue is what you find on the left side of an assignment expression (str = "hello", str is the lvalue).  In the above code, "secret" is the target object of a method call, not the lvalue of an assignment, so that term isn't really appropriate.  Really, the technique of using the String literal as the target object in an equals() call just guarantees there won't be a NPE, because the equals() method of String does not throwing a NPE if you provide a null as the parameter, and you know the String literal isn't null.

    This is in contrast to languages like C, where the technique of reversing the constant with the variable is used to prevent accidental assignments, like "if (5=x) do_something();".  Since the lvalue in this expression is 5, and the constant 5 doesn't have a lvalue, this causes an error when compiling, and then you remember to make it "if (x==5) do_something();"  The expression "if (x=5) do_something();" won't get caught by the compiler, and the assignment was most likely not what you want.

    Ok, I'm nitpicking, but in Java, the technique of using a constant String as the target of an equals() method call has nothing to do with lvalues.  The technique in C of putting the constant on the left side of a "==" comparison is to catch an error by putting something that isn't a valid lvalue on the left side, so the compiler can catch the mistake of using a single equals to compare.

    Ok, I shut up now.

  • anon (unregistered)

    Oh, ok, so he should write it like this:

    if (authTicket == null && "secret".equals(request.getParameter("backdoor"))) {
      // create the ticket like he did
    } else {
      throw new AuthorizationException();
    }

  • fullstop (unregistered) in reply to nullptr
    Anonymous:
    Not only does he include this nastiness, but he also uses a pet peeve pattern of mine (and a consistently great indicator of a crappy developer) -- not using a variable to store the result of a lookup (getParameter). Why, WHY do all crappy developers always do this?


    Why waste the stack space?  I don't understand what the issue is here, honestly.

    I can understand if you don't store the value, and you access multiple times.  Other than that, can you fill me in?
  • fullstop (unregistered) in reply to Tony Morris
    Anonymous:

    Yes, assuming the type (in this case java.lang.String) supports the Object.equals contract, which it does. Those who babble about performance implications from multiple invocations of a method are yet to learn about HotSpot compilation and premature optimisation (HotSpot is better at inlining method invocations than you).
    <insert-large-corporation-name-here>


    Interestingly enough, "12345".equals(new Integer(12345)); will return false.
    In java at least.
    </insert-large-corporation-name-here>
  • Anon (unregistered) in reply to David

    Anonymous:
    We bought an ERP system that breaks if your database login is anything other than Master, master. And the admin login (also hardcoded) is supervsr, supervsr. And the frontends must have read/write access to the folder on the server containing the ERP and database, even though all database access is client-server. The _secure_ method they recommend is to setup the frontend with the UNC path rather than mapping it as a drive.

    My next year will be spent fixing this thing, without any access to the source of course. It's our first ERP, and we made the mistake of paying upon install. The demos looked alright, and the feature list exactly matched what we were looking for. But I could go on for days explaining all the stupid things that are wrong with it. If I had the source (we discovered it's written in COBOL), I'm sure there'd be a few WTF's. It's using the database as a set of flat text files. It's not normalized, having child records that repeat nearly every field from the parent record. The DBMS reports index corruption, which they say is normal because they tricked it into putting many tables into a single file intended to store one table. They filter out the extra tables by creating a view on each. Somewhere it's keeping a list of customers sorted by name, not in any tables, which gets out of sync with the customer table and must be rebuilt with a batch.

    No offence but I thought the great american tradition was "It doesn't work properly" = Legal Action (I'm an aussie, and it happens here too, I've worked for companies who've had legal action against them because something didn't work as the customer expected)

    Sounds like a legitimate gripe, Make them fix it.

  • (cs) in reply to Anon

    if(paula=='secret') {...}

  • (cs) in reply to fullstop

    Anonymous:
    Anonymous:
    Not only does he include this nastiness, but he also uses a pet peeve pattern of mine (and a consistently great indicator of a crappy developer) -- not using a variable to store the result of a lookup (getParameter). Why, WHY do all crappy developers always do this?


    Why waste the stack space?  I don't understand what the issue is here, honestly.

    I can understand if you don't store the value, and you access multiple times.  Other than that, can you fill me in?

    Eh... generally the temporaries use the stack space anyway.  Besides, what usually amounts to a few bytes is rather insignificant in most cases.

  • (cs) in reply to Corwinoid

    We ought to be able to edit...

     

    I'll add to that.  In C/C++, you know, real languages, the TRO persists until the end of the statement, but the space used by the TRO on the stack is non-permeable in the current scope (generally you'll only have one stack move per scope, if not one per function).  For a series of TROs, the compiler may reuse the same stack space, and you only pay once for the largest object.  So you might save a few bytes by using unnamed temporaries like this.

     

    AFAIK, however, in Java, you don't get TROs.  The return should be the returned object, which will persist until garbage collection.  Correct me if I'm wrong.

    Leaving the local reference unamed gives you nothing.

  • (cs) in reply to anon
    Anonymous:
    Oh, ok, so he should write it like this:

    if (authTicket == null && "secret".equals(request.getParameter("backdoor"))) {
      // create the ticket like he did
    } else {
      throw new AuthorizationException();
    }


    I'll let you figure out what's wrong with that :)
  • (cs)

    Good lord.

  • Dum dum dum.... (unregistered) in reply to fullstop
    Anonymous:
    Anonymous:

    Yes, assuming the type (in this case java.lang.String) supports the Object.equals contract, which it does. Those who babble about performance implications from multiple invocations of a method are yet to learn about HotSpot compilation and premature optimisation (HotSpot is better at inlining method invocations than you).
    <insert-large-corporation-name-here>


    Interestingly enough, "12345".equals(new Integer(12345)); will return false.
    In java at least.
    </insert-large-corporation-name-here>


    I don't see why that's interesting. Why would a String be equal to an Integer that happens to have the value of numbers in the String? And if you expect it to be the same, why use a base 10 decimal, and not, say Hex? "12A45"... etc, etc.

    But, I've gotta say, this is the best WTF I've seen in a LONG time. I've lurked for quite sometime... but this I've gotta say is the best.
  • (cs) in reply to Brian H
    Anonymous:

    What do they do when they forget "<font color="#800080" size="4">secret</font>" as the password!?!?



    Download the source from sourceforge.net and browse through it.
  • zzz123 (unregistered) in reply to Unforgiven

    As of 6-8 months ago, your standard inkjet printer/scanners at Best Buy worked just fine on US bills.  I used a crisp $20 to test out half a dozen models I was considering buying.

    I had seen the documentary on a rock show promoter travelling around Illinois passing copied bills, and the comment from the Secret Service that all "modern" copiers had protections against it.  I was curious if it was true.  Maybe on bigger business copiers, but not these cheap things...

  • Warning! (unregistered) in reply to Nitpicker
    Anonymous:
    I'm kinda confused why you call the "secret" literal an lvalue.  Doesn't the term lvalue really only apply to assignment expressions.  I.e., the lvalue is what you find on the left side of an assignment expression (str = "hello", str is the lvalue).  In the above code, "secret" is the target object of a method call, not the lvalue of an assignment, so that term isn't really appropriate.  Really, the technique of using the String literal as the target object in an equals() call just guarantees there won't be a NPE, because the equals() method of String does not throwing a NPE if you provide a null as the parameter, and you know the String literal isn't null.

    This is in contrast to languages like C, where the technique of reversing the constant with the variable is used to prevent accidental assignments, like "if (5=x) do_something();".  Since the lvalue in this expression is 5, and the constant 5 doesn't have a lvalue, this causes an error when compiling, and then you remember to make it "if (x==5) do_something();"  The expression "if (x=5) do_something();" won't get caught by the compiler, and the assignment was most likely not what you want.

    Ok, I'm nitpicking, but in Java, the technique of using a constant String as the target of an equals() method call has nothing to do with lvalues.  The technique in C of putting the constant on the left side of a "==" comparison is to catch an error by putting something that isn't a valid lvalue on the left side, so the compiler can catch the mistake of using a single equals to compare.

    Ok, I shut up now.



    Actually, even my 15-year Borland TurboC 2.0 compilor complains about if(x=5)


    Warning test5.c 76: Possibly incorrect assignment in function main



    capthca "screen" much better for color-vision deprived




  • Best Buyer (unregistered) in reply to zzz123
    Anonymous:
    As of 6-8 months ago, your standard inkjet printer/scanners at Best Buy worked just fine on US bills.  I used a crisp $20 to test out half a dozen models I was considering buying.

    I had seen the documentary on a rock show promoter travelling around Illinois passing copied bills, and the comment from the Secret Service that all "modern" copiers had protections against it.  I was curious if it was true.  Maybe on bigger business copiers, but not these cheap things...



    Aaaaaand. . .   You get your mail-in rebate in crisp 20-dollar bills
  • Megamanic (unregistered) in reply to JB
    Anonymous:
    Anonymous:

    What do they do when they forget "<font color="#800080" size="4">secret</font>" as the password!?!?

    lol, i hope this guy wasn't working for the FBI or something.

    In an environment of medium or low security, i think it wouldn't be as bad if at least the words wasn't hardcoded. But there is a lot of better ways to proceed in cases of password lost.


    www.fbi.gov?backdoor=secret
    ...
    Oh shit...

  • (cs) in reply to zzz123

    zzz123:
    As of 6-8 months ago, your standard inkjet printer/scanners at Best Buy worked just fine on US bills.  I used a crisp $20 to test out half a dozen models I was considering buying.

    I had seen the documentary on a rock show promoter travelling around Illinois passing copied bills, and the comment from the Secret Service that all "modern" copiers had protections against it.  I was curious if it was true.  Maybe on bigger business copiers, but not these cheap things...

    Maybe the protections he was referring to are the hidden identification codes some printers print that allow the Secret Service to match a counterfeited bill to a printer.

    http://www.schneier.com/blog/archives/2005/10/secret_forensic.html

    BTW, if you want to use currency to evaluate a scanner-printer, it's legal to scan and print US currency as long as you make it obvious that it's not real (e.g., make it >1.5x too big and keep it one-sided).

    See http://www.rulesforuse.org/pub/index.php.

    --RA

  • (cs)

    I once worked for a place where I hardcoded my username and password into the programs.  A little before I left, I made a asp page on one of the sites http://www.example.com/about/everything.asp which was a file manager with full privs, NO auth required (talk about that security hole).  It was originally a test script I was going to build into a site management software, but it came in handy when my old partner (yeah, I was a partner) decided to change all my hardcoded usernames to "oldflobi".  Oddly enough, he didn't change my passwords, probably cause he was looking for the wrong one since I had changed them all right before I left. 

    Not that that really matters, there's a login script I wrote on a different site that emails me all failed login attemts (so I could troubleshoot if customers had a problem logging in) and every time he changes passwords for everything else, he forgets that his is hardcoded into that so I get an updated password about the 15th of each month when he changes his passwords for everything else and forgets to use his old password for that. 

  • (cs) in reply to nullptr
    Anonymous:
    not using a variable to store the result of a lookup (getParameter). Why, WHY do all crappy developers always do this?


    Apparently, they think they are improving performance by not using a temporary variable. Assuming they think, that is. Now, *of course* the compiler generates a temporary anyway, but how could they know? <sarcasm>"We're programming high-level apps, we don't need to know assembly language."</sarcasm> Sounds familiar?

  • (cs) in reply to kipthegreat
    kipthegreat:
    Anonymous:

    Hank:
    We ship products with backdoor passwords. They are 10 random digits, and only internal support knows them - we don't tell customers.

    That is a really bad idea - If I was a customer and I found out you had a backdoor I would be really, really upset.



    I agree, I hope the customers weren't concerned with security ....  There are other ways of hacking things besides a dictionary attack.  Like disassembling your binaries (which is especially easy in Java--not that I'm saying you used Java.. but if you did..).


    You mean Hank and not today's WTF, right?  Because I'd really like to know how you would disassemble the binaries of a web app.

  • LarsW (unregistered) in reply to nullptr
    Anonymous:
    Not only does he include this nastiness, but he also uses a pet peeve pattern of mine (and a consistently great indicator of a crappy developer) -- not using a variable to store the result of a lookup (getParameter). Why, WHY do all crappy developers always do this?


    He does store the result, or at least everything valuable about it, by generating an AuthorizationTicket. That object is probably stored on the servlet session. So there is really no need to keep this particular String in a variable after the request has finished processing.

    As long as the request is encrypted over HTTPS, and this system is run on a single server, I don't see this as a terrible security risk. It is defenitely BAD, but not TERRIBLE as in "hacked within 5 minutes". A dictionary attack would have to guess both the parameter (backdoor) and the password. Of course, I wouldn't trust a system like this. Too many ifs (request encrypted, no angry ex developer, no printouts in the bin, not installed anywhere else...)


  • (cs) in reply to SkyHeaven
    Anonymous:
    Maurits:


    [T]his should work null-or-not, right?

    if ("secret".equals(request.getParameter("backdoor")))


    I personally wouldn't do "secret".equals(...), but that's only because I prefer to always have the variable as the lvalue.


    An lvalue is something that can be assigned to.  So the variable is an lvalue by definition, no matter where it appears in the expression, left, right, or center.  Although if it isn't on the left, lvalue is admittedly a misnomer.

    I always write "constant".equals(variable).  But even for if (x == 7), I just write it in the natural way, not backwards.  Modern languages and even modern C compilers don't let you get away with that error (at least, not without really trying).  I think the assignment-in-if-statement is largely a myth.  I've been programming in a variety of languages since 1978, and I see all kinds of bad code including many WTFs in the codebase I'm currently maintaining on a daily basis.  And in all that time, I have never seen the infamous single-equals error in production code.

    "ROUSes?  Rodents of unusual size?  I don't believe they exist."

  • (cs) in reply to Dr. John McKittrick
    Anonymous:
    What's the big deal? We did that all the time when I worked for professor Falken on the WOPR project. As far as I know there was only one meddling kid who managed to sneak in -- and even then, it wasn't REALLY global thermal nuclear war.


    Malvin: I can't believe it, Jim. That girl's standing over there listening and you're telling him about our back doors?

    Jim Sting: [yelling] Mister Potato Head! Mister Potato Head! Back doors are not secrets!

    Malvin: Yeah, but Jim, you're giving away all our best tricks!

    Jim Sting: They're not tricks.


  • (cs) in reply to Warning!
    Anonymous:

    Actually, even my 15-year Borland TurboC 2.0 compilor complains about if(x=5)


    Warning test5.c 76: Possibly incorrect assignment in function main



    capthca "screen" much better for color-vision deprived


    Most C compilers have option to warn about that constuct and many allow to treat it as error.
    However

     if (5=x);

    is not legal C at all and every compiler fails.
    (Who Cares)

  • (cs) in reply to TicTacToe
    Anonymous:

    Anonymous:
    What's the big deal? We did that all the time when I worked for professor Falken
    on the WOPR project. As far as I know there was only one meddling kid who managed
    to sneak in -- and even then, it wasn't REALLY global thermal nuclear war. 

    Cute kid, really. 

     

    "Would you like to play a game?"



    That should have been 'Shall we play a game?'
  • David (unregistered) in reply to ferrengi
    ferrengi:
    Why does your company need you to fix these idiocies?
    Didn't your company purchase yearly maintenance together with the license to use this piece of junk program?
    Since you do not have the source code and the people who sold it to you do, why can't you submit these issues to them as bugs and get a version that works properly.
    These sound like the type of things that a lot of other clients would complain about anyway so isn't it in the seller's best interest to solve these issues?
    At my company we could never get away with telling our clients to live with these types of issues.


    They've fixed a number of issues. But I think one of them decided that having the CC processing right was complex enough to call it a feature request and not a bugfix. I guess CC processing is a new feature. It can charge cards at order time alright, anything involving preauthorization (it preauthorizes unless you charge at order time) has dire consequences. We're in our 2nd month of implementation, and there is a yearly maintenance which they'd lose if we abandoned the ERP. If the first month of implementation is always the hardest, then hopefully the worst is behind us. I sort of feel somewhat responsible for not getting more involved in the evaluation.But the things that are wrong with it are things that I never could have imagined, that we never would have asked about. Feature-wise, there were maybe 3 or 4 ERP systems out of hundreds that appeared to match the functionality we were looking for, so our choices were limited to begin with. First impressions from our evaluation were very deceiving. We did interview other users of that ERP (identified to us by competing ERP vendors) who said the system was alright.

    On the bright side, the system is extremely modular. The ERP isn't a single program, or a modest collection of programs, but over 4000 tiny standalone COBOL programs (in bytecode form), probably one program for every single dialog or process. A lot of newer features are being written in VB6.

Leave a comment on “C'mon, There's Nothing Wrong With That!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article