Neither am I a developer/programmer/computer scientist. But it seems to me that any carpenter/builder should be ably employed if he can frame a door and install all the necessary shims, sticks of supporting wood, main guts of the assembly (if not a prefab vinyl composite job of some sort) and he's come equipt to the site with his Paslode and compressor and plenty of ammo to shore the whole thing up.
Hmmm. And now that I think of it, yes I haven't been asked to include a backdoor in any software. But I will if I think it's going to keep the pipes from bursting during the freezing dark days of the coming wait for a tenant to occupy the building, as cold as it is ... having no heater/boiler only swift deep chilly water.
To test the application and the gate only remains open during/on the development. One of the reasons for this is that I would love to grab the codes that the application generates for users and store them in the database. The application sends the codes over email/SMS. I can easily mock them, or, I can leave a development-only API endpoint that allows me to capture the last OTP that was generated.
Not that if that qualifies.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
We use USB 'dongles' to control access to features in our products. I hate it, but I'm not paid to like it. When Windows 10 was coming out, we had a major new version about to release. The PHB's had the bright idea to make it Windows 10-only, and enforce that in the dongle. At the time, most of our testing hardware was still running Windows 7, matching what most of our customers had.
Note that there were no features in the product dependent on anything specific to Windows 10.
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.
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.
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.
Last Visit: 31-Dec-99 19:00 Last Update: 1-Dec-22 23:52