Jump to content

Field encryption how-to


This topic is 1434 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi Forum, 

 

So I am trying to figure out how I might encrypt some fields in Filemaker, using Scriptmaster. Here's where I am at:

 

 - Want to have the interface as follows:  user sees encrypted text in the field by default, clicks a "Reveal text" button, is prompted for a password, and if the correct one is entered, sees the unencrypted text in a dialog. 

 - I could just use EncryptDES() and DecryptDES() and be done with it, but I understand AES is stronger, so I'd like to use Encrypt/DecryptAES() if possible. 

- So I need a 128-bit key to work with AES. But I don't want the user to have to memorize/deal with that—rather, just with a conventional password. So, I am thinking of having the conventional password get hashed with a random salt using Cryptography - MD5 Hash() (1000X iteration to be secure), producing the 128-bit key. 

- So I need to store something in the database to check against the entered password. Normally with password verification systems, the hash is stored. But the hash is the secret AES key! So I don't want to store that. 

- If I don't store it, how can my script tell if the correct password has been entered? I guess I can just run the decryption with whatever is entered, and if the users sees junk in the output, they know they entered the incorrect password. But it seems there must be a more elegant way to do this.

Edited by nolamike
Link to comment
Share on other sites

  • Newbies

OK, I think I have figured out a solution. In addition to creating the 128-bit key (for AES) using MD5 with a salted password, I can use the same password with a different salt to store a verification hash. Then when a password is entered, I can hash it with the 2nd salt and compare to the verification hash.  A match, and the script can take the password, along with the 1st salt, create the decryption key for AES, decrypt, then discard the key. 

Anyone see a hole in this plan?

Link to comment
Share on other sites

As long as all pieces of that puzzle are stored in FM it is not really going to be secure...

Also you have to absolutely keep perfect track of when what field is encrypted or decrypted.  And make that approach safe against FM crashes / network interruptions.  So think "transactional model".  Otherwise you risk decrypting when it is already decrypted or encrypting when it is already encrypting, and in the process toast your data.

Link to comment
Share on other sites

And of course if someone enters the right password, exposes the encrypted data and walks away from the machine when the sensitive data is exposed then anyone can see it password or not.

<< reminded of this in a previous Wim thread

Link to comment
Share on other sites

  • Newbies

@wim re: storing the puzzle pieces. True, but if I store only the 2 salts and verification hash at least some serious time and effort (I think) is involved in breaking in.  re: crashes. I do have to think through protecting against interruptions.  Seems the riskiest model is getting text out of a field, en/decrypting, then writing back to the same field. I should at least dedicate a field to storing the encrypted text and nothing else. 

@kris good point. Thinking now I will have the decrypted text display in a field, then have it disappear after a short time interval. 

Link to comment
Share on other sites

  • 5 years later...

This topic is 1434 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.