help creating custom login system

[Vaughan]

"the file was accessible after being "Permanently locked" by the developer package"

This just means that the file cannot be opened in FM Pro or Dev and have the layouts, fields and scripts etc changed. The ability to change the *structure* has been removed somehow. It does not prevent the file from being used in a relationship or otherwise to access the data inside.

[Vaughan]

I've posted a FMP 7 security demo into the FileMaker Pro Samples forum.

[dmaxj]

I, too, am in a similar situation like solarpunk. I need a layer of "simple security" with logging, prior to letting others get into a database... I will d/l the attachments and review. Thanks!

[dmaxj]

The gateway demo is pretty good to review. It has some features that I like. I realize that this is prototype implementation, but I am wondering about a few items.:

How was the browse, layout, find, preview selections subdued/grey'd out?

How did you implement the logfile?

How did you subdue any of the dropdown options in the file, edit, records, scripts, etc on the menu bar???

I have been working in filemaker 6 for about 1 week. I come from a c++, mysql, php background, so learning an "all-in-one" tool will take some getting used to...

Thanks for the patience...

[BobWeaver]

I think we have to keep the whole security system in perspective. If your only goal is to control access to a small system on a an office network where your employees are reasonably trustworthy then I don't see any major problem using a custom login system. If there is a malicious employee, then they can probably find easier ways to cause trouble in the office than hacking into the database.

[dmaxj]

Bob, I agree with you whole-heartedly... I am really more interested in logging specific transactions that occur. And I would like to be able to associate the transactions with specific users.

I inherited a filemaker database from a previous developer. She had setup four different levels of access to the database. The 50+ users of the database are sharing passwords. Some of the transactions that users are performing are causing problems and we cannot tell who is doing what and when. Right now, four "across-the-board" passwords will not cut it. I need each user to be identified when they are entering, editing, and deleting information.

Surely, this can be addressed. I am working in FM6. Any ideas???

Thanks

[Vaughan]

FMP 7.

[Steven H. Blackwell]

FileMaker Server 7 and FileMaker Server 7 Advanced will have ***extensive*** security management features including strong data encryption.

See some early details in the Tech briefs on Serevr and on Security:

http://www.filemaker.com/upgrade/techbriefs.html

Steven

[dmaxj]

So, if everyone in the office has filemaker 6 - will I still be able to develop in filemaker 7 - AND distribute my application to the filemaker 6 users - AND still get the filemaker 7 benefits???

Maybe I should rephrase. Is there any backward compatibility between filemaker 7 and filemaker 6??? My dilemma: my dept just bought filemaker 6 and licenses for everyone in the office. I'd hate to be the one to say "now we need filemaker 7 because of it's security features." However, if I said " Filemaker 7 would be great for me to use for implementing a security model AND it can work with Filemaker 6!!! - Yay!!!

Does this sound possible - it would really make my week...

[Vaughan]

No backward compatibility (just like FMP 4 and FMP 5). Everybody will need to get a copy of FMP 7 on their desktop.

[Leb i Sol]

"No backward compatibility"

so does this mean that only 2-3 developers in world have their solutions secure in previous versions?

or is every one else living by

"it is not secure...oh well, it is just the way FM is" approach?

[BobWeaver]

Essentially, you're correct. Any solution that was created in version 6 or earlier can be opened up, and everything made accessible. There have been password crackers available on the net for quite some time.

The best security of which I'm aware is a password shielding technique that was used by New Millennium (and maybe others) in some of their security plug-ins, but even this can be bypassed in about a minute using a hex editor. However, most users won't necessarily have the knowledge to do this. So, as I said previously, you need to keep everything in perspective. A few people may go to the trouble to open up your solution to see what makes it tick, but we are talking about a small percentage.

Security in FM7 is vastly improved as far as normal file access is concerned, but it won't prevent people from opening up the files with a hex editor and looking at the scripts, calculation formulae, etc.

