Hello,

Hello, i was wondering if someone can give me a hand with this. we have 28 databases right now and i was not here when they were build, i want to build a custom login system for the employees. I have check some solutions like the gateway but i am new to fm that i dont know where to begin when it come to that that solutions.

Here is what i want to do. i want to create a solution where i can give each person their login/password to access the databases. The deal is that once they are login, i want the databases that correspond with their L/P to open automatically. I have the divide the everyone into groups: Operation, Adminission, Managers. Some people need access to some database to edit/create record, other just need to browser for record and print them out. i want to create administrator interface where i can add new users and enable their privilage. right now, we are using general password the groups.

any help would be appreciate,

Thanks,

victor

Hi Victor. I'm right in the middle of something now- just saw your post. Rather than explaining in detail here, I can send you an example of how I do a login system with our databases. It works very well.

It involves creating a master login, one record file with a few globals; and another one, or perhaps two user files, depending on how you prefer to set it up. Then the privileges for each specific database are set in the user file. Creating a relationship from the master login to the user file (master::USERPASSWORD = user::USERPASSWORD) then enables user access privileges for each user.

Let me know if you are interested, and I can send them to you fully open and you can check the scripting of the system.

Manny Silva

Child and Family Services

New Bedford, MA

[email protected]

Manny,

Can you email me the file to [email protected]

Thanks,

Victor

I too have a similar problem. I work for a school and we have a series for databases that link together. I would like to create a user interface that asks for username & password and then allows them into the approriate area and give them the access writes they need. At the moment we use the built in password facility which is ok but I don't know which password belongs to which user plus if I need to change it I have to go through all the files making the same changes.

Hope someone can help.

Cheers

Keith Bolton

[email protected]

Manny,

Why don't you just post a zipped copy of your solution to this thread? That way anyone who chooses to browse the thread will have access to your solution and you won't be inundated with email requests.

This is a super-simple database login system I created that opens files based on a username. The password for full access is "Admin" - the file called Login Database is a custom login that asks users for a username and password, which it references against the file called Access. Each user has their own record in Access, containing the username, password, and which files should be opened. The same script in Login Database that validates the login also opens the specified databases. You can define reading/writing/printing permissions by having users enter a base password when opening Login Database, and define the same basic passwords throughout all the files and give the different groups appropriate access. This is just a basic shell but it can easily be applied to your databases. I didn't want to add in extra stuff that you would just have to take out when applying it to your databases.

FM.zip

I do again want to caution about the use of these log-on systems. They basically are insecure and they can severely compromise the security of solution files.

At

ISO FileMaker World (check it!)

you find a nice login system called " [color:"red"]The Gateway ". The description says:

Here is an incredible implementation of a login routine, allowing personalized access to a solution, user-specific privileges and preferences, system preferences, administrator settings and privileges, hierarchical access to the data, and even an activity log. You can open this one up and see how efficiently it has been made, then incorporate it into your own solution!

The Gateway MAC

The Gateway WIN

The referenced system is a poster child for the insecurity inherent in these systems. It was broken wide open in less than 30 seconds.

These systems are trouble. I advise your not using them.

Yeah, but there are programs floating around out there for about $40 that will give you the native FM password in a matter of moments. So I'm not sure a custom system is really that much worse than the native system. I think if I really needed security -- like running a reactor or an air traffic control system -- I'd choose something other than FM.

my two cents

Yes, as OAM pointed, and with many respect to Giuseppe's work, this kind of solution wouldn't be suitable as a Login routine.

I'm not a hacker, but with even less than 30 seconds, you'd be able to screw up the whole file, and even delete the admin/admin password.

I'm not that sure Giuseppe's demo was designed to demonstrate a login routine anyway.

My 2 cents.

I've heard that argument before, and I am not buying into it. There are steps that can be taken to protect files, although these cracker programs can do a lot of damage in terms of extracting passwords. Several have been made to go away, and I hope that trend continues.

My resume is that real security in FM doesn't exist. FM is sending valid passwords to client machine

I have downloaded the attachemnt but i am unable to open login db, you mentioned that admin was the password, do i need a username also to be able to open the files and build by own usernam and passwords. thans

You aren't really going to do this are you?

Steven

what i really needs is to be able to tell which operator took a message and whick opr delivered the message. i have only two computers peer to peer. messages are taken and delivered on each machine. sometime station 1 takes the message and station 2 delivers the message, i just need someone to identify who took the message and who delivered the message, thanks jim

Steve

what suggestions do you have then? You are preaching not to do it, but aren't offering any solutions / files in return. I need a login system where the admin can create users and passwords and the users can only see their own records or records that the admin deems okay for everyone. I don't want to use the built in privelages because of the annoying "no access" tags...

what then do you suggest other than "dont use that"...

The Moyer and Bowers book "Filemaker Pro 5.5, techniques for developers" discusses the pitfalls of custom login systems, and then goes on to describe a system which avoids them. That's not to say that no one has discovered other weaknesses though.

Brian Kennedy posted a sample solution framework using their technique. Here is the link:

http://www.fmforums.com/threads/showflat.php/Cat/0/Number/74935/page/4/view/collapsed/sb/5/o/all/fpart/1

As I recall, the method uses a paused script for user ID and password entry. If you are using Filemaker 6, I suggest you replace this with a custom dialog.

Ever look to see what a "Halt Script" does to looping pause? THe suggestion about custom dialog is an excellent one. But be sure to assure that the solution can't be opened in an earlier version.

The <no access> tags can be easily dismissed by the use of a Go To Related Record as I explained recently on FM Experts.

