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.
Writing a back door is just more coding. Code for a while and see how much extraneous crap you write just for kicks.
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)?
Easy:
1) Code reviews.
2) File change diffs emailed to developer mailing list.
3) Group-owned code.
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)
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.
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.
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.
"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."
Did you ever think of what would happen if a cracker found out about such a backdoor? Just because you do your best to keep it a secret doesn't mean that crackers can't find out about it.
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!
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!
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
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.
IMHO that's unethical. Holding companies hostage is not a valid business practice, even if made crystal clear up front.
Sounds like a good way to damage your rep. Of course, if he really feels he has to do this, it may be the companies he works for don't really have great reps themselves.
Share and Enjoy!
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
People have been sucessfully sued for this practice.
Successfully sued on what grounds? "The software we stole doesn't work"?
A contract has two parts - If one party fails to fulfill their obligations, I had the understanding that the other party had no obligation to fulfil their side either.
If that does not hold true, why would ANYONE pay for ANYTHING? "Yup, you just ship me that nice new PC, I'll send a check tomorrow". Bwa-hahaha. Time to upgrade to a quad Sparc-III, yup yup yup.
Though, I will readily admit that law does not equal logic, and no doubt you can indeed point me to cases won on this very issue. I expect, however, that they would at least have some extenuating circumstances, such as the customer losing half a million transations just because the software disabled itself. (For which reason we should always add the ever popular "The author bears no responsibility for financial losses or damages resulting from the use of this program by the customer", or something to that extent).
In at at least one case, the developer was sued for loss of business and for hijacking the User's data. As far as the courts are concerned, there are already well established prcedures to follow if someone defaults on a 30 day account. Stopping someone's business so it is impossible for them to remedy the breach is not one of them.
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.
I think the customer should have the right to decide.
Random is the New Order.
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.
and you are the kind of people that I loathe and will gladly assult on the street.
I have HAD to crack software my company legally owned to keep it working after the company that wrote it went out of business and is dead and buried. company that made it is gone, software DIES... That is pure bullcrap.
Please let me know what company you work for so I can make a reccomendation to my company to NEVER EVER buy your crippleware products.
Timebombs should be 100% illegal.. it's exactly like the car dealer coming and stealing your car after you bought it. If your company's software is a LEASE then you had better say so.
Do not look at laser with remaining good eye.
should be ssh. You certainly don't want to write your own buggy backdoor. That is just schtoopidttt.
Reposession is the taking back of physical goods that were never fully owned by you. It's outlined in the loan agreement. When you buy a car with a loan, you do not fully own that car, the bank owns it, and the contract signed agrees to reposession as a method to recover if you default.
Except in the physical-goods world, you put a repossesion clause in the contract.
Mad Software: Rantings on Developing So
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' !
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.
"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
"Did you ever think of what would happen if a cracker found out about such a backdoor?"
Uhh, the backdoor password is as secure as any other. Generally they're better than the real passwords.
Oh, and they can be MD5'ed the same as any other password. So "strings" won't work.
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
I dunno what is scarier, your vision of how efficient they are, or the fact that you believe that any part of the gov't, including the NSA, has its act together to that degree.
If they end up pwning your computer, it is much more likely to be through some stupid-simple method you didn't anticipate than through some virtuoso brute-force crypto crunching. Sorta like how the most successful maliciousdarksidehackers usu achieve their goals through social engineering rather than brilliant technical hacks...
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.
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.
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.
I guess it wasn't in the contract, or the programmer would simply have sued.
His payment was promptly received.
If I were the customer, I would have sued for extortion. But that's just me. (Again, presuming the initial contract wasn't being violated.)
Sorry about the AC, can't find my rarely used ./ acname.
I love being a contractor. There are lots of benefits, but $ ain't one of them. If you want the $ then you need to make the transition from contractor to contracting company (requires steady clients).
Certain kinds of consulting also carry the big $.
In the UK I saw lots of people trying to get on the contracting 'gravy train'. Most of them were sub-par and just chasing the $. As soon as there was a blip in the market... wham! They're back looking for permie jobs 'cause all of a sudden it occurs to them that they have a mortgage to feed.
Robert Kiosaki in the book Cashflow Quadrant divides people into four broad categories:
Employees
Self-Employed
Business Owner
Investor
Each 'quadrant' has different mindsets, therefore certain personalities do better in each one. This is why you can have a CEO earning hundreds of grand a year, and still have no savings (he's a great Employee, but a crap Investor), whereas the janitor might retire a millionaire (not being paid squat diddly as an Employee, but is a good Investor).
Employees crave the security of a regular pay-check. In return for that they work hard to make other people (Business Owners and Investors (shareholders)) rich.
To succeed as a contractor (in the Self-Employed quadrant) you need to not need that security.
Becoming a contractor because you got all bitter and twisted, (or you were chasing the big $) is a good recipe for financial/emotional meltdown.
Now take your bitter friend who is successful (presumably) as a contractor. What makes him/her good in the S Quadrant and bitter about companies?
Basically it is being a Perfectionist/Do it Yourself type.
To succeed as a Business Owner, you need to be able to ask people to do something, and have them do it. Sounds easy right? Hmmm... Turns out to be pretty difficult (particularly when dealing with Prima Donna programmer types (of which I am one))
To succeed as an Investor, you need to be able to do research, and control your emotions. Being a good shopper (a) knowing when a sale is on, and (b) waiting for the sale (this is why a lot of guys would be better off letting their wives control the long term investments - because they are good shoppers).
An example is where I live, the real estate agents are all lazy scumbags. Therefore when the latest property guru breezes through town and fires everyone up, those that actually go out and start shopping around for property find that the agents are nice, but never ever ever return your calls (and yes, they're on commission... don't ask me I don't know why they aren't motivated). Most people get brassed off at this and give up. But if you think about it, its such a small hurdle to get over... Every time someone whinges to me about agents I do a little internal dance of glee because I know its making it so that those of us willing to chase them up can get all the good deals.
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
How could you have the guy locked up? He added some features to a program; that is not against the law. If you want him locked up, he would have to use these features to gain access to the computer.
Hell I added a programming language to an in-house app that we developed; should I be locked up? No one asked for the language so it must be a bad thing, and I must be punished.
You have good points...
Frankly, I think software companies _should_ be liable for their bugs, which would obviously include liability for any backdoors. This would make a huge difference in the overall security of software across the board, but the ramifications of this thinking are another subject.
You made a point about a bug being unintentional and a backdoor being intentional. I guess my point is that I don't see that clear cut of a difference. I have coded several bugs very well knowing they could possibly be exploited. However, when the whip is being cracked, one tends to sacrifice certain things. Not that this justifies it though!
What's a company going to do if and when they are brought to court due to a problem with a backdoor? Aren't they going to say they aren't liable for it because it should have been removed from the production release and is therefore a bug? This seems to be a pretty strong argument for the company to take, since in general there is no liability for software security (unless stipulated otherwise via a contract or something).
As for your particular situation with the movie industry, I don't think it's the backdoor itself that will get you into trouble, it's the fact that you've got a copy of something you shouldn't have. It doesn't matter how you got a copy of the latest movie, but that you possess such a copy. This is quite likely to be the stronger argument in court, don't you think?
You're absolutely right as for the 'deepest pockets' point, however I don't think that's exactly on topic. In as much as it pertains to a small development firm or a contractor, you're right, don't mess with the big bucks (whether M$ or the movie industry). This is good, although a bit obvious, advice.
Beware of geeks bearing formulas.
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
This is an interesting situation. If I was the
manager and had a hint that any of those backdoors
were likely intended for malicious access I would
have called this guy in and told him exactly what
was found - put it up on a projecter and review
the lines of code - for example the code allowing telnet access over an unsecured port. Then I would have warned him that if anything untoward
happens to the system - i mean if suddenly a process core dumps, the database gets corrupted - he is the first person we are going to go looking for. Then I would have fired him. The risks are too great to leave someone like this on staff.
Imagine this guy goes on to do something very costly to the business - the manager is going to be extremely responsible for letting this guy keep his job. I wouldn't take that kind of risk.
I would say cut your losses, take some economically feasible defensive actions, and then get rid of the cancer.
I'd have made him a part of the new 'code review' team, and made him explain to the group what his code was doing.
If nothing else, it would show that people were on to him, and potentially embarass him.
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.
The real lesson you needed to learn:
1. User apps should never be setuid root. Ever.
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 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.
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