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
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)?
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.
If you designed a system that you personally can break into, then you didn't put enough thought into the security design.
I personally think it's my responsibility to AT LEAST make sure that I couldn't break into the systems that I build without having knowledge of the passwords or whatever. If I think of a way that I could get in without it, I fix it or contact the person currently responsible for the code and let them know about it and how I think it should be fixed.
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.
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.