I am trying to alert you all to dangers in the methods used in these log-on systems so that you don't wind up having to explain to your bosses or clients how your technique resulted in the fairly easy extraction or compromise of your data or files.

The closer you stay to the built-in FMP system, the better off you are.

yafreax asked:

"what then do you suggest other than "dont use that"... "

Use the built-in system. The fact that you or anyone else wants to do something else or wants a different functionality isn't material here. What is material is that if you use such a log-on system, you almost always degrade your security.

I have already had to provide expert witness testimony is 2 cases involving loss of data and property in systems such as this and the attendant negligence and liability issues. I hope not to have to do that anymore anytime soon or at all.

Steven

I have a solution that will work for you. I wrote it to control 25 databases for a flight training school. It manages groups (instructors, admin, dispatch, etc) and provides customized access to each database as well as access privledges. Email me and we can discuss it: [email protected]

Ever look to see what a "Halt Script" does to looping pause?

Yes, I have. That's why I suggested the custom dialog. However, even with a pause loop it's not necessarily impossible to make a secure login. You just have to make sure that if the user manages to cancel the login script, it's cancelled in such a way that he isn't logged in yet, and cannot get beyond the login layout and the login file.

BTW, I'm not trying to encourage people to use custom logins. But if someone asks, I'll give them whatever information I can.

I'm less concerned with the weaknesses of the login procedure than with other back doors into the files. You can spend a lot of time making the login script secure, and then completely overlook some simple thing in the rest of the solution that will let a hacker in with no effort. So, if you're doing a custom login, it's important to design the whole system from the ground up with security in mind. You can't just take an existing db solution, tack a login script on the front and expect it to be secure.

" less concerned with the weaknesses of the login procedure than with other back doors into the files. You can spend a lot of time making the login script secure, and then completely overlook some simple thing in the rest of the solution that will let a hacker in with no effort."

Exactly. And if a developer believes that the custom log-on provides security, and then that belief proves false--then these other vulnerabilities become even more exploitable.

"You just have to make sure that if the user manages to cancel the login script, it's cancelled in such a way that he isn't logged in yet, and cannot get beyond the login layout and the login file"

However by entering a known false log-in, you can frequently force open the "users" file, and then you cancel the script. Now you have an open "users" file that is in almost every case I have seen easy to exploit.

Steven

Downloaded and tested the app out, wanted to view how it's done, but I can't seem to get full access to it.

I was able to view test it with the Admin ID, but it won't take Admin as the password.

Did you know that hack programs are not able to hack an FM database password when you use an "!" symbol in your master password?

Version: v6.x

Platform: Mac OS X Panther

Wanna bet?

Actually, I should ask if you've tried them all. I wrote a password hack program about a year ago as a result of a discussion in this forum, in order to demonstrate how insecure Filemaker's built-in passwords are. I haven't found any special characters that would prevent the password from being found. But, it's possible that some of these hack programs do not have the complete encryption algorithm figured out, and so may fail with certain characters.

BobWeaver, I've misplaced the password for a database of mine that I would like to recover. Would you happen to still have a working copy of that program?

Jim,

The databases open with a default low-access password for normal users. When you opening the databases to do work on them, hold down the Shift key. It will ask you for a password. ("Admin") Then you can show the Status Area, switch layouts, and create records that define access for your users.

Admin is only the password to gain full access to the file - it will not work in the login system itself. Once you have full access to Access.fp5, run the script that says Show Status Area, then switch layouts. You will be able to see the logins I created.

All of this discussion about creating custom logins is obsolete: FMP 7 has it all built-in and facilitates building secure interfaces to manage it all.

YEAH!

Can't wait till FMP 7 Server comes out...!

Hi Greg

Sorry, I don't do password recovery because I have no way to verify who is the legitimate owner of a database. I've done a couple of demonstrations on some empty files that a couple of people have sent me, but that was the extent of it.

No need to wait till server, it's all functional in plain old FM Pro 7. Even the Trial version.

I've put something together already... when I get time I'll strip it out and get a demo happening. I'd welcome the security experts here like OAM, Bob and Ray (amongst others) to evaluate it.

We can all learn from this together, learning FMP 7 is such a big job.

I'll post it in the samples forum when it's done. Probably later today my time.

Yeah. It looks like I have to upgrade to OSX now so I can play with the new toys.

It looks to me that hosted files should now be very secure. However, files to which the user has direct access may still be susceptible to attack with many of the old methods (except that it won't be possible to retrieve passwords since only the pw hash is stored). And FM7's method of converting older files compromises their security, but it seems that FMI isn't interested in security for fp3 and fp5 files any more.

Alright, thanks, I'll just have to invest in the commercial products...

Version: v6.x

Platform: Windows 2000

I think some of the benefits of downloading these solutions and even creating them and posting them up here, include demonstrating some of the inherent weaknesses of any solution.

Really I would suggest people don't download a solution because it's not secure, it may just just perfect for the sort of application they're using.

I was not surprised that Bob Weaver hacked into my login demo in a matter of minutes, but I was gobsmacked that the file was accessible after being "Permanently locked" by the developer package... In fact it's made me re-assess my approach to security within solutions, and for that i am grateful.

The level of security that a person requires in their solution is entirely their own baily-wick. The Gateway package talked about here is definately not secure, but that doesn't mean that its completely useless. I think the approach used in its development was good, and if anything it's a great learning tool in filemaker development.

Just my opinion.

ps: I know encrypt my sensitive data with 128bit RC6 encryption

Q

"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.

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

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!

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...

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.

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

FMP 7.

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

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...

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

"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?

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.

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.

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.

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.