[Ken Newell]

Did you buy on a VLA? If so a while back FMI added one year of upgrades to them. What that means is you would now have FM7.

[Leader]

I have inherited a DB that uses FM 6's login/password facility that has gone away in 7. This FM 6 DB has close to 4000 user IDs and passwords and I wasn't seeing an immediately obvious way to convert that to 7.

That's been percolating in the back of my mind as I've working on other problems, and I think I've come up with a solution: Write a FM 7 script that rolls through the DB plucking out IDs and passwords and applies the AddAccount script step to generate a new ID with password for FM 7.

If you always force the user to use one of your scripts to change his password, you can maintain that in the DB, but reflecting Greg's point above, it should be encrypted and not plain text like it is presently.

I've also designed another security precaution recently for a DB in which people are allowed to update information. The REAL DB is kept separate and users log in to a front-end DB with fields that are related to the fields in the Real DB. All of the checking and analysis is done in the front-end DB and then passed back. The user never directly touches the real DB.

[Fenton]

This seems to be quite the rambling conversation, so I'll toss in a couple ideas. In response to Leader, I recently posted a little file that had a Loop to create multiple Accounts, just a few, nowhere near 4000; but I see no reason why it couldn't. I'm very impressed with the capability and speed of Account scripting in 7. If 6 could have 4000 I imagine 7 could. Drop me a line if you want me to send/post the file again; it was really just a simple loop. You need it, and a few other scripts, in every file, to create, delete or change the password of an account, from a central file.

In discussions about security, especially those that involve both versions 6 and 7, there is quite a difference between "just keeping track of who is logged in" and "security." The former can be handled by a fairly lightweight custom login system, while the latter is probably best served by using the built-in passwords.

It's also important to consider how many people you're dealing with. In 6 it's kind of a pain to deal with lots of people, so lightweight custom login routines may be a acceptable compromise. In 7 it's so much easier to create accounts that the compromise may seldom need to be made.

A further interpretation of "security" is the developer protecting his work from being "borrowed" without permission. That's a different thing.

Since almost every solution has at least an element of all the above, anyone asking for advice should try to lay out at least the basics of what kind and level of protection they are after.

[bruceR]

" I recently posted a little file that had a Loop to create multiple Accounts..."

Could you point us to it? Where did it go?

[Fenton]

Here's a link to the file (hopefully):

http://www.fmforums.com/threads/download.php?Number=104045

I've since decided that the Loop to create multiple Accounts is superfluous, unless you have more than 20; because you can just click a button to do them one at time; it's very fast. For 4000 it'd definitely be worth it :-)

Each file needs the set of 3 scripts: Create Account, Reset Account, Delete Account (I'm not bothering with Disable/Enable at this point; you can just Delete/Create).

You can import the basic scripts from file to file, but the new table::field format means that you end up having to retarget most fields; (relationship::field) imports with no problem though, as long as the TO's (2) are named the same.

One limitation to all this Account scripting is that, for security reasons, you can't Get(AccountNames), so you don't know if any particular account exists yet or not. That's why the ErrorCapture(On) for Reset and Delete. Then it doesn't really matter.

[Leader]

Hey, Thanks, Fenton! I got the zip.

[ML2008]

What programs can retrieve my password? I have fm7 file that I was dev scripts that change the password automatically based on todays date and now can't figure out how to open it.

Please tell me how to do it!

[ML2008]

Where?? I need one of those to open my under development solution that changed the password based on todays date. Now I can't open it!

[Fenton]

Manny. Sorry. No one can open it except you. It's one of the features of FileMaker 7. They can't even open it.

You used a script to change the master password? I never have done that; and I guess you're finding out why it's dangerous. Perhaps I should redo the template to block that. Try hard to remember what you did. Remember the account name must be correct, and the password is case-sensitive.

[Leb i Sol]

passware.com will handle only FM up to version 6