Granting back door access to an application

[Mike Lewis]

I've recently been working on an application where security is an important issue:

- All users have to be authenticated with a strong password.

- The password table is encrypted.

- Only a designated adminstrator can issue logins and passwords.

- All changes to logins and passwords are securely logged.

All this is working fine. But some questions have now arisen:

- What if the administrator falls off a cliff?

- What if it's necessary to run an admin function on an emergency basis (repairing corrupted tables, for instance), and the administrator isn't available?

- What if a vindictive adminstrator deletes his/her own login (and them immediately walks out of the office for good)?

And what if something like this happens while I'm away hiking in the Grampians or whiling away the evening of my years in an old folks home?

The question is: Should I provide some sort of emergency back door entry into the system? If so, how should I do that ? And how should I communicate the fact that such access exists, without alerting a would-be intruder?

I'm sure some of you must have faced similar problems. I'd be interested in knowing how you've dealt with them.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Mike Gagnon]

Create another user in the user table (you as an admin) and communicate this info to the president of the company only.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[foxbldr]

ML,

I had a similar situation and I was asked same type of 'What-if' questions from the client.

In my case, I used a simple binary file to bypass security and grant admin rights to the user (i.e.Chief Info. Officer/Owner) with an expiry time. Binary file is created by the user (creation will take only couple of minutes and file expires after a pre-defined duration) using his/her special security code (only known to them and they can change at will) and data (i.e. login, password) used for authentication. User can run the application to read this file by using a command-line parameter and then application will authenticate against this file content.


Nowadays, clients ask all kinds 'what-if' questions and once a client wanted to know whether the Y2K compliant application I upgraded work in year 10000!

I would like to hear more ideas.

Foxbldr

 

[Scott24x7]

A common "Admin falls off the planet" (and there are LOTS of things that can cause this to happen) precaution is to have the admin write the password down placed in a sealed envelop, which is then put into a bank valt. In the unfortunate event of either having to have the admin removed (in which you get someone to open the envelope change the admin password before the come into work...), or they are incapacitated, the password can be accessed. It should NEVER be shared with another person as a "backup". Securing it in this way is usually better.
Most companies (I know I would be) will not allow you as the developer to have a "secret" login that only you know about... with a diligent admin, they would spot it in a second anyway, especially one with administrative or high security access.
The main way to resolve the "Admin logs in, deletes account, walks out" is something called "BACKUP". This should be done daily at minimum, and in 15 minute increments for high availability needs (usually when using SQL Server, but can be accomplished with VFP as well with the right routine.) In the worst case scenario, if it's a daily backup and he/she waits to the end of the day to delete the account and walk out, restoring the user/login table is all that will be needed. If they format the server, backups are their only reilef anyway, and have ramifications reaching WAY beyond just your Fox app...
Ability to run certain funcitons like Reindexing can be granted to a power-user, or "Alternat Admin" who has their own password. Assumingly, if the admin is unavailable and an emergency function needs to be run, there is someone on hand qualified to run them, or who is the contact for you as the developer to walk them through the process... I assume these functions are automated within your application, as REINDEX routines are fairly easy to implement at either the table or data base level.
None of these are show stoppers.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Hello Mike,

more a story, than an advice. I introduced a "backdoor" in an application that would break a lock: If the database failed and the app went into maintainance, shutting every client down, then a lock was introduced in the form of a file at the database. (If users would knew that, they could have removed that file and start the app again, but that just as side note).

Then after repairing the database, the admin should be able to test the application first, so I programmed that if a certain file "admin.txt" was in the local applicatio folder, the app would not react to the lock file at the database folder and start up anyway.

No user ever got that knowledge, but the admin once put his app folder on the net to copy it to clients having prolems with the installation. Guess what? the "admin.txt" file spread and therefore tha startup lock for maintainance mode failed for these users.

The lesson one should learn from this is, that such special unlock permissions should be kept local, so perhaps storing something in the registry would be better than a file, or couple the en/decryption of the file to some hardware, eg hard drive serial number, that way it will only work at the admins computer.

I wonder if it's really that bad an idea to have several admins. They can watch over each other. Perhaps even allow some things (press the red button to cause an atomic war or delete the database or something similar devastating) only, if at least two admins enter their password.

Bye, Olaf.

 

[Nifrabar]

Mike,

What about a parameter in the main.prg holding the 'masterkey'. Than, later in the application that 'masterkey' enable full control over the application.

Would that make sense?

-Bart

 

[Mike Lewis]

Many thanks to all of you for those excellent replies. It's nice to know that I'm not the only one who has faced this situation.

You've given me plenty to think about. I'll be deciding what to do over the next few weeks, and let you know the result.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[ramani]

I have generated a backdoor entry to all my applications using a special password. The password programme in addition to the password validation uses a (OR) condition, checks for my password also. This password is not stored or kept in the database itself. It is a generated password, based on the year, month, date combination. For simplicity let us say..
[some XXX] ;
+ ALLT(STR(100+year)) + ;
+ ALLT(STR((100+month)*3)) + ;
+ ALLT(STR((100+day)*2))

So anytime i get a call, or i have to attend on site, i can use the mentally workedout password and checkin. Even if we have to provide this key to anyone, we know that it will work only for a day. However, this function, is so tightly held like the source, no one knows about it. (I am using it for over 20 years with success.).

In addition, I have a suit of other features built, providing a special status to this type log-in (as a special super-user) for database maintenance or error recovery (again hidden in certain rightclick events) which will not be visible even when we tell the password to the users as a one day access.

I cannot comment on the ethics of doing so (keeping a secret entry), so long i remain honest and provide the password for the benefit of the client.

cheers

____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[Mike Gagnon]

Longtime no see Ramani.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Scott24x7]

Ramani,
Agree with Mike, great to see you here again.
Have to disagree with your approach, and as industry security goes... I don't think any client would be to happy to know of this. I know if I got caught putting something like this in for some of my work, there could be serious liabilities...


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[ramani]

Scott,
I already commented on the 'honesty' part of it.
I disclose and take care since a back door entry is required to bail out customers with least of costs. It is not only the disclosure, we have to stand by that. I am well trusted on this over 2 decades with no liability issues. A switch in parameter file should disable such a function and absolves any responsibilty. This was left to be mentioned in my thread. Also, in the worst case, again we have to enable that directly using VFP and use the back door entry. It is only a question of remote usage or knowlegeable usage.

Any backdoor entry is subject to the same questions / standards. Any data in the hands of creator, can be opened and read. The discussion will open up many ifs and buts and standards. So i will leave that out.

But anyone reading it, should note your point carefully. Good you highlighted it better than my comment. May be the wordings confused it a bit. As said, it involves even maintenance codes and support functions thru those backdoor entry.

And thanks for the welcome and to Mike Gagnon also for remembering.

Warm regards to everyone in Tek-Tips.
I hope and wish this thread remains on its topic. !



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[Mike Lewis]

I've pretty well decided to go with a solution similar to Ramani's. I'll hard code an emergency login name, and generate a password on the fly, based on the current date.

As far as the ethics is concerned, I never envisaged using this login myself. In fact, the real issue is how to deal with the need for emergency access when I'm no longer available.

I need to give the details of the back-door access to a "trusted" person in the company. I'm not sure who that person will be, but that's not a problem for this forum. I will give this person the information they need to determine the password for that day. If necessary, they can then give the password itself to the person who actually needs access to the system, on the basis that the password will "expire" at the end of the day.

Ramani: I'm pleased to hear that you have faced the same problem and have found a solution you are happy with. It must be at least a year, maybe two, since you were last here. I tried to email you some months ago (can't remember why), but the message bounced.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk