Password Encryption

[Jalz]

Hi Guys,

Are there any tools to encrypt the master password in the database? I thought there was a tool from New Mellenium, but I cant find this.

Thanks

Jalz

[Jalz]

Anyone? Surely there must be something?

I've found that a 'former' client has unlocked my files with my developer password (it was one of my earlier projects where I didn't put an about screen, so whoever cracked it wouldn't have known)but it means lost $$ for me.

So that this doesn't happen again, I want to encrypt my password whether using a plugin or not.

There must be a password protector, as doing a search in good for filemaker passwords, yields so many recovery tools that cost less than $100.

[Genx]

...um, how did he get your password in the first place?

[Genx]

Oh right, cracking software... i assumed that just broke in with full access priveleges - not actually revealing your passwords... oh well.

[Steven H. Blackwell]

Are there any tools to encrypt the master password in the database?

First off, passwords are [color:red]not stored in the database since FIleMaker Pro 7. An encrypted hash of the credentials is strored. The so-called "cracker" tools physically attack and remove the hash.

To prevent this, use the Developer Tool to remove [Full Access] accounts from the file. Note that this also means removed from you as well.

What exactly do you want to protect against?

Steven

[Jalz]

Thanks Guys,

I'm trying to protect my solutions from un-authorised access. The one that they broke into was a .fp5 file, I've been reading up on the issue and .fp7 files seem alot more secure.

Steven, your point of removing the master password is a good one, the only problem is if I ever want to do further custom work, I guess I'm going to be stuck.

Oh well, fingers crossed for the sucrity in .fp7 files.

[Fenton]

In a properly deployed solution you would always keep a master copy, with Full Access, on your computer. That would be the one you'd do further development on. It takes very little time to run files through the developer tool.

It would be smart to rename them at that time, to minimize confusion (for both you and FileMaker). That would also mean to be careful about using hard-coded file names in such things as Select Window, etc..

Of course, if by "custom work" you mean small tweaks, possibly done remotely, to a client's files, then stripping access is not so good. You'd have to get their files and reimport the data, then re-strip. Stripping is more appropriate for commercial vertical solutions.

[Genx]

You know what you could also do?

Remove the account... but before you do, make a trick somewhere - on one of your layouts to re-generate that full access account - obviously, somewhere only you know... e.g. If the user holds down ctrl + shift + tab while going to layout x, it prompts user for a "password" using a custom dialog, then pause the script for 10 seconds, if the user presses shift, ctrl, pause 5 seconds, if the user presses shift, then prompt for another password, then take to a replica of the original layout the user was going to and then hit an invisible button located somewhere no one would usually look for etc. etc.

Something really quirky :[color:orange]

[Ender]

Seems goofy. Anyway, you cannot script the creation of Full Access accounts.

[Genx]

Lol, ohwell i tried. Goofy is fun :

[Genx]

Oh well, point taken.

Goofiness aside... Just create export scripts, should you need to do an update at any point, you can simply export all the records using a pre-created script, then import to your new file using a matching import script - you can still work on your one version of your file - and all is good.

[Jalz]

Thanks both Genx and Ender,

Genx, I quite like the idea of disabling the master account, and re-activating when changes are required to be made by the developer. Although Ender said it was 'goofy', sometimes you have to trial dodgy methods with FileMaker to achieve results.

I theres some substance in attempting to do something with a sample set of files. If it fails, I guess I can keep a 'full' copy on my harddisk and export data into this when an upgrade is necessary.

Edited August 6, 2006 by Guest

[SteveB]

If you feel more comfortable encrypting a password, go to Link for a free plugin that will do the encryption.

Steve

[Jalz]

Thanks Steve,

Looks interesting. The only drawback of this is that the plugins are FileMaker Pro 5 savvy, and although they may work with FMP 8 & Mactel - I'm not sure whether he is going to be updating/maintaining the plugins.

I've resigned to the fact that FM Security is OK for the mass number of my clients, however if someone wants to break in - theres nothing really I can do to stop them.

[SteveB]

I'm pretty sure he won't since he hasn't touched what's out there in 5 years, but this does work with 8, as does other pre-7 plugins. I'm using Troi Dialog and File with the early plugin interface.

Here's another approach, altho not free: WinBatch has an RC4 extender that provides the same level of encryption. While it would appear to be expensive, WinBatch can do so much. However, it assumes you are Windows based. It provides an analogue to Applescript, but with more power.

Yet another approach: While it's beyond me to do anything with it, there is freely available RC4 code in c++. For a C programmer, it could be turned into a standalone pgm.

After writing this, I noticed you're cross platform::so much for WinBatch!

Steve

Edited August 6, 2006 by Guest

[Genx]

Jalz i tried it, ender was right, you can't re-create [Full Access] accounts. You have to have a reserved version of the file instead where you maintain full access priveleges -- can make updates and then update locked versions.

[Steven H. Blackwell]

The only way to disable [Full Access] Accounts is with the Developer Tool.

I showed at the 2001 Developer Conference how these so-called "secret buttons" can easily be thwarted. Please, just do it the right way.

One of the advantages of The Separation Model™ is that the UI and Logic files can be easily replaced with updates. THose updates have the [Full Access] Accounts removed.

Steven

[Genx]

Thats what i was thinking, The Seperation Model is trade marked? Who by?

