|
We don't use any backdoors, although different keys can have different levels of access.
For obvious reasons I'm not going to say any more than that, other than that working on security stuff is challenging in a pretty unique way. 
Anna ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Riverblade Ltd - Software Consultancy Services
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
|
It sure is. 
In the past I've used hardware keys (Deskey DK2s) for protection, and as far as I know the software has never been cracked. That's no mean feat, seeing as most users are stuck offshore with little to do in their spare time than watch p**n or try to crack the software...
For the stuff I'm currently working on a hardware scheme wouldn't be cost effective, so we're using a software one instead. Although that's less secure, with the volume and market we're aiming for it should be more than adequate.
Using the framework we've chosen we can easily support multiple levels of keys (Standard Edition, Professional Edition etc.) without hardcoding backdoors into the code. Keys can even have additional information such as expiry dates or network licences encoded into them, which is useful!
It's proving to be an interesting experience. Now all we have to do is actually sell the thing! 
Anna ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Riverblade Ltd - Software Consultancy Services
Anna's Place | Tears and Laughter
"Be yourself - not what others think you should be"
- Marcia Graesch
"Anna's just a sexy-looking lesbian tart"
- A friend, trying to wind me up. It didn't work.
|
|
|
|
|
Anna-Jayne Metcalfe wrote:
other than that working on security stuff is challenging in a pretty unique way
Absolutely!
Assembler skills and a little bit of paranoia are sure helpful here.
Pandoras Gift #44: Hope. The one that keeps you on suffering.
aber.. "Wie gesagt, der Scheiss is' Therapie"
boost your code || Fold With Us! || sighist | doxygen
|
|
|
|
|
|
like anyone is going to truefully say exactly what. I have but outside of its context its simply boring and useless.
truth of the matter is--that like anything else--uncontrolled access in the wrong hands can be dangerous. there is no such thing as real security when it comes to software. having a back door that only the exec who ordered it, and the engineer who wrote it know about, falls under the afore mentioned methodology.
I personally have used it as a means of securing payment for trial like software (locks down where no one except the back door user can operate the app & re-activate it) from a client who was notorious for getting demowarez & never paying for their license.
/bb|[^b]{2}/
|
|
|
|
|
I actually voted 'No, not ever' but I do know of one 'backdoor' in a solution for a customer: if you enter a particular username and password, it forcibly logs everyone out. That combination doesn't actually get you into the application, though. It's basically just a 'master reset' command. There are some areas of the application where only one user is permitted to use it at a time; the secret password resets the flags which track which areas are currently locked.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I voted that option because I am the only employee. All of my pc software uses hardware keys, and there are no back doors at all. The only back door I have anywhere is on my website entry system. I have an overriding password that will log me in as anyone, but I must still use their username. That password does not allow me to do anything in the credit card area however and that requires a secured connection with separate requirements. All log-ins and attempts are recorded, so I can tell if anyone uses the override password. That password is hard coded on the server and no password ever leaves the server logic to be viewed on a client computer. If someone should figure out the password (which in 4 years no one has even tried), I can easily change it and no real harm is actually done anyway. No personal information is available with that password since all of that type of information is only recorded in the credit card area, which itself is new within the last 2 months. It simply provides me a way of using the website for tech support issues without having to use everyone's password. Nearly all the information entered in the non-secured area becomes available to all others using the site within a few weeks as well, so this password really would only give them that information a little sooner than they should have it.
That is why I chose that option, and I am the only one who knows about the password, other than all of you now. Oh well, you are not likely to be using the site, so it really doesn't matter.
Fred
|
|
|
|
|
We make systems run in a low risk environment by few users, and we know our customers well enough to recognize them over the phone.
Our login is not made as a heavy duty intruder protection, it is just meant as a way to keep curious co-workers out so they don't mess something up through mistakes.
Sometimes our users forget the password and call us. To solve this, we have made a program that, based on the system clock, generates a password that the program will accept for a full hour. An hour later, the password is old and unusable. This way, we can let them logon to change their password without trouble, and security is not dramatically compromised.
This is also a neat way for us to work when we support customer on site or if they send a copy of their system to us, since it allows us to login without them having to reveal their password (which they no doubt use in a bunch of other places).
Of course, only we have the super password generating program, and we keep it tightly secured.
The customers are aware of this possibility, so technically it's a borderline case of a backdoor. So far, no customer has disapproved, in fact they consider it very useful and they feel safer knowing that even if they screw up really bad, we can get them back in. In fact, it is probably the most popular non application specific feature in our programs apart from the cute animated login screen.
|
|
|
|
|
We have a similar program, but ours may be slightly more secure. On the login screen, a three character string is displayed that is based on the computer's hard disk volume serial number. So, when they forget their password, they just need to give us their user name and those three characters, and our program generates a password that is valid only for that user on only that machine for one day.
|
|
|
|
|
I voted partly to be tongue-in-cheek, but also to reflect what I've seen many do over the years. This should increase statistical accuracy in lieu of those who wish to remain voiceless.
Two things about human nature that are difficult to suppress:
1) Wanting to play (usually a good thing - keeps spirits up)
2) Doing things to bypass the irritation of "the system"
No one wants more frustration, so if people can bypass it, they often will. The question is why some people break security to make things easier. It's easiest to assume all such people are the problem.
Poor communication, design, and/or management are often the culprit. IT and development are often at odds, which is a sad but common situation. Aside from egos and control freaks, it's often a case of "my group wants what it wants, and doesn't care about your group's concerns". When this happens, no amount of "thou shalt not..." will completely fix the problem, since the resulting anger destroys cooperation.
The gifted manager brings such people together to resolve the issues, and the resulting fix improves everything. But when communication and/or cooperation is poor, or no such manager is in the picture, things fall apart. This is perhaps mankind's greatest organisational inadequacy.
So what happens when an otherwise good employee is caught having made a back-door, when that action was just a response to a malingering disease? With little doubt, the disease makes the obvious blame, thereby protecting itself from blame.
Why not just fix the disease? Look at 2) above (NOTE: endless loop).
Politics are unavoidable.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
