Tip #12 - Passwords in FilePro

palmtree with sun behind it

TIP # 12 Passwords in filePro

Nancy Palmquist

Creation Password	This password limits access to the development modules in filePro. If this password is assigned, it incorporates the filename. Changing the filename will alter the password that filePro, expects you to enter. This password must be supplied to reach Define Files, Define Screens, Define Output, Define Edits, and Define Processing. This password must also be entered if you are saving a process table that does a lookup to this file or create a browse lookup to that file. Recommendation: Only use this in extreme circumstances. Better to remove access to development altogether for most controlled installs. Removing: Easy to remove, if you know it already. filePro technical support can help you, if it has somehow been assigned and you do not know it.
Screen Password	This password is a runtime password. It will limit access to a particular screen at the point of data entry. This password can also affect data displayed in a browse in that file. If you are having trouble displaying data on a browse list, it might be controlled by a screen password. Remove all screen passwords to see if this is the case. Recommendation: Not usually needed. Numbered screens are the only ones available to the casual user. Lettered or named screens can totally be controlled by processing. Use them to control access. Removing: Anyone with creation access to the Define Screens can remove this type of password easily. Changing the name of a screen outside filePro will also change this password.
Output Password	This password is a runtime password. It will limit access to a particular output. Recommendation: Use this password to control sensitive reports and processes from accidental or malicious use. Removing: Anyone with creation access to the Define Output can remove this type of password easily. Changing the name of an output outside filePro will also change this password.
Menu Password	This password is attached to the menu. It will limit access to the menu. Any user that has access to the operating system prompt can get around this by running the functions from command lines. Recommendation: Use this on a controlled system where users have no access to command line. Removing: Retype the menu. You can usually see the menu content with "cat" in UNIX or "type" in DOS, but it cannot be pulled into an editor, so try to print it and start typing.
Site Password	This password is attached to processing tables as they are recorded. If your computer has a site password assigned, all process tables recorded that have no passwords currently assigned, will be assigned your system site password. No prompt to enter a password will be displayed, on the home system (This is the system that created the password and originally assigned the password). If this table is moved to a different system or the site password is changed on the home system, then a prompt will appear to request the site password. The site password is required to edit or view the process table. This password does not restrict the use of the table in runtime in any way. Recommendation: Always assign a system site password to your computer. Then all the tables written on your system will be assigned a password that YOU know.

Definitions that may help with site passwords.
Home System:	The computer where the process was first saved with the password assigned to the system. On this system, the site password is invisible to the developer. If the site password on this system is changed, it is now going to behave like a User System.
User System:	This is a system that has a different site password than the assigned processing site password. On this system, a prompt will request the site password each time you try to edit or view the processing. By assigning the correct site password to the system, this type of system can behave like the home system.

HOW TO REMOVE OR ACCESS A TABLE WITH AN

UNKNOWN SITE PASSWORD

When the system site password matches the site password assigned to a table, no prompt will appear to ask for a password. When they do not match, a prompt will appear to request the correct site password. If you cannot supply the password, or would like to remove or change the password, try the following procedures.

Want to change the password and I know the current password.	Add ABE=ASCII to the configuration list or set in your environment. Then use Define Processing to load the table. Insert a line at the top of the table and type an apostrophe as the first character of the IF or THEN. Save the table. Now you can shift to an editor appropriate to your system (vi, edit, ed, wordpad, whatever you like that can edit an ASCII file). Load the process table in question and delete the first line. Now the password is null. The next time you save the table, your system password will be applied to the processing table.
Don't know the site password and the table is in ASCII.	You can edit the ASCII table with an editor from UNIX or DOS to remove the offending password. It is embedded in the first line of the table, but not always at the same byte. Use an editor and remove the password from the first line. Now you can load the table with Define Processing.
Don't know the site password and the process table is encrypted. (Not in ASCII) Table was written on your computer.	Find a backup of the fppath (UNIX /etc/default/fppath, DOS \fppath) and restore. If the prompt disappears, you have the correct fppath, make a safe copy and don't worry about it. If the correct fppath cannot be found and the processes are still inaccessible, refer to the solution below.
Don't know the site password, process table is encrypted and the table was not written on your computer.	Call filePro technical support. They will have you send a backup of the process tables and will reset all passwords to a known password for $100 (current price 1997). Ownership of the processes must be guaranteed in writing as part of this option.

EDITORIAL COMMENTS ABOUT SITE PASSWORD

This password seems to give people the most problems. I think it is because it can be assigned accidentally and the user does not realize it is there until it has infected many tables on their system. I HIGHLY recommend to everyone that one be assigned on your development machine. Write it down, put it in the safe. You will never need to bother with it again. It will be attached to every process table and you will always have it. Once one is attached, it is never changed. If the password is changed on the home system, each process will ask you for a site password. Since this behavior will be noticed while your backups are still recent, (if you didn't put it in the safe as I suggested above) you can restore the fppath that had YOUR previous password from a recent backup.

If you do not assign one on purpose, no password is attached to any table when it is created. This leaves the table unprotected so if at some later time, it is changed or assigned, it is still invisible to you. As you work on your tables, it is attached to each as it is recorded. This can go on for months, until someone changes it again or removes it. Then you may have hundreds of tables with a password assigned that YOU DO NOT KNOW. Not a good way to start the day. Now it may be too late to find a backup of fppath. The most common time this problem appears suddenly is when the computer hardware is upgraded and a backup of the filePro data files is restored. This usually does not include the fppath file so in effect you are moving your data to a new computer.

So in conclusion, my best advice is ASSIGN A SITE PASSWORD. If you can't remember it, use "password" which is the first obvious try of anyone that hits a place with a password they do not know.

EDITORIAL COMMENTS ABOUT ANY OTHER PASSWORD

I do not usually use any other passwords for runtime control, they annoy me and only provide limited control for only amateur users. I never use CREATION passwords, they only annoy the developer (me). I rarely use SCREEN or OUTPUT passwords, they are only useful in systems with no filePro development available.

FINAL HINT

I always try to make security invisible, it makes it harder to breech something when you do not know it is there. Using the processing to provide security, by asking for a password and checking it in processing before a secured screen is displayed can work well and be difficult to bypass.

CONCLUSION

I know there are a number of consultants and developers that have other opinions on the use of passwords. Before I start getting a lot of flack, I wish to add that this has worked well for me. Your own level of paranoia and system requirements will determine how much security is necessary or required. I like security that does not drive me nuts. On systems were the "prc" tables are available, the site password gives you a no-brainer way of applying security that does not effect the processes on your source system, but kicks in when the process is moved to the customer computer. I do not have to remember to do something. I like that approach to security. It makes my life simpler and I sure need that. On 4.05 versions, you can set PFSP=sitepassword and assign a password for just your session. That can allow you to work on a system with a different site password, and make it invisible to you while you work. Neat new feature, will be very helpful.

Written by Nancy Palmquist at nlp@vss3.com