Custom Login/Splash Screen

[Fesseyo]

Hi Chaps

I have a live FMPro 8 Database hosted by a server.

To date access to the primary file has been automatic via a non passworded "demo" account. I have now set up users with various levels of access privaledges that I now want to start using.

However, I would like to create a startup/splash screen for these users that contains some database information such as a company logo and address but also contain a "User" and "Password" field that on a button press uses a script to authenticate the user and log them into the database proper.

I would like the User field to retain the user name for the user workstation but of course NOT to retain the "Password" that was entered.

I have trauled the posts but there appears to be very little on this sort of Login Personalisation - any ideas?

[Genx]

Its all in the wrist... :

It all just requires a bit of creative logic.

Before anything else, you have to create an ultra low privilage account called anything really. All it has access to is the fields on your login page.

When you first open the file, run a script to login as this ultra low privilage user, resize your splash screen etc. etc.

Then...

Firstly, what you will want to do is use global fields - these are "special" fields, read up on them around the forums - for the users login / password.

Secondly, to authenticate via the filemaker accounts you simply run the script step "Relogin" specifying the login field and password field as the login and password respectfully.

Then, if the login is successful, you can wipe the users password and retain the user name for your utilization via scripts etc. later.

Any more specific types of questions give us a yell. I'm not exactly sure where i first saw this technique but it might have been on www.filemakermagazine.com

... good website

Good luck,

~Genx

[tusharguptait]

Hi,

I am using customized login script on the same lines but there is a problem. when user is entering a password it can be viewed by anybody. It is not coming as '*****' as should be in the case of passwords. Is there any method through which we can hide the text as user enters it in password field?

Thanks

Tushar

[Genx]

I use bulletfont... purely for the purpose of hiding what the user is entering at login -- you'd have to install it though on each of your client computers -- which isn't a problem if you do install packages.

[tusharguptait]

Thanks Genx.

[Genx]

No problem, but if you go with that idea, just remember it will only conceal the password (someone can still copy and paste to word and change the font)... but it does suit nicely for custom login screens.

Just for the sake of it, i've attached a screen shot of something i'm working on at the moment -- i had to blank out the product name.. - oh and i ah, felt christmasy..

[Steven H. Blackwell]

Oh my.

Everyone please look at the options in the Custom Dialog box or those presented by dialog plug-ins such as the one from Troi.

Please do not use or store ersatz passwords in your files.

Steven

[Genx]

I use bulletfont... purely for the purpose of hiding what the user is entering at login

remember it will only conceal the password (someone can still copy and paste to word and change the font)... but it does suit nicely for custom login screens.

... they arent stored? These are globals that are cleared once FileMaker authentication using the Re-Login Script step is completed. Where do i recommend that these passwords be stored?

[Genx]

72576 146664 402948 565600 834260 1062936 755090

As per storing passwords in general, if you can tell me each of the 17 variables (i'm being nice and telling you the variable number of variables) used to encode the string "lauders" in to the above i'll give you $100 (I'd offer more but i'm poor).

[Steven H. Blackwell]

You're protecting against the wrong threat if this is a "password" that is actually a data element in the file rather than a real password that's part of the security schema.

Steven

[Genx]

...These are globals that are cleared once FileMaker authentication using the Re-Login Script step is completed

[Steven H. Blackwell]

Why are you using this screen with a relog instead of the credentials challenge modal dialog?

Steven

[Genx]

1) Because it's ugly, 2) Because it's ugly... 3) Because i can 4) I'm still using FM Security, the account that has access to that page has access to that layout, those two fields and the login script ONLY... I don't see what the big deal is?

By the way, when you say "credentials challenge modal dialog"... you are just referring to the standard FM relogin dialog right?

[Stuart Taylor]

Hi Genx,

Steven may mean that as of course this is the most secure due to the fact the user being challenged has no level of access to the file at all.

but he may also mean the standard dialogue box in which you can specify that the text use password characters.

best

Stuart

[Steven H. Blackwell]

'm still using FM Security, the account that has access to that page has access to that layout, those two fields and the login script ONLY... I don't see what the big deal is?

The file is now open. If your log-on or re-logon process is interrupted then it's opened in a state that might reveal more information than you think it does. This would depend on the architecture of this file and of any related ones and how tightly the privileges are set.

Without seeing these files, I can't say. [color:red]What I can say however, is that this is a principal attack vector for extracting data and for promoting privileges.

Steven

[LaRetta]

I would like the User field to retain the user name for the user workstation but of course NOT to retain the "Password" that was entered.

At least on Windows, the Account Name can pre-fill according to the Windows logon name. The password should only be handled through proper FM account logon.

[Genx]

What I can say however, is that this is a principal attack vector for extracting data and for promoting privileges.

... Attached is the script I call from login.

Perform Script[Re-Login ; Fromfile: BackendFile]

If( Get (scriptresult) <> "Success" )

Set Field [LoginCounter ; LoginCounter + 1]

If[LoginCounter = 4]

Exit FileMaker

End If

Else

Perform Script[GetPrivilegeNameAndPass; Fromfile: BackendFile ]

Set Variable[ $login ; GetValue( Substitute ( Get(ScriptResult ) ; "|" ; ¶ ) ; 1 ) ]

Set Variable[ $pass ; GetValue( Substitute ( Get(ScriptResult ) ; "|" ; ¶ ) ; 2 ) ]

#useless without a backend login anyway, the front end is a dataless UI shell -- only used to control layout navigation.

#besides, bypassing login using the shift key takes you to a toolbarless layout

