Slashdot Mirror
Do You Write Backdoors?
quaxzarron asks: "I had a recent experience where one of our group of programmers wrote backdoors on some web applications we were developing, so that he could gain access to the main hosting server when the application went live. This got me thinking about how we are dependent on the integrity of the coders for the integrity of our applications. Yet in this case a more than casual glance would allow us to identify potentially malicious code. How does this work when the clients are companies who can't perform such checks - either because they don't know how, or because the code is too large or too complex? How often do companies developing code officially sanction backdoors...even if means calling them 'security features'? How often has the Slashdot crowd put a backdoor in the code they were developing either officially or otherwise? How sustainable is the 'trust' between the developer and the client?"
I don't know about you guys, but not too many of my projects spare enough time in the project timeline to allow me to write backdoors or Easter eggs or whatever.
The last thing I'm thinking about when rushing towards the deadline is some fancy backdoor into a web app I'll probably never use anyway.
-- jimmycarter
Unless he was acting on some sort of order from you or someone else who can tell him to add something like that, I'd fire him.
I'd also look into opening a criminal investigation.
I've never coded backdoors into any software I've written. I usually don't use them in the future, and if I really need them, I gain access by other means. I can't see a logical reason to add them in, especially if you're job depends on the integrity of your code.
Writing a back door is just more coding. Code for a while and see how much extraneous crap you write just for kicks.
my code is so tight, the front door and backdoor are on the same hinge! hooah!
Only in the BBS Software, did I write backdoors, those kids never registered...had to slap their hands a bit.
But, thats not to say I lack ethics, am a cracker, or am out to get my client.
How many times have we all heard, duhh.... I forgot my admin password, but I cant reinstall, I need the data.
So yes, I backdoor, and I document it internally (hardcopy stored in a safe). Its just an extra insurance policy for when some moron that I worked for 6 years ago does something stupid.
That said, coding backdoors for the sake of getting access to a web farm so you can host your own services is certainly a bad thing(tm). But hell, what are you gonna do? Everyone backdoors. Don't believe me? Watch someone 'in the know' log in to a random windows box using the System account and come talk to me.
this has been one of the biggest arguements towards using open source software. companies can theoretically trust open source software because everyone sees the code and they can easily modify it. my question is though, even though we have the source, do people actually read the thousands and thousands of lines of code in the program they're using or just the parts that would interest them (for modifying/improvement purposes)?
Some of the apps I make have the option to "allow" a backdoor by setting a flag (default on). The client can turn it off if he/she really doesn't trust me, but in most cases they find it useful in case I ever have to bugfix the systems and/or they lose their own passwords.
I know a person who owns his own company and writes code on a for-hire basis. He puts in timed expiration code such that if they don't pay him within 30 days of delivery, his code de-activates.
Where I work, we do similar things, but our motivation is to ensure that users are always running the latest version of our frequently updated codebase. We, as developers, do have the ability to run expired code via the backdoor.
Praying for the end of your wide-awake nightmare.
Here's a list of 1090 backdoors.
"I had a recent experience where one of our group of programmers wrote backdoors on some web applications we were developing, so that he could gain access to the main hosting server when the application went live."
/Mcdonnel-Douglas embedded the F15 Eagle fighter plane with a backdoor in its computer systems so if its ever used against the USA it will strangely malfunction.
Its like that theory that BAE
Unlikely, but interesting concept all the same!
Trust and loyalty used to be my main focus... I trusted that those stock options i was offered instead of a chunk of salary would be good, and the company trusted that i would deliver good software, on-time.
I fulfilled my part of the bargain, but when it came to stock option maturity time, I got laid-off.. The company is still in business interestingly enough, and now posting profits even.
Who do you trust, and how is that trust repaid? I can tell you I no longer have the same sense of loyalty and trust in my employer. Companies are paying on average HALF of what they were for the same work 2 years ago.. Trust... works both ways or it doesn't work at all...
But when you think about it, all leaving a backdoor in a system does for you is to provide an opportunity of accessing a system in a way that you shouldn't be. This can lead to trouble down the line.
Clearly, there are legitimate uses for backdoors (to use in case of emergencies, etc.), but unless the backdoor is documented someplace for others in the software development group to be aware of, it's likely the kind of backdoor that is simply not ethical to implement, since it's only usable by one person.
I'm sure people can provide examples that disprove this, but for the majority of situations, as a developer, having a backdoor in a system can only lead to a security breach at some point ...
I am working on an app for the govt, and yes, I have programmed in a backdoor login, as it's very useful for testing and development.
However, the following are true:
1) management knows full well of its existence
2) BY DEFAULT, it is turned off in any build
3) it is NEVER to be deployed turned on
I think it's a good rule of thumb.
http://kered.org
Though it wasn't explicitely mentioned in the question, I feel that such a situation may be more common when the developers are hired as temporary / part-time help. In this case, you are a client and the developers may be looking to get something more. If you have your own in-house developers, they'll have more stake in the company and the project, and surely would care more about security - both the security of the software and the security of their job. A hired hand could code the backdoor then move on before you ever notice. Your own developers would be more hesitant to do this because if and when it gets noticed, they'll still be easily found in the cube on the third floor, east wing.
Maybe a good idea would be to bring on a full time development staff and pay them good money so they don't feel the need to try to get something more. Oh, and tell me where to send my resume once you create these new full time positions.
How are you going to keep them down on the farm once they've seen Karl Hungus?
Backdoors can be a good insurance policy, and their theoretical presence might guarentee your continued employment, but if your employers find them, I can guarentee you won't be working there for much longer :P
I work for a small startup that specializes in custom web-applications for indy record labels and small-time bands and clubs. Our main product is a all-in-one web-app that will allow the customer to manage their shows, news, mailing list and numurous other things.
We offer several levels of this product, one being shared (get 1 account on our servers) which we control, standalone, and custom standalone (the standalones go on their own servers.) The latter two are designed to have one back-door login account for myself and the other programmer to go in there and edit their settings or database if the customer breaks something.
So there is my 2 cents. Yes, I put small backdoors in my company's web-apps per boss's request.
And it lives here!
This story was just begging for this link!
I (like many of you) work on a contract basis per project, and I'm contracted to fix any problems with the software as part of the job.
If an intruder breaks into a database through a back door I put in (and let's face it, it is asking for trouble), I'm obliged to spend my valuable time closing the hole.
I'm not of the opinion that it's worth my time and money to show off what a great hacker I am - my clients are really the ones who matter, since they pay my wages, and my skills should be reflected in my work...
sig:- (wit >= sarcasm)
What really concerned me though was when we were supposed to store credit card numbers encrypted in the database and I used a simple replacement cypher as a placeholder. Then, when I later asked about putting real encryption routines in was told "we aren't going to do that".
So customers are really in the dark when it comes to the security of their software.
Rich
There shouldn't any hard-coded trust between the authors of decent software and the buyers/users of that software. The fact is that any useful information that the backdoor could provide to the coder should be available to the purchaser. If the purchaser wants to trust the coder he needs to run sshd and give the coder and account with access to the application he coded. Why anyone would "reinvent" a secure backdoor when it can be accomplished with Freely available tools to a much greater level of security is just beyond me.
Doing things like
Anyways, my point is that most backdoors put in by developers seem to be accidental rather than intentional.
C - A language that combines the speed of assembly with the ease of use of assembly.
ok, i don't think there's a backdoor, but i know windows xp comes installed with a special microsoft tech support user. how do they get to use that user to fix problems? that's what i don't understand. it's really odd i think. i wouldn't be surprised if microsoft started putting backdoors into their software that only closed when you entered a unique serial number that bounced back from an online serial number database. similar to the way Q3A uses the cd key. although i know there are some hacks to the Q3A cd key to allow you to use a pirated copy, so this may not work. i just wouldn't put it past microsoft to do something like that.
please me, have no regrets.
This thread that gotten me wondering, what sort of legal options would one have should they find an employee coding in backdoors?
Would this be considered felony fraud? The more I think about it, the more I hope so. Think about this -- one coder acting alone could cost a company millions of dollars in lost profit and trust. This would be more than that coder will probably earn in normal income thruout his entire life. I think this is one case where a jury SHOULD seriously consider decades of imprisonment. This isn't a simple case of a kid using DeCSS or defacing a website, this is case of one person destroying the image and trust of an entire company.
When I was a consultant at a Big 6 firm (back in the day), a colleague of mine wrote a Windows app for a client. He added code that would cause the application to stop working after a certain date, so that if the client doesn't pay their invoices, he won't update the code, and the app will simply stop working.
I personally considered this to be very unprofessional, and probably not legal, but he claimed that it was perfectly legit. Of course, the client didn't know this, and he never told them (they did pay their invoices on time).
Definitely not my style, but it is evidence to me that it is done on a regular basis.
The only way to guarantee that this doesn't occur is thorough code reviews.
Sorta, the only way to guarantee is to make ALL _checked_in_code_ reviewed. This is generally not a very practical alternative in any project that has real deadlines. What happens during a "code review" (a formal one anyway). People review the code, make comments and the developer(s) go off and make whatever changes. Ooops, gotta now review the code they changed.
I don't but two guys here did just that last year. It was a customer facing website for a large multi-national corporation. The "backdoor" was caught before going live but they were fired with extreme prejudice.
Speak truth to power.
I'd like to post an intelligent responce, but I need more info. Can I have some people send me a list of back doors they've created so that I can investigate further? thanks
1) if it's not in the requirements, it shouldn't be in the code
2)if it's useful or necessary, then it should be in the requirements. But it's not a back door anymore (maybe a side door?)
It's supposed to be completely automatic, but actually you have to press this button.
Putting backdoors is unethical, but possibly not illegal depending upon how you make your software available (i.e. license terms and conditions). It may only be illegal where you _use_ the backdoor (because you are then technically trespassing on property of another), or if someone else uses the backdoor (you could be held in negligence).
I've been involved in a project where an easter egg was planted (command line interface to a subsystem, and if you enter right command, it will drop into a text RPG). You could get in trouble for this in certain ways:
(a) wasting client money (if the program developed under contract and this functionality is outside of the scope of the development agreement);
(b) negligence/action if something goes wrong with the functionality or leads to lack of performance of the software, etc.
Most applications have some sort of back door.
There are different extents to back doors. For example, in some filtering programs, you get admin access. In other programs, you have the ability to log in as a remote user. In another, you can bypass the encrytion passcodes.
Having a remote access backdoor saves lots of trips to a customer site. Having a backdoor for admin access is good when they lose their passwords. Or remotely shutting down the application is good when they don't pay.
There is also the other site to consider, if there is a back door, the application is clearly less secure.
You have to balance the lack of security caused by this by the need for the features the different back doors offer.
You should tell the client about this, but then it is a problem. If you tell people about back doors, some people may try to hack it. Having the remote ability to shut down an application may defeat the purpose.
Fight Spammers!
I know that probably was a joke but.. If you think the NSA needs a key to get to your data you need to go read up on the amount of computing power they have in their hands. I recommend "Puzzle Palace" and "Body of Secrets" from James Bamford. Really interesting stuff. They could basically pick through your weak built in encryption like Rosie Odonnell picks through a rack of ribs. Their computers would literally sigh from boredom.
Didn't we learn - if your developer is complaining that he doesn't get paid enough, you'll have dinosaurs eating your customers soon enough?
Seriously, this is why every line of code is *meant* to go through proper examination by your peers. With the number of eggs and backdoors in some commercial software (*cough Excel 97 *cough*), you have to wonder...
I'm a girl too! See naked chicks in my journal!
In my experience, back doors tend to be "in the mind of the programmer" as opposed to code that was physically made to be that way. It's not that the programmer sat there and added a way to hack in-- it's just the fact that since he knows how the system works, he knows how to gain access if need be. After all, just about everything electronic can be exploited at some point.
I think you really have to consider the intent. If someone tries to go into the code and deliberately put a back door in w/o proper decision authority, that should be considered unethical. If the client wants it tighter than Fort Knox and loses the key, it's not your fault.
I have been developing software in some form or another ranging from ascii based games to multi-tier web applications, since I was 8. I'm now 30 and I can say without hesitation that even without explicitly coding a backdoor a "good" developer can get into and exploit a system of his/her own design and development simply as a result of an intimate understanding of the application and how it handles data. So the only way to really prevent this, if you were really that worried about it, would be to labotomize the developer or somehow wipe his/her memory. Cheers, Binary Air
Occasionally I have been given a task to write a piece of software and I do not have an account on the system which I am writing the software for. The backdoor is designed to make sure test is working. So I basically put in code which basically says:
If User = Me then
bypass security
else
Security/Validation
end if
This way I can test the app without having to go and validate against the system which I don't have rights to. When we move from test to production, this backdoor is left in until the client validates user acceptance test(UAT) phases, at which point a second production move is done without the offending backdoor. In otherwords the backdoor is the first UAT bug reported.
I suspect this is common for contractors.
Ted
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
No, that was the random seed used to encrypt Frontpage connections to the server.
(Kinda funny actually, someone who had to support Netscape 4.x for any length of time must have wrote it.)
However, once the phrase was found out it made it easy to start cracking the encryption. So it was removed and replaced with something else.
The guy decided to be a dick about it and not pay him the money he deserved.
Fortunately for him he put a backdoor in. He told the guy about it. Once activated the system would not work until a password only he knew was entered.
His payment was promptly received. (He got the idea from a movie.)
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
Backdoors are very hard to justify and also adds coding (as mentioned here before).
However, I've been involved in projects where we've added an easter egg.
Why? I don't know, it's fun, easy and it's cool when you can show someone that you actually was part of the development. Ofcourse, these projects were inhouse product development. I would probably not consider doing such a thing in a customer's product that I'm working with, besides, that's not what they are paying me for.
With so many clients deploying on Windows, who needs to waste time putting in a back door?
Its built right into the OS.
Cheers,
prat
The program came in handy a few times. I finally deleted it about six months later.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
A microserf friend once told me MS had no policy either way on easter eggs. They were there if programmers took the time to put them there. If an easter egg can get through development, peer-review, testing, packaging, why couldn't a backdoor?
Call it an "Administration area"
I make these: http://beatseqr.com
I heard that there's this program called Mozart's Ghost that has a little pi symbol put there by the notorious hacking group, the Praetorians. Anyway, if you click on it while holding down control-shift-back-back-forward-punch, it opens up a backdoor and your screen goes all crazy. I think it let's you hack the gibson or something.
"It's Dot Com!"
it was a variable name for a public key, not a backdoor or anything like that.
I would like you to go perform a simple experiment.
Write a "Hello World" program, where you have a static character array named "Fred" containing the string "Hello World" which you pass to printf.
Compile it.
Now, search the executable for "Hello World". You find it, right? Now search for "Fred". Funny, you get no matches. Doesn't that seem odd, considering MS's claim?
Doesn't it also seem odd that, in the context in which "NSAKey" existed, it fit perfectly in a data area containing identically-formatted key data?
read bruce schenier's column on it
Okay. Does the following quote sound familiar?
"Two, that it is actually an NSA key. If the NSA is going to use Microsoft products for classified traffic, they're going to install their own cryptography. They're not going to want to show it to anyone, not even Microsoft. They are going to want to sign their own modules. So the backup key could also be an NSA internal key, so that they could install strong cryptography on Microsoft products for their own internal use."
It would appear that Bruce did NOT claim the key only existed as a coincidence... He said it *might* result as a coincidence, or it might result from the NSA wanting to *improve* the available security for their own use (and, presumeably, to hell with the win95-using masses who fund the NSA through taxes). These do not describe the same situation.
Arguably, though, the "improved" security argument seems no less offensive to the privacy-minded. Why? Becuse, if the NSA saw a need to use super-secret-spiffy encryption for their *own* traffic, they did so due to the inherent weakness of the default crypto available (which I doubt many people would disagree with in hindsight).
So they didn't *need* a backdoor for everyone else, they needed a *lock* on the wide-open-barn-door for their own use.
The ultimate network admin tool needs HELP!
I used to work for a company that wrote billing software. Our billing app that we wrote had an easy way to get root on the billing box, via a simple exploit. Although it wasn't planned as that, it was discovered shortly after we shipped it, and was unpatched for years.
As a result of this, anyone who knew our software could get in as root to any of the servers running our billing software. I haven't worked for that company in 4 years, and I don't even think they are still around, but anyone running that billing software can be compromised (hopefully no one is still using it, but you never know).
We did have a standard user that we setup in the database as well, so we could perform maintenance, but we told them about it, and coordinated maintenance with them. That could be contrived as a back door as well though, as it did allow remote access by our company.
Cowboyneal is my backdoor.
Oh, I'm sorry, I thought this was a poll.
Which is to say, most people who went into contracting did so just because of stories like you told. They got tired of being jerked around and decided a little uncertainty and paperwork was worth getting little freedom from the corporate brain washing about team and loyalty.
Granted, many went into it because of money during the dot-com boom. They are no longer contractors now ;-)
I'm loyal--to getting the job done, according to contract, as long as I'm getting paid. I produce results, give advice, and let the customer go his own way--even if they insist on taking themselves to hell in a handbasket.
It beats getting all worked up over stupid stuff at work.
I always loved the "We're a family" line I got when people tried to get me on as a FT employee. I don't know about you, but it is usually true--and they have all the problems that families have too. They can keep them ;-)
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
I was attached to a software package that didn't have a backdoor per se, so much as an undocumented account with a password of "a" that you could not take out of the database without doing major surgery. The software also (used to, anyways) put the undocumented account BACK into the users table and and restore the specific records to their "default state".
Savvier customers changed the username and password (the rule required the user_id entry to stay in the db. But you could change the username/pass to keep undesirables out of the system. Yet many of the customers didn't ever even officially "discover" it... Before I left I never heard of any malicious things being done with this account, but as I told my boss the day I found out about it, "Its only a matter of time."
I left when everybody around me started getting ".com" fever. Like, wacky. People who made $50k annually were leveraging a fortune in paper stock options to buy brand new Mercedes Benzes and hot tubs...
Who did what now?
the facts are:
As to giving the customers the source code, I remember doing that in the mid-'90s before it was fashionable, and having their "computer people" continuously removing it from corporate systems because it wasn't on the "list of approved programs".
I work for a small web company developing web apps for other small-to-medium sized companies. The one thing that you learn when you're in a small software company is that nobody wants to pay their bills.
This is hard to see from a large-company perspective, because as a developer you aren't the one collecting the money, you have accountants and lawyers and rabid CEOs that make sure you get your contract's worth one way or another. But small companies don't have this option--they can't afford lawyers or even the time to spend in court. They have to find where their next paycheck is coming from.
As a result, many of our clients have tried to jerk us around by either dragging their heels on payments or doing something underhanded like changing passwords to servers to try to lock us out and give us the finger. There have been instances where I've sent out a "it's all done, check it out" email and had the live server's passwords changed on me minutes later, follwed by a "we're not paying" response.
Simply put, backdoors are a small company's only assurance that it will be paid for the work it has done. Given, the backdoors that I put in aren't to r00t the server or take down a whole subnet, they're limited to disabling the application that we developed. Until the client has paid their bills, it's still our code, and we have every right to put in as many backdoors as we want.
--My other sig is a ferrari.
Dear Backdoor,
I'm sorry I haven't written in so long, but you know how busy things get. Maybe it's time for us to move on. I've found this great credit card database that uses default passwords. What can I say, it has so much more to offer.
Yours truly...
In the past, I've included "secret" passwords at the request of the people who'd be going to the customer sites to help out. Often times you'd find the customer wasn't around to tell you their password when you needed to quickly get in and look at or fix something. I coded a fancy algorithm where password was dynamic based on the day of the week and the month name, but our field circus guys found it too hard to remember the algorith, so I was forced to change it to "*", which I considered very dangerous.
Another time, we had a one line message window - if you sent a message with a severity of 'w','e','s' (for warning, error, and severe respectively), the message would stay for progressively longer amounts of time before the next message could wipe it out, and it would flash different colours and beep for the more severe ones. For message type 'i' (information) it would immediately be replaced by any subsequent messages. Once when it was late at night and I was getting a bit punch drunk, I made one branch of the program put out the 'i' message "How the fuck did that happen?" followed immediately by a more informative 'e' message. Nobody ever saw the 'i' message, because it was replaced so quickly. Until one day when somebody put a scroll bar on the message window so you could scroll back and see previous message. I got a call from a trade show requesting an immediate patch. Ooops. That's the closest I've ever come to putting in an "easter egg".
I think putting in secret backdoors to get access without telling your superiors is very bad news, and could quite easily get you fired.
The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
not put backdoors in the software they create. I look at this way, give the client what they want and don't worry about anything else.
Why open yourself up to potentially losing a client or just looking like an asshole just so you can do something that your client probably doesn't want you to do.
What happens when someone else find your back door and exploits it? What do you tell your client when they ask you about why there is a back door into their application?
It is quite possible that you will get sued. Aside from losing your business you will lose any integrity and should be ashamed of yourself for disrespecting your profession.
Good programmers are ethical and do what they are told.
LoRider
and the one to which "kt" refers is described here. Truly ingenious. Even looking at every part of the source yourself can't protect you in a case like that.
- Codes we share amongst ourselves (dev team and with the testers) get out. This is obvious.
- Some codes that I do not share amongst the team got out. And these are complicated as HELL. Like doing a series of things in the game and it having another effect minutes later that you must also know to activate. I show just a few people that these things are even possible, without sharing how. (Yes it's fun to feel cool.)
- Some codes that others added that I do not know about show up in public.
Conclusions: No backdoor is safe. Once released (or delivered), the code is in the hands of the enemy. Period.Corollary: People have way more time on their hands than they should.
1st, when I leave a company that I don't like or a company harms me - I consider that their "punishment" is not having the best man for the job - a backdoor would nullify this high ground and proove that I wasn't the best man for the job. And if a company is good to me, or I like them - than these are the last people in the world I would want to harm or compromize - so either way, it's just plain a poor way of living.
2nd, I don't know about you, but I worked on more than my fair share of projects where I could tell that the core was written badly, but didn't have the time, resources, or approval to do it the right way myself. There are plenty of things that could go wrong that I can get blamed for even if I do everything right, the last thing I want to do is add something else that can go wrong. No thanks!
3rd, I want denyability. When I leave a company, I want them to change the passwords, delete accounts, and for the code to be secure. The last thing I want is some breakin or failure put back on me years after the fact. There are plenty of shortcommings in life that can "catch up" with you, even if you do your darndest to be perfict. The last thing in the world I want to do is add some more to that pile.
4th, I rely on these people for contacts, reference, and refferals. Why risk burning bridges when I don't half too. Why risk a job when if I don't want it I am free to quit. If you don't like a company, why risk going to jail for them. If I must risk going to jail, I would much rather it be for a cause I believe in like that lady who refused to go to the back of the bus.
Not All Backdoors Are Nefarious.
I was a senior software engineer at Whistle Communications, and later at IBM, for the Whistle InterJet/IBM Web Connections products. I did most of the last generation of email, user account management, mailing list, internal database, and other infrastructure services for the product.
This product has back doors. But they are all explicitly guarded.
From the front panel of the InterJet, you can enable remote management, for a short period of time. This allows a tier 1 support representative to help you configure/maintain your InterJet, while you are on the phone with them.
This required explicit customer consent for remote Web UI based administration.
From the Web UI, if you are logged in as "Admin", there are "secret URLs", which you can use to obtain raw access to the configuration database for much of the InterJet: all of the parts I personally wrote, and some of the rest of it, where the engineers used the standard APIs we had agreed upon for user interface and common configuration store code. This was done to work around the Web UI design, which failed to expose many useful features of the product, which we engineers knew would result in customers inability to use the product as it had been sold to them. It was likewise useful for tier 2 support, to avoid engineering escalations.
This required explicit customer consent for remote Web UI based administration.
Also from the front panel of the InterJet, you can enable "telnet mode". This was done by going to a particular configuration screen on the front panel, and entering a "T" (for "Telnet") on the front panel keypad at that screen. A time limited ability for a remote engineer to come in and manually access the system to diagnose and treat engineering escalations was thereby enabled.
This required explicit customer consent for remote shell based administration.
In addition, this mode only worked from a specific netblock of IP addresses.
Once in at the shell, it was possible for an engineer to force any of these protections. It was common practice for a persistant problem to leave the remote access for engineers open until the problem was verified to be resolved.
There was also a "magic" front panel sequence that would permit you to play "Pong" on the LCD display. I filed a sev-1 bug ("total loss of functionality") against the maintainer, because it did not support "Skunks" (scores of 7-0) as a victory condition. 8-).
All of them were under direct user control, in terms of outside access.
None of these are "proprietary" or "confidential", they just aren't useful to people without documentation.
Other than working around the Web UI designer's intent, with the second back door, none of these really qualifies as nefarious (I would argue that working around the Web UI designers intent qualifies as "routing around the damage").
-- Terry
Yeah and there was like a WAR or something because of the GAMES. Then to stop the WAR he had to play GAMES with the computer.
I think it was called, "The Bus that Couldnt Slow Down".
I don't need no instructions to know how to rock!!!!
should be ssh. You certainly don't want to write your own buggy backdoor. That is just schtoopidttt.
If a back door is exploited and the company looses lots of money, etc... They simply go through their source integrity system and hold the coder partially responsible... Even if the programmer no longer works for the company...
It's responsibility...
But then again this country's general populace doesn't accept the concept of responsibility... Just look at the number of stupid lawsuits that are out there and the number of criminals that have gotten off with a good lawyer...
my 2 cents
Back in the days of GOD (Good Ol' DOS) the variable memory need would grow too large for that reserved, needing tweaking. Or a scratch database would get corrupt from a hardware failure.
Almost all things that could go wrong could be corrected without having to tear the code apart...because it always worked in my development systems; it only broke in production environments. The "backdoors" proved invaluable for tending to the screwups of the DEUs (Defective End Users :)- example: one of my clients had forgotten to use the AR functions and had literally MILLIONS of dollars owed to them in the system (only), all because they never entered checks received. Arghhh!
db
Cig:
ôô
my favorite backdoors are not those that are obvious, but those that could be passed for a simple programming error... buffer overflow..etc
In fact, sociopaths are a minority
Sort of a tautologous statement, wouldn't you say? I mean, once they are in the majority, then their behavior is called custom right?
I would have to say that explosives are the most abused technology in all of history.
Writing backdoors is an extremely stupid and dangerous thing to do.
Obviously you take the risk to get fired on the spot. But of far greater risk is your liability. What if your backdoor causes (unexpected) damage to the company? Do you have the pockets to make up for that? Because you can rest assured they will be knocking at your (front) door.
If you have to write a backdoor for 'good' reasons, make sure the company is aware of it, and there should be no problems at all.
The 'putting in a backdoor to make sure a customer pays in time' is stupid as well. If someone writes software for me and comes back with an 'update' after we pay that removes a backdoor, that was exactly the last time that person would work for me.
In fact, that programmer would have signed a contract that specifically states that we do not allow backdoors, but I guess not all companies think of that... Regardless, that programmer has wasted the company's time, with all sorts of (legal) consequences.
As a lawyer and developer, I'd say back doors etc. may work for payment insurance as a practical matter, but if it comes to a legal push and shove, one might best have the explicit right in one's contract and/or have a good layer on board-- one conversant with the idea of consequential damages.
What about all the great P2P software out there? There are alot of people downlaoding what they think is safe software, but how many back doors are in cracked software of the internet?
just a thought...
I would never write backdoors in my own programs, because I like to use my own programs and if there is a backdoor in it I woulnd't trust it.
It's like the novell tools for networking... many of novell's tools were just against their own network.
Novell had a backdoor in case the supervisor forgot the password. This was the worst possible thing thing they did... It was so easy getting control of the network a child could do it... and then install further backdoors and login/password registration programs.
The story about the F15's having a malfunction in case war breaks out is ridicolous... what do you think will happen when the enemy finds out how this backdoor works... then USA's F15's will be worthless...
Same thing goes ofcourse for newer plans...
My point is: 'any backdoor can be used against you' !
I have been pondering the implications of this type of thing for a while now. I am currently building in a backdoor AND telling the user about it. You can read more of the discussion here:
Remote Code Hosting
www.jmagar.com
-
Such an organisation is likely to have "change control" procedures to protect against the all-too-common production outages caused by careless upgrades/installations. These procedures may entail mandatory delays, sign-offs, handing over to sys admin staff, etc.
For a developer, these well-intentioned controls can feel like an obstacle preventing him from doing his job of providing working applications to his company's users. This is particularly likely if the rules are created and enforced by remote levels of management.
In such cases, there are a whole range of "features" which can be added, more or less openly, to an application to make it easier to correct problems and make adjustments without going through the painful ISO9000-style bureaucracy. The developers may not even think of them as "backdoors", but that's what they can amount to in practice.
To take a ridiculous example, someone I know was instructed to develop an application that parsed and interpreted a subset of Java at runtime for certain aspects of program logic. When he pointed out that it would be easier and more reliable to dynamically load real .class files, he was told that that was no good as the class files would be "executables" and therefore need a formal software change notice, but the slapped-together interpreter would be reading "config files" which could be changed more easily. The manager in charge of the project, of course, was several layers below the managers that dictated the procedures, and found it easier to design round the restrictions than to change them.
I was working for a company that went belly-up around 9/11. I was one of the few people kept on as a contractor, but I wasn't guaranteed that I would be paid. The product was going to be installed at a single (large) client. I put in a simple check to exit with an error message if the app was run past a date a few months in the future. I planned on eventually taking it out if all went well.
I was at least a little clever in how I put it in; didn't make the check too obvious. But our source control system gave me away (I knew it would, but I wasn't trying to be that secure). I've wondered though, how difficult it would be to plant the change in a much older version of the source file. We were using SourceSafe, but I've never looked into the format of the actual files or how that would be done.
I have never been asked to write a back door, but I have been asked write code to covertly send us reports about how the customer is using our software. The motovation behind this is that our software (Health Care) is price based on the 'number of lives' covered by our system.
My response was that I could do this, but that I thought that doing this without notfying the customer that it was being done was wrong. Stangely enough they did not argue with me, and as far as I know it has not been done.
"How sustainable is the 'trust' between the developer and the client?"
Trust? Who needs trust when there are contracts?
I don't really care if the person coding my project puts in a backdoor if I can sue them into oblivion when it's discovered/used.
-R
- First, target a specific program and specific language construct and modify the compiler code for a corresponding malicious actions (trojans).
- Then, compile this tainted source to get a tainted binary and install it as the official compiler.
- Then, remove the trojan(s) from the original source code of the compiler and the trageted program and compile it with the Trojan binary. The Trojan-ridden compiler will insert trojans into clean source, with no traces in source anywhere.
I also heard unconfirmed reports that he actually did this, but somebody please tell me if you know.I am not aware enough about the code legacy of GNU/Linux, but is all the code in the GNU system from scratch? Does it legacy need to be checked for backdoors or are we to rely on a chain of trust?
Wouldn't the better option be to make your application expire a certain number of days after installation UNLESS a code is entered? The theory being that when you recive payment, you provide the code.
The outcome for you is the same. If you don't get paid, the system locks them out. The outcome for the client is that honest, paying clients don't have hidden (exploitable) backdoors living in their deployed system.
I don't really care if the person coding my project puts in a backdoor if I can sue them into oblivion when it's discovered/used.
If the damage the backdoor can do to you will cost you more than you could hope to recover from them by "suing them into oblivion," you'd be well served care a lot.
.sig: file not found
Really? The computers would literally sigh from boredom? Since when do computers literally sigh? Or feel boredom? "Literally" is not to be used for emphasis; especially when you're applying it to something you mean figuratively.
Most of these comments do not particularly apply to "the web" as, in my mind, a web browser is just another interface surface (like a printer or a live screen) and the IO parts of a program are only the surface.
During the construction of a program I almost always end up writing a test harness for each significant module. Where possible I like to include the test harness inside the library for that module.
I then, when assembling the final product, do compile time control of whether the target application does, or does not, have the hooks to branch into the test harnesses. When an application ehxibits an error that doesn't have a clear source origin I switch to the "debugging version" of a product and that brings in a fully-featured set of back doors and hacks. Clearly the dubugging version is not suitable for production.
That having been said.
A certian lazyness on the part of the developers combined with a sloppy mind set being promulgated by the "I can drag and I can drop so I am a programmer" school of language-constructors, debuggers, and IDEs, has led to a plague of escaped code.
A primary example of these escapes are "cheat codes" in games. Now days, you can't even expect to sell a game at all unless it is rife with cehat codes you can include in the book. These are the "send a message to all from the console saying "I Am Rich" and you will get $100,000 credits at the start of your next (event)" things. They clearly exist so that the developers can go in and exercise the extreme limits of their design but then they are never disabled later for the production release.
This is dumb and annoying in games. In "real" applications this is potentially catostrophic.
But the "whats good for bob is goog dor ted" mentality causes the cheating haxor kiddies, who have seen these back channels as required parts of every program they have used growing up (e.g. the games) and now somehow think such things *BELONG* in code.
Any culture that teaches kids to just use the cheats (the cheat codes are even commonly printed in the manuals now, and then *explained* in detail in the walkthrough & cheat book you can buy seperately) and that any program without those cheats is probably trash, should not be surprised that when those kids enter the workforce they will, as a matter of self-pride include such things in the code they then write.
(Example: my room mate is 12 years younger than I. He can't function in a game, or at least "can't enjoy" a game, unless he has got the FAQ and walkthrough around "just in case." What has he learned from life about "working it out himself?" and what should that teach the rest of us?)
Test harnesses are necessary for development.
They should be expunged from production code.
Programmers should *know* *how* to write code that doesn't change core behavior when you take out the test harnesses.
Games and toys should not be an exception as that sets bad habbits.
===
We are all doomed...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Would you feel better if it was a radio button or or slider rather than a clickable button? Also, it is about as malacious as Winamp, in that you have to allow it to phone home, and you can choose to allow it to report anonymous statistics (just like winamp). I don't see people with pitchforks calling for nullsoft's (er... AOL i guess) heads.
Doubtful. A backdoor is never needed. There's no backdoor to losing the Administrator password on an NT box, yet you can reset it with physical access. Would people be thankfull if there was one? I doubt it, you'd probably have an ape shit.
You are the epitomy of what is wrong with many developers today. You hate your users with a passion much like some land owner has towards his 'peasant' workers. Grow up, listen to your users, respect them and advise them, and with all honesty work towards middle ground.
-malakai
-Malakai
A Dragon Lives in my Garage
Here is something to think about, at my last job, we ran a very popular piece of software that is used to track and manage student loans for our financial aid department. One of our financial aid reps was having problems with her peecee and I sent out one of our IT support guys who was a full time student and part-time employee. He ended up calling the support desk for the piece of software in question and the rep gave him a backdoor account that was full access right over the phone. Luckily for me, the kid was honest and came back and told us about it. We all had a laugh that such an important piece of software could be compromised so easily and the support rep didn't even think twice about giving info on the backdoor to a student. Just to be safe, I periodically checked that student's account and made sure no phony changes were made. The more I thought about it, the more paranoid I became. I talked to my boss (the IT Director at the college) and found out that we really didn't have any choice in the matter, that piece of software was the only one like it. Thankfully, I don't work there any more, and I don't think the problem was ever exploited, but I wouldn't be surprised if I ever read about it. I won't divulge the information about the backdoor, but I will say that the software in question is called WhizKid and there may be college employees here on Slashdot that are familiar with it.
I was subcontracted to build a Delphi app for some other folks. The payment was going to be some pocket change up front and then a percent of sales.
Paranoid that the minute I gave them the program it was going to turn into "Mooman? We never heard of no Mooman" and screw me from the sales, I made a backdoor/easter egg: While the splash screen was showing, if you type m-o-o, the splash would change to information about my little company.
Since the people I was providing the code to weren't Delphi folks, I figured it was a safe CYA to make sure that I got credit where it was due...
I also wrote a perl-based self-registration CGI for them too, and in it I set up a backdoor just so I could get the count of the number of registrations.. Again, just to keep 'em honest.
Not malicious by any stretch but I feel completely justified in what I did...
In the Portland, Ore area and like card games? Check out: http://groups.yahoo.com/group/portlandgames/
Maybe it's just because I work for a defense contractor, but putting deliberate (security) backdoors in programs has never even really crossed my mind. Even with unclassified systems, it'd probably mean the end of my career. Or at the very least, it'd cost me my job and my security clearance.
That's not to say I haven't put some undocumented features in place, just not ones that deliberately compromise security. They're simple debugging tools - an extra URI parameter that makes an ASP page report (in HTML comments) SQL statements executed and profiles execution times.
Maybe the mindset is different in the commercial world, but here it's a given that someone else will be responsible for your code someday, that there are many eyes watching for things that don't belong.
People get this cloak and dagger impression of security in the military... I don't think that fits at all. It's all about paperwork and documentation and following procedures and regulations. Yeah, I've got a security clearance, but I avoid having to mess with classified stuff whenever possible. In truth, most of it's pretty boring stuff, and it's a pain in the ass to deal with.
The bottom line is that all of us here take too much pride in the quality of our work to deliberately compromise it.
Interesting question... I have never and would never build a back-door into anything I code, unless it was approved and well-documented (some clients might want it).
But, on the other hand, I have build Easter Eggs into systems I've written. One system that is used by thousands of users at my current employer has a silly little Snake game in DHTML if you find it, another high-volume system has Blackjack built-in.
Neither has ever been found, but I have told a number of people, including the managers that sponsored the projects, about them (after the systems were deployed). They didn't seem to mind too much (looked at me kind of funny, but didn't really bitch).
The question... is THAT ok? I know probably most big-time sofware has eggs, but as a matter of course, should it be acceptable, or is it generally unacceptable like back doors seem to be, judging by the general tone of the responses here?
Many of the same arguments apply, such as extra code that could break and put blame on you... They might even be exploitable as security risks if really pooly written... And of course, it most probably was NOT in the client's requirements, so should you do it, even if your intention is not nefarious (mine certainly weren't).
I don't know, I'm kind of torn now that I think about it. I've done it before and didn't think twice, not so sure I would in the future though. Thoughts?
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Embedded applications are the worst place ever to place backdoors. Need I point out the Alcatel DSL modem issues caused by default passwords and backdoors for Cable providers?
At least on a computer, upgrading the software or replacing it is easy. In a fix environment, it's very bad to have any kind of insecurity.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
I don't usually respond to troll acs but I'll bite this time just for "kicks":
"Literally" is not to be used for emphasis; especially when you're applying it to something you mean figuratively.
Kind of like: I'd like to figuratively put my foot up your ass?
If meant it as a jab, a funny, a laugh, a quick haha. I guess you get your kicks in other places. Like in your ass for instance. Oh wait, not actually in your ass. Just figuratively.
I'm not kidding. I work for a major software publisher (who will remain anonymous so that I can keep my job) who as part of our annual design process include a design specification for an easter egg in the product. Even QA spends time testing the easter egg.
A good example is a web-based app I developed for our intranet. We were having trouble debugging customers problems with it (normally PEBCAK - and we'd get useless reports back from customers, and be unable to replicate the problem since we couldn't log in as them).
So, we created a method whereby an administrator could log in as any non-administrator user by supplying the non-admin username and using their own admin password (on a page separate to the normal page). No global master password. One-way encryption of passwords.
When someone logged in this way it was logged to the database that the customer was being spoofed (and by whom) - audit trail. Once the login check had passed the admin could act as if they were that user.
This was considerably more secure for the customer than asking for the customer's password and telling them to "change it later" (which was what we'd had to do previously).
This became an official feature of the app - albeit a not-very-well-known one. To use it you had to have superuser access - which usually meant that you had direct access to the back-end database anyway.
This reduced the time required to deal with problems by a massive amount.
The NSA, interestingly enough, measures their computing power in acres. Yes, not Megahertz or flops or anything lik e that. They measure their computing power in terms of how many acres of computers they have. I think the current value is several thousand acres of computing power.
Depending on what you use, I'll go out on a limb and say the NSA can't break it. 256-bit AES? Gotta say no to that. 256 bit Blowfish? Nope. 256-bit Twofish? Nope again. The NSA doesn't have enough brute force power to break those algorithms. It'd be much easier and cheaper to use something like rubber-hose cryptanalysis.
As for weak encryption, well, anyone can break that. Check sci.crypt sometime and see how many people show off their ciphers, only to have them broken within the day.
Some years ago I worked for a really big telecom firm shipping POTS telco equipment to almost all countries in the world. We had this really smart guy who was working with a command module (a module that receives the CLI command the operator would type to configure something). During system test, one of our testers saw something in the code which looked really weired. It was not really weired but the code in this particular piece of code did something which wasn't obvious. The tester tried to enter a commad which excercised that particular piece of statements. Nothing happend. After a while he discovered this code was dependant on a specific type of hardware configuration. After this was set up he tried again to fire off the command. The reply was:
Perre was here!
(his name was Per, Perre is slang). He was sent to the boss and he had to take it away. But I actually think this code got out to customers. If Per reads this you might wanna fill in what really happend at Ludde's office.
And how does that differ from normal prejudice?
There is compliant disposition of employment and then there is non-compliant disposition. Picture a couple of burly security guards with an empty cardboard box explaining to you that you need to turn in your security credentials and pack your personal possessions under supervision during the next 5 minutes before being "escorted" off of the premises.
Contrast that with the picture of a large party being thrown in your name as you complete your "two weeks notice" into early retirement for a job well done after a career of successes.
Speak truth to power.
We all witnessed Admiral Kirk leveraging the ultimate backdoor in Wrath of Kahn!
If it's a good enough programming practice for the United Federation of Planets, it's good enough for me.
We should never forget that the first big Internet worm spread itself largely though a back door written into sendmail. The author, Eric Allman, deliberately put in two backdoors as SMTP commands, "DEBUG" and "WIZ", one of which (DEBUG) was used by Robert Morris's worm. While Google can't seem to locate it, there was a contemporary statement by Allman that the reason for those two commands was a Berkeley sysadmin who wouldn't give him privileges to update sendmail, so he did it himself, the hard way.
Anyone who writes a backdoor should be fired ASAP and the door should be closed. Failing to do so can easily make your company liable for damages caused by someone using it. It's a miracle that Allman didn't get prosecuted with Morris - he probably would today, but the legal folks were more clueless about computing risks in those days.
I saw first hand how back dooring software could provide job security for one developer.
I worked at a company that produced some very complex financial and utilities management software. They needed a way to have these two applications talk to each other and their solution was a daemon to act as a conduit between the two. Since it had to assume user privs the daemon was set to run root suid.
The code had been in production for quite some time when it was assigned to developer to maintain. The code was a mess (it had been written originally by people unfamiliar with programming in the Un*x environment). The developer was tasked with cleaning up the code if he could. Since they were very busy there was little or no supervision over him. As long as the daemon worked everyone was happy.
Eventually the development department decided to restructure and investigated letting this guy go. He had a reputation of being a bit of a hacker so they came to me (I being the Un*x/Network admin at the time) to see how we might protect ourselves from reprisals should he be let go.
I was fairly confident that my systems were tight. The biggest weakness as I saw it was this daemon. So I checked out the source code and started going through it. As I did, I discovered that this simple daemon had developed some new and interesting features. Along with it's normal duties, it also doubled as a telnet daemon (you could telnet to the listening port and login just as in telnet - except this one would ignore /etc/securetty thus allowing remote root logins over an
unencrypted protocol). Another feature was it's ability to tunnel other
ports through it's own listening port.
The code was too convoluted for me to get a complete grasp on it in the time alloted. I went back to the VP of development, pointed out what I had found, and suggested that he would need to have every piece of code this guy had worked on audited to make sure it was clear of back doors. He visibly paled. The developer in question had been there for over 5 years by this point and had touched nearly everything at one time or another.
In the end they simply moved him to another department (he is still there as far as I know). They felt it was too cost prohibitive (and dangerous) to let him go.
They never did tell their customers about these gaping security holes either.
Lessons learned:
Backdoors are coded for a reason. Obviously, the job didn't call for it. Call the FBI. You are not equipped to discern whether it was inconsequential. That backdoor served a purpose.
.com'd running as a pay-for-service business.
Nextime, structure your coding away from needing "trust" and "detrimental reliance".
Backstory: I had an entire project move off-shore through a backdoor via a coder. The project reappeared *whole* complete with the project application and name
What my friend meant was that it usually takes a good amount of bitterness to make anyone consider contracting. It's a scary step and most are intimidated by their manager's comments about "contractors have no benefits".
That's all it meant--i.e. "perhaps you are now bitter enough to take a risk". But what you said still applies. I had many friends who were bitter enough to give it a try. Only one friend of mine did and is still doing it.
My comment was the same thing: if you feel that betrayed, realize there are other options.
As for me, I did it because I was fed up with flushing my life down the drain in salaried positions. When I get paid by the hour, I find I get more equitable treatment. Employers *think* about what they want me to work on. And usually they are more serious--since my time equals money in a very easy to use formula. And I don't feel like I am being cheated when I get a heavy work load--more hours equals more compensation.
Less pay or not, salary is for suckers. Even if contracting is making half the money, right now pay is down across the board and salaried employees are being asked to work twice the hours. So do the math.
(OTOH, during the dotcom days, I made some serious money. Ah, things will never be like that again *g*)
For me, contracting is about quality of life--as in, I have one now.
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
--main reason I am against computerised voting. I'd bet a LOT there's all sortsa nifty "features" in the code that got "reviewed" and judged "ok".
But, it's just so gosh darn conveninet to have the computer vote for me! And it's so modern and techy trendy! And "they" wouldn't do anything to affect a vote would they? I mean it's not like anything as important as control of a state or the world's most powerful country is actually enough motive and incentive for the nice people at E-VOTIN'TECH.con Inc. to do naughty things, is it?
Nawww-never happen in a billyun years, people are all honest, rilly and trully!
Why? Because I REALLY do not like to lose. If I ever got screwed by a client, they would stand to lose more than me.
Have I ever USED one of my backdoors? Only once in over 24 years of working with computers. I wrote a program for a college professor who then turned around, changed the opening banner/credits/logon page to HIS name, and then sold it to the college as his own work. I went in, changed the page back, blew away the user and password file, and disabled the logon sequence. Everyone on the college's staff who had a computer got to see what I said about him the next morning when they tried to log on.
A few weeks later, after all the shit was through flying, I gave the college the program for free. Along with the source code (Open source circa 1979!).
The number 1 problem of working in a cubicle - 23 power cords, 1 outlet...
You're right, how could I be so ignorant of important PC issues of the day?! You've helped me to decide: I'm leaving computers and the software industry to take up a peaceful life of contemplation. Living off the land, pumping my own water, harvesting crops. I'm obviously a failure as a technologist, so I must find an ecosystem I can truly integrate with.
-If
PS: I USE the NET, and pay attention to it all the time, so I don't know what you are implying.
Run a pencil-and-paper RPG campaign with your far-off friends: Gametable!
Their computers would literally sigh from boredom.
Literally? I'd pay to see that.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
The less sophisticated customers would never authorize anything like that until and unless they were in a panic, so we learned to pre-install it. In general, saving the customer from himself is necessary to maintain good customer relations, and is probably the origin of the term "Customer Engineering".
I18N == Intergalacticization
But I don't remember the guy's name. Or maybe it was a chick. But whoever it was, they were definitely a staid and steadfast compiler writer.
It's that simple. The client has to trust the developer, and if that developer gets caught doing something malicious, it goes into 'big news' and that coder just lost his career.
/. and I mean, "IMAGINE A BEOWOLF CLUSTER OF THESE," ok enough :)
Just my $.02
P.S. I can't resist blabbing here how this problem might vaporize if everyone wrote 100% GPL code and had that code analysed by many eyes... after all this is
Sigs pose an operational security risk and help the baddies aggregate data. I guess commenting does too, oops.
Peer reviewing has several advantages in a commercial environment:
Ensure the code is correct, ie no obvious errors that will come and hit us during acceptance and therefore hit our bottom line
Ensure the code is efficient and well written, at the end of the day, when the project is completed, the client takes ownership of the code. It's its badly written, this could impact repeat buisness
Ensure the developers are not putting 'back doors' in. On a large development project, you should have a development environment and a seperate acceptance environment mirroring the production environment. Developers should never get anywhere near production testing code.
Peer reviews can help sell your company, if the client needs to be assured that you will develop quality code, then the peer reviewing concept will work in your favour.
/. posting.
Developers placing 'Easter Eggs' and 'Backdoors' in programs to me suggests poor management by their team leaders / project leaders / project managers. If legitimate back end access is required, by personnel authorised to perform it, then a mechanism that the client is aware of should be used such as a troubleshooter logon / password.
Just my 2 cents on my first
I was working on a small custom db (in c, way back in the PC dark ages)that was going to hold confidential data, and had a simple user login coded up. Management insisted on putting in a back-door because past experience indicated that a few times a year a customer would ask us to "recover" a lost password. The back door was used to get into the system as an admin and reset the other user passwords for customers.
Anarchists never rule
I don't like backdoors since they create all kinds of security leaks. If you properly test your system before going live you don't need a back door to debug.
BUT once I was asked by one of my bosses to put a backdoor in a system. The client was getting very hard assed about paying the money he owed the company for the development of the system. Inside sources warned us that the client is going to grab our software and cancel the contract.
What happened? We installed the system and sure enough the client told us a week later to go stuff ourselves. hehe a few clicks and what do you know the program suddenly developed a few 'bugs'. To this day the client never knew what hit him but it only took two days before we were back on the job with a bank balance the way it should be. The 8 hours of effort putting in a backdoor sure as hell beat the hundreds of hours in a court.
I've made it easy to disable security on development versions of systems I've written, just to spare myself the pain of logging in every time I bounce the web server to reload my .jsps, but I have zero interest in letting a real "back door" go into production. I'm not sure why. Fear of getting caught is somewhere on the list, but pride in putting out the best, most secure system I know how to make is a lot more important. In my current job I'm playing with real people's real money. Who cares if my company screws me over some day? I still don't want to make it easy to screw over some poor AOL-connected grandmother who pays her bill using my system.
I guess what trumps it all is that code with a back door is less elegant than code without, from a standpoint of efficiency. Lines coded versus purpose accomplished. So in my book, it's no back doors because of 1) Aesthetics, 2) Pride 3) Fear of getting caught.
Don't do it.
During development, sure. Get the underlying logic and interface working, then plug in the authentication. If the final product has a back door, that's like selling locks are, undisclosedly, set up with a master key, which you posess. /, replace or edit the file, reboot normally).
Of course, you want to permit the owner to uninstall the lock if he loses the key... or just wants to disable security, if he thinks that's safe. Same with software. Put the authentication in a discrete file, so the person posessing the system running it can bypass the application to set up newly-defined security, just like the unix password files.(boot to access the partition containing