Auto Login Concept

[Vaughan]

Hello

I'm working on a bug/enhancement database. This will be a system that I WANT people to be able to enter data into with the minimum of fuss.

One of the features I want it to have is auto-generating user accounts, to enforce record level access restrictions. However I want it to be maintenance free and not require an administrator to set up accounts.

Attached is a small demo file that I'd like comments on. Its interface is extremely rudimentary but it has the basic functionality for testing.

Briefly it works this way:

Double click the file to open. It displays the list of existing user accounts.

To log-in just click on your name.

If your name isn't listed then click the "add account" button down the bottom and follow the prompts.

When the "Welcome" screen is displayed then you're in the main database with your customised account and no longer using the guest account.

It is open for inspection using the default full access account credentials.

This file requires FMP 11 or later. It will not open with FMP 10 or earlier.

What I'd like to be improved:

Passwords are not stored in the users table, however they are initially entered into global fields for the custom dialog. Ideally I'd like to somehow get rid of these global fields as well so that the passwords never hit the data layer (ie, somehow enter directly into the Add Account script step).

Auto_Login.fp7.zip

[IdealData]

Wouldn't a "Duplicate account" function be nice for that? You could duplicate new ones from a master and force them to enter a new password at next login.

[IdealData]

And then it hit me!

When you create the new account just ask for the user name but set the "user must change password at next login" to on and the password to "blank". Run a re-login and let FileMaker take care of the dialogs and password verification.

[Vaughan]

Thanks for taking the time!

set the "user must change password at next login"

I tried something similar: setting the account to a default password, loging-in to the new account, the issuing the Change Password step immediately afterwards. The user is than prompted to enter the old password and the new one twice, and I can imagine confusion about the old password.

My testing indicates that if the New Account step has the "must change password" option selected, but is set to run without dialog, then the use isn;t prompted to change the password.

[comment]

I can imagine confusion about the old password.

I don't think you have too many choices here - there are only three script steps that will show a password dialog.

Add Account []

Reset Account Password []

Change Password []

You obviously do not want to expose the first two to the user, so it's either that or globals. And why not globals?

[IdealData]

Add Account does not allow "no dialog", bur Re-Login does, albeit pointless to do so as you need the prompt to permit the user to enter their new password.

Your original design is only flawed by your search for security perfection, but the global can't be seen by anyone and provided you cleanse the globals immediately after the user has entered their details then it won't exist for very long either.

Another approach would be to email the user with their details, use a random created password maybe? Maybe even display a dialog of the random password (or an easy one to remember - their name, their email address?) and then run the re-login with the requirement to change the password. If they mess up, just delete the account and let them try again.

When I tested the re-login you can prime the account and password, and the password will show in the change password dialog, albeit in "bullets", but it overcomes the issue of the blank password

If you're expecting them to report on bugs and enhancement requirements then it's a reasonable bet they're already used to creating user accounts and passwords in other systems.

I hope you don't mind if I take something from your example though.

[blueboy21]

Hey guys,

I'd like to ask something. for example: My user name: Robert and password: 12345.

It seems 12345 but I want to hide this key letters. Instead of that, how can I change 12345 as ***** on the login screen?

Any script hints?

thanks in advance,

[IdealData]

Dialogs that use input to fields can have the "password" character (bullets) applied to them - there's a check marker for it in INPUT fields.

[Vaughan]

You obviously do not want to expose the first two to the user, so it's either that or globals. And why not globals?

To maximise security. Wanted to see if it could be done without them. I've used globals, and am happy: the password is only in the field for a coupe of steps and only the current user can see them anyway, so there is minimal security implication.

I hope you don't mind if I take something from your example though.

No, I don't mind at all. Let me know if you come up with any enhancements.

[comment]

To maximise security.

I can sympathize with the feeling - but I wonder if there's anything real that would justify it.

[Vaughan]

The desire to do work that is best practice.

Perhaps another way to put it might be to say that I don't want anything I do to LESSEN the in-built security.