Re-Login[ AccountName: $login ; Password: $pass ]

End If

Please explain further the concept of "privelge set promotion".

ReLogin_Script.pdf

[Stuart Taylor]

Hey Genx,

If i'm understanding this correctly it is less the script and more the initial access permissions on the backend file.

For you to Re-Login do you not have to have an auto-login setup on the backend file.

In that way your attacker is already into the file to begin looking around for vulnerabilities.

In the past i have used some pretty dumb methods to extract data from a clients old solution to implement my own... and the old auto login has always been there for me to execute scripts and often read data that i really shouldn't be able to. Once a file is open you can ususally document its whole architecture.

So when OAM says he would need to see the file i think it would have to be the whole file. One small slipup and your compromised.

On the other hand if they have no access to begin with!

(ps love the snowman login screen)

Maybe i'm wrong.

[Genx]

... The backend login has the same welcome account as the front-end, if you login to the first file and there is an account with the same login / pass in the second file that is referenced from the first file it logs you in.. -- there is no additional login script.

The welcome account in the backend has access only to those two fields (which are stored in the backend) and the one re-login script pictured above.. The welcome account in the front end has access only to that script written above

[pjdodd]

I admire and share your enthusiasm to make Filemaker solutions less ugly, however, until Filemaker include some proper application and development graphics (and design tools) I would advise caution before diving straight in.

1) Bullet Font.

StuartT is right - use the password field from custom dialog. ALL common fonts have a built in bullet character (option-8 on mac, I assume Alt-8 on PC). Having to install a separate font is asking for trouble, especially when upgrades or system maintanence affects that font and your solution decides to pick a nice plaintext font to show your data! In terms of font usage in general it is wise to stick with the standard (if ugly) system fonts because they work, all the time, every time. And it's less work for you.

2) Sensitive field data.

After the user has entered their information you say the field is cleared. That sounds ok, but being cautious I would clear the field, Commit Record, enter some random data in the field, Commit Record, then clear the field again. By forcing the writing of the data and then over-writing with random gibberish you make it a little harder I think. This might seem paranoid but just as deleted files are not really deleted, cleared field data might not be really cleared until it's overwritten. I'm not sure on this point because I also think it matters whether you have single or multi-file solution and if it's standalone or over the web.

3) Multi-File Solutions.

StuartT is right to urge caution as it is very easy to slip up with multi-file solutions and assigning security priviledges. I'm a shameless advocate of single file solutions for many reasons but one of those reasons is avoiding the problems of checking for possible security holes. It is the permissions on the backend (data) file that surely matter most and I think it is this file that other posts are alluding to. Careful, careful, careful. If in doubt, grant as little access as needed using priviledge sets.

4) Re-login process.

The script and procedure seems well enough to me. I think you should have more confidence in your solution than others want to you have. I also think you should not listen to advice that doesn't come in plain English and definitely does not have any "possibles", "mights", "maybes" and so on. They don't really help do they.

5) Standard Alternative

Wouldn't it be nice if someone, anyone, actually created a Custom Login screen script and method that we could all copy, that was as secure as it could be but still visually beautiful? I don't think I've seen that one on the Sample File forum yet...

[Genx]

1)Bullet Font

... It's installed using an install package not manually and it's only REAL purpose is to temporarily conceal the data in case someone is looking over the person who is login in..'s shoulder -- it's installed with every update of the software so i'm not sure it's a huge issue in itself.

2) Sensitive field data.

Global fields.. session specific anyway, file starts with values emptied, only that session can see the data even if the field isn't cleared properly for whatever reason.

3)Multi-File Solutions

Again, the privelege sets are almost identicle

FrontEnd: Login -- Welcome, Pass -- Welcome

Permissions -- 1 script, 1 layout

BackEnd: Login -- Welcome, Pass -- Welcome

Permissions -- 1 script, 2 fields

Because the logins are the same logging in once in the front-end removes the need to have to login in the backend as long as the account login and password is the same.

4) Re-login process.

I have confidence in my solution only because it's been questioned, sometimes with maybes and mights, before and i've done everything in my knowledge to address those questions -- I still agree with you here in principle though, for someone to make me change the way i do something i need solid reasons.

5)Standard Alternative

Yes :)

[Stuart Taylor]

One last thing to add...

And this is purely a question ... i do not know the answer.

When your passing a value/s (password) from a front end file to a backend file in filemaker is it in plain text and interceptible by someone listening in to network traffic?

This is less in relation to your file Genx and more to do with wanting to know how filemaker handles this kind of thing.

If a backend file is on the web this could be a big issue.

Always wondered about this and seperation model techniques.

Best

Stuart

[Steven H. Blackwell]

The precise method depends on the OS of the Server and of the workstation running FileMaker Pro. But since FileMaker Pro 7 the credentials are sent in an encrypted fashion using as its base the PKCS5-PBKDF2 algorithm developed by RSA Laboratories.

Steven

[Stuart Taylor]

Many thanks,

Great to know.

[tusharguptait]

Hi,

I am required to create an advanced customized login screen. I need to create a login screen similar to we see on mailing sites like yahoo or gmail etc. User will enter login-id and password and if authorised then he/she will be directed to *.fp7 application. I am working on FM Pro 8.5 and this application is designed for both Windows and MAC(accessible thru FM & IWP). I tried guest login/re-login option thru custom login screen but it doesn't look safe to me. Also bullet font need to be installed seperately. Please suggest me a simple and secure solution.

Thanks,

Tushar

[Genx]

Just use the relogin step with dialog -- It's the simplest and securest way to go.