[Jalz]

Thanks Guys,

Interesting thoughts, I think the seperation method is by far the best way to go. Updates can be easily done in the UI file, which is then stripped of FULL ACCESS account and then deployed.

The solution should technically be sound. Just need to Test and BETA my solutions thoroughly before accounts are stripped.

Jalz

[Genx]

Here's a better question - if Full Access is removed, how easy is it to get to the data?

[Steven H. Blackwell]

he Seperation Model is trade marked? Who by?

Presumably by its creator, Mrs. Hammersley of DataWaves International.

Steven

[Steven H. Blackwell]

Here's a better question - if Full Access is removed, how easy is it to get to the data?

That is a much better question and the answer depends on the privileges left in the file. The data may be vulnerable to persons who can open the file and who are sufficiently knowledgable about the way FileMaker Pro works.

Record Level Access and field level encryption are the best protections. They are expensive however.

Steven

[Genx]

What about complete layout blocking in the backend - both front end and back end need password

[Genx]

OMG, wim's in that company, i love his profile.

[Genx]

OMG, so are you :

Where's the one that created the sep model - i see no her.

[Genx]

Either way, i got off track... i originally had a point.

Umm, assuming all accounts are locked out of backend data (all layout access is locked - script editing etc. is locked - no accounts capable of doing it). And front end - while viewing data in the backend - is completley limited to the data i want being shown.

There is some data in the backend that must be kept hidden however, what i really want to know, is how hard it would be to break in to a stripped file and access the data.

[Steven H. Blackwell]

If the file is opened, either by an authorized users, or as a result of some other process such as an auto-enter password, then there are a range of privileges associated with the Account that opened the file.

Absent Rcord Level Access or field level encryption, if the data can be viewed, then as a general rule they can be extracted. The removal of the [Full Access] Accounts really does not have much bearing on this at all.

Steven

[Steven H. Blackwell]

Where's the one that created the sep model - i see no her.

http://www.data-waves.com/principals.php

Steven

[Genx]

Hi Steven,

Following that line of thought, if the data can't be viewed -- i.e. again if the front end as a whole only views a limited amount of the backend data -- and the backend is locked down -- that is there are no layouts effectiveley, script access and layout creating access is cut -- the data in the back end (excluding the limited data that can be extracted through the front end) is secure?

Cheers

[Steven H. Blackwell]

if the front end as a whole only views a limited amount of the backend data

Then that data can be viewed if the file is open with an Account whose privileges allow that data to be viewed. This might be your "front end" or it might be someone else's front end file.

I couldn't pass further judgment without actually seeing the files.

Steven

[Genx]

Lol, i'd love to, but they're a bit giant at the moment. I'll try explain the setup a bit more thoroughly.

Front End Contains:

Basically just a set of Token accounts, seeing as the front end contains no data -- the only purpose these serve is a) Low Privelege no access to any layouts Welcome Account b)LoggedInUserAccount. All "privelegeset" and "username" checking, are done via globals stored at login.

Back End Contains:

All real accounts. When a user try's to log-in at front via custom log-in screen, triggers a script in the backend to attempt to validate. If valid credentials, logs in as a user (no access to any layouts) - sets account name and priv set in globals for use by front end.

All data shown in front end is happy, it's just that the backend contains a few passwords here and there stored in fields because they may change at some point -- that i don't want to be exportable -- hidden in front end, fields locked for copy, set by script.

Anyway, so diagramatically:

FrontEnd-----||||Backend||

The front end is viewing the bars at the front of the word Backend, additional sensitive data in the backend (not accessible on any layouts by a user in the backend - no layouts exist) is represented by the bars at the backend - not viewable from the front end - dwould be hidden yes?

P.s. Export is hidden in all menu's

P.s.s. Reading your response, seems to have answered my question... oh well

Cheers,

~Genx

[Inky Phil]

Hi Genx,

Export might be hidden on all menus but could I not create a file that would import from your backend - assuming I knew what I was looking for of course

Phil

[Genx]

Well, i would think not - purely for the reason that you would need to be logged in to the backend. Which can only be done from MY front end - despite the fact that it calls a particular script in the backend -- that script happens to be one that logs in based on credentials provided in the front end -- so either way you would need to be logged in to the backend -- if you wanted to call ANY script in that file.

Then, assuming you did manage to break past the accounts... i'm not really sure.

[Genx]

Trying to export from locked layouts -- doesn't work... Not saying there isn't away, i just can't find it. I'm really not sure about the import...I would assume it wouldn't work if export was disabled (its actually greyed out in the menus).. that would be a big security hole dont you reakon?

[Inky Phil]

It would be a big hole and I do not know if turning export off stops this happening but I do know that:

a:) I have created a runtime and to protect my solution I removed all admin privileges at the same time. To complicate matters a little further I invoked kiosk mode at the same time but that is not really relevant.

b:) So that I can issue updates to users, any new files I send them (that are also runtime/admin rights removed) have import routines that will automatically grab the data from their existing files and update serial numbers etc. All the user has to do is move the old files into a previously named folder and press a button.

I know that this does not prove much but it does prove that the data in a solution with all rights removed is not totally safe. Like I said before, if someone knows what they are looking for it wouldn't be rocket science to pull it all out.

Phil