Encrypting or otherwise protecting passwords

[isakudai]

I'm setting up a custom password access system. I have an employees database that holds userID, password, and access privilege codes. This, and the files that I'm protecting, are made with FM5 and hosted on FM server.

I just discovered the other day that anyone can start a new FM file and import userIDs and passwords from the employees DB with no problem at all. I don't see any built-in FM way to stop this, so I figure the best way to prevent any problems is to store the passwords in encrypted form (some of our customers want us to start doing this anyway). I figure I'll use a calculation field to encrypt a "change password" field, then use a script to set that calculation to the encrypted password field before clearing the original field, ie.

user inputs new password to "change password"

Script:

set field "password" to "change password encrypted"

clear "change password"

That way, if someone imports the data, all they can get is encrypted passwords -- the real passwords are not stored anywhere. Also, using a calc field with all commands disabled means no one will be able to see the encryption key. They can't print field definitions, and they can't import an encryption script to another file because the encryption doesn't happen in the script.

My question is, given the above proposed scheme, how do I encrypt a text field? I've seen a few posts on encryption, and it seems the better algorithms tend to rely on the ASCII character designations. How do I write a calculation field to perform functions on the ASCII codes for each character? So far, my encryption only works with pure numeric passwords. Also, does anyone see any obvious holes in my scheme?

[SteveB]

You can use Crypto Plugin (a freebee) from www.protolight.com

[CobaltSky]

If you are going to assemble your own encryption algorithm, you don't need to break to ASCII, you can assign a numeric value of your own to each alpha character and store each character as two numeric digits in a long numeric string (the two digits for a particular character don't have to be adjacent in the string, so long as you know where they are) - before during and after which you can perform whatever math you wish (so long as it is reliably reversible) on the whole or parts of the string.

Added security comes from the fact that your number to letter allocations can be ramdomly derived rather than sequential - and nobody but you need know what they are (unlike ascii codes...).

[Anatoli]

RE: I just discovered the other day that anyone can start a new FM file and import userIDs and passwords from the employees DB with no problem at all.

How if the file is password locked?

[isakudai]

RE: How if the file is password locked?

In this instance, FM asks for a password before allowing the import, and this is great for keeping complete outsiders out of the system, but nearly all employees have the user password. With most of our files, being able to access the data by importing it to another file does not matter too much. It's not a matter of data secrecy as much as maintaining data integrity. Passwords is the only time it really matters.

From inside the file, all commands are blocked to the normal user. Everything needs to be scripted. But in FM's access privileges I allow most functions for users, checking their true access privileges with the custom password system. That way, we don't have to unhost/rehost all of our files, and go through and change each file every time someone's access privileges change. We just check a few boxes on their employee record. And some of our scripts require imports, so at this point I can't just block the export function without risking problems.

So, I guess the answer to your question is that I let it happen! It's just the law of unintended consequences. However, thanks to the replies to this post and a little additional research, I have been able to put together at least a temporary encryption solution that results in a list of gibberish if anyone tries to obtain the passwords. At least for now, I think the value of the information is outweighed by the cost of trying to hack into it. And from an administrative point of view, it's still a very easy system to manage.

Of course, I'm no FM guru, so if I'm way off base here please steer me in the right direction (seriously).