|
I was asked to analyze an application and inject some malicious piece of code that would allow spying on incoming data and altering outgoing data, I played dumb and said no one on earth is capable of doing such thing, the idiot manager believed me (or perhaps they were afraid I would report them since that was clear case of fraud at least)
|
|
|
|
|
We only have read only access the production database at a client. I was tempted to put in a backdoor to get the connection string for full access so I can fix things in an emergency, but decided against it. If they found out or something went wrong there would be big trouble and I could get fired. It would have been easy though, we make the builds and they deploy them. They assume what gets built is what's in source control, but it may not be the case. They should have an automated build and deployment system to prevent it. Using ILSpy would reveal the backdoor though, if there was one.
|
|
|
|
|
My neighbouring team was asked to include a logger of the number of times the software has been invoked. The management said that this is for billing purposes. Not sure whether the end customer knew this.
|
|
|
|
|
I am not sure if that would be called as a backdoor. I would categorize this more on product usage data collection (surely, this could need a mention somewhere in terms and conditions of software that such usage data might be collected). For me backdoor would be to have access to customer data/environment through the product without customers permission/knowledge.
|
|
|
|
|
I've used Aladdin HASP HL USB dongles to store the master password.
The software uses the HASP APIs to decrypt the information and to authenticate. This is performed on the hardware dongle that is plugged in to the computer or a server on the network. No dongle, no access, no backdoors.
Having read 'Applied Cryptography' by Bruce Schneier (Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition, ISBN: 978-1-119-43902-8) I never hardcode any passwords or secrets in my software as it is impossible to keep it secret that way. Obfuscating is just "security theater" to quote Schneier.
There are other ways such as using smart cards that have cryptographic chips to protect passwords. Using hardware with cryptographic chips, where the encryption/decryption is done on the chip is the safest way to add "God" powers. Use public/private keys and keep the private key on the removable hardware, thus you can send a signed message from the hardware to your API to allow this "God" mode in your application. The application has the public key to decrypt the signed message which can't be duplicated (include a salt / time / message unique value) and it should remain secure.
CJ
|
|
|
|
|
We developed a secure email system that the [redacted] wanted for it's internal use. However, they wanted us to make sure that there was a backdoor so they could read other people's email outside the [redacted] environment. We refused to do this since the nature of the system meant it wasn't actually possible without a total redesign and rewrite (plus we didn't want to).
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Customers not paying their rental for our studio datafeed. It may seem obvious now that display systems that run from a studio should have some way of being disabled for none paying users, think of a Sky box. Still we had to introduce a secret, over air, update to do just that after a salesman reported that the display system was available on eBay and connecting it to a satellite data receiver was all it needed to work!
|
|
|
|
|
"No - I've never been asked to add a backdoor to my code"
Might want to change this poll option to say software and not code for obvious reasons.
One may have a backdoor to your software/system, but Shirley not to your code.
|
|
|
|
|
Because users, even trained users for sensitive applications, are not bright and Companies are downright stupid.
Storyboard:
1) You create an authentication and auditing system with unrecoverable passwords and customer-unique encryption keys upon request from them.
2) Customer proceeds to create their accounts.
3) Customer then burns all the hard copies of their passwords, doesn't communicate them to the IT, doesn't keep them in the reserved documents archive.
4) Customer proceeds to use a Neuralizer[^] to wipe any tace of said accounts clean from the mind of everyone, to be sure.
5) Customer then calls angry because now they are locked out of the machine and it is your fault and they are calling an attorney because they are losing entire days of production, and they cannot reasonably expect to wipe the user configuration and redo it from scratch or pay support to do it for them (because they sent to the training they paid for the temp subsitute who got fired 3 weeks later).
So... master password it is.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
When such master password are findable with reverse engineering your are in trouble. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Not my decision + not my responsibility = no ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) given.
The only protection to the master password was the use of characters not typeable with the on-screen keyboard in one case and not allowed via keyboard in others - you had to either use the machine with a keyboard attached or an additional tool.
Circumventabke, yes, but... refer to the first line.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
holy sh*t - damned managment ... 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I've worked on a few systems that had a button that let's you take over a user account.
These were always business accounts, and I could always find the same data in the database, but I was still told to never ever ever let the customer know we had these impersonation buttons 
It was mostly so that if a user got an error we could impersonate their account and do the exact same action they did to hopefully see the same error.
In these cases the software already had this when I joined the team.
One time I've been asked not to encrypt passwords so we could easily retrieve passwords and log in as users (asked to me by an IT-consultant and ex-programmer, go figure).
This was for a service and we got a lot of complaints about missing data (ultimately, the problem was never the service, but users using wrong date filters or the business not supplying the data).
I flat out refused that one, there are far better ways for me to check whether a user should get data.
They ended up letting IT give out passwords to users and I later found out they stored these passwords in an Excel file and all passwords were "00000001", "00000002", "00000003", etc. 
Finally, I generated a password and added a reset password button.
They now screenshot the entire screen, including username and (one-time visible) password directly to users 
I can't seem to win this one, but at least when the database gets hacked/leaked/stolen they won't find any passwords 
|
|
|
|
|
The closest I have come to doing that (so far) was including a secret "expert mode" in one system.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
