prevailing opinion is that it's best to use Filemaker's built in security features.
Ok, but how can you force the user to set a strong password? And what happens if he forgets the password?
You have 2 resources in your Privilege set toolbox: password length and password life. You can use both.
A strong password is commonly considered a password containing a combo of Uppercase, lowercase, numbers, special chars, etc. But a long password is a strong password, too.
A short-lived password is also a good idea.
The problem is, people do forget passwords, and the more they do, the more they write it on a post-it placed on a random corner of their screen...
Whatever you may create on your own will be less tight than FM's built-in security. To start with strong encryption for passwords.
Using FM accounts for WD access is a proven strategy. siplus mentioned where to start with.
I think it's unlikely anyone here would say you should bypass FM's built-in security features. But you don't need to. You want to enforce conditions on passwords, that's fine, you can do that.
You need to script Account Creation and Password resets. Look at these script steps: Accounts script steps
In the script that, for example, creates an account, you can use a global field to take a password, and check it's validity before handing it off to the Add Account script step.
If you want to implement your own login system, one thing you have to avoid is comparing. NO this = that, no patterncount, no if, or case, or similar. No building up a key or a word. GTRR's and quickfinds based upon OnLayoutKeystroke that lead (or not) to a single record in a complex table setup can be an idea.
siplus You'll need to explain yourself a bit more.
DavidJondreau has suggested testing the password and tests would be comparisons. For example, you could test for common passwords to ensure that they are not allowed. See http://www.passwordrandom.com/most-popular-passwords
$test = Substitute ( $password ; ["password"; "" ] ; ["1234"; ""] ; ["qwerty"; ""] ;[ get(accountname) ; "" ] )
Length ( $test ) > 7
The same website provides a password test meter: http://www.passwordrandom.com/password-strength-checker. That test is strongly biassed toward password length. A lot of password meters recommend length over other factors. That is handy. It means that memorable phrases are good passwords.
One thing that has not been mentioned before: offload the account management and pw requirements to the OS: use External Authentication.
Also, you can test to make sure there is 1 lower case, 1 upper case, etc etc.
password = Global::Password ;
alpha = "abcdefghijklmnopqrstuvwxyz" ;
upper.alpha = upper ( alpha ) ;
digits = "1234567890" ;
special = "?@$%"
has.letter = not isEmpty ( filter (password ; alpha & upper.alpha ) ) ;
has.upper = not exact ( password ; lower ( password ) ) ;
has.lower = not exact ( password ; upper ( password ) ) ;
has.digit = not isEmpty ( Filter ( password ; digits) ) ;
has.special = not isEmpty ( Filter ( password ; special ) ) ;
result = has.letter and has.upper and has.lower and has.digit and has.special
The most secure way is easily the Filemaker built in passwords, very little thought needs to go into making that work.
If you do make your own system then be aware that the passwords won't be stored encrypted in the database unless you encrypt the whole file.
If you do your own password system then at the least:
1) Make your file automatically open with a non user-administrator account
2) Ensure that the user is not able to move to other layouts, run scripts, etc at the login screen since when they are at your login screen/dialogue they are already in your database.
3) Is there also Filemaker Pro access to this database? Be aware of the FMPro users abilities to access your database because they may be able to view stored passwords if set-up incorrectly.
4) For future development, never ever make a mistake that makes your database in-secure!
5) There are many more fine details than this to consider...
Don't store passwords. Don't recommend it. Neither is good practice.
If you use automatic login you have to take precautions with the privilege set: You'll need to allow them access to a few global fields. You may want to set up a table for this purpose. You'll need to allow them to run several scripts. You'll need to allow them access to several layouts, based on the login table. Don't let them do anything else. Don't let them see anything else. Deny access to all records and all fields in all other tables.