Logging Screen

[panchristo]

Hi all.

I've read several topics about the potential dangers of using Ersatz security systems and I am pretty convinced about it.

What I'd like to know is if there is any simple way to make an intrusion-safe custom log-in screen. In my case, I would benefit greatly because FM is not supported in Greek.

Is capturing log-in data in a "blind" layout using globals and injecting those into a re-login script considered safe?

[panchristo]

ANYONE?

[Vaughan]

What I'd like to know is if there is any simple way to make an intrusion-safe custom log-in screen

No. There is no simple way.

There is probably not even a difficult way.

Analogy: I tell the professional security guard outside my house (the built-in FM security) to let you through the door, then when you're in my living room I ask you who you are (my custom log-in screen). You are in my house already. That's not secure.

[LaRetta]

:waytogo:

[comment]

Well, I don't know. You're welcome to shoot holes in this idea:

An opener file that automatically logs into a dummy account with practically zero privileges, presents a custom dialog with two global fields, performs a relogin and clears the globals.

[panchristo]

Crisp and clear as usual!

Thanks.

[Vaughan]

Comment: that's an excellent question. :

Why post a custom dialog and store the answer into global fields? Why not re-issue the Login step. But then the question would be "Why not do that in the first place?" The original poster needs to explain why the built-in authentication does not work in Greece.

HAVING SAID ALL THAT... I have been thinking about doing something exactly like this myself, but am loath to do so because I KNOW I'll live to regret it.

Steven Blackwell, now would be an excellent time to share your expertise. :

I'm currently working with FM Go and getting my head around the concept of two different classes of device/interface access the database. (There are actually more than 2: IWP counts as well, and Server side scripts may be a 4th. These are all results from the Get( ApplicationVersion ) function, and all have different limitations on scripts and interface and so are essentially different "devices".)

What I'd like to do is have an account for a user set up so they log-on on a desktop and get a certain interface and privilege set; however when they log-in on a mobile device they get a different interface and privilege set. Giving therm the different interface is easy; it's the different privilege set that's hard.

I don't think the FMP security model can manage this: a user account can only only have one privilege set assigned to it. Setting up separate accounts (say "vaughan" and "vaughanipad" would work but would require the user to remember to change their login based on the device they are using: getting them to remember one is hard enough!

A work-around would be to log-in with one privilege set, then switch to another. But that would mean either prompting the user for a different account name a password, or storing the credentials and log-in them in silently.

The former (prompting for a different account) means duplicate accounts need to be set up for each person and I can see a usability and configuration nightmare there. It's really just saying to the person "Use your other account on this platform" and being rather blunt about it. The other option (silent re-login with stored credentials) means that the Get() functions associated with security will be screwed, the stored credentials are a security risk and if the account credentials change the process breaks.

In both cases though, we've opened the door and let the intruder into the living room.

What might be needed is for the security model to recognise the platform or application version, and use this to conditionally assign privileges. So one account/password can be assigned multiple privilege sets depending on platform.

(I have no doubt that the engineers in FMI have already considered all this and are probably working on it. IMHO the reason there are so many new bugs in FMP 11 was substantially re-written for the new mobile platform.)

[bcooney]

Why the need for a different priv set? I suppose it's bcs you don't want to rely on the restricted interface you've crafted for non-fm clients?

[Vaughan]

Barbara: that was quick! You might want to re-read my post above I've made some changes.

You're on the right track: I can see you grok the mobile thing too.

The mobile platform's inherent "transient" nature - it's only a phone call away from instant program termination - means I really want to restrict what the mobile user can do. Mostly just view data, maybe change a few fields like update contact info. Definitely NOT a process that modifies multiple records that if interrupted will leave the data in an incomplete or undefined state (ie, phone rings, battery dies, network drops out, Home button is pressed... process stops dead.)

So when I log-in, I want to get normal user privileges if I'm using FM Pro but want to get limited privileges if I'm on a mobile device running FM Go. I don't want to have to log-in with a second "mobile" account because I'll always forget and will get annoyed when I get told to use the other account name.

New thought: I just realised that it may be possible to create an extended privilege that can determine whether the user is on FM GO and restrict access, but not conditionally assign privilege sets.

[comment]

why post a custom dialog and store the answer into global fields?

Because they want custom (Greek) labels for "Account Name" and "Password".

Steven Blackwell, NOW would be good time to share your wisdom!

I'll second that, and add another situation to consider:

A cashier needs supervisor's approval. The supervisor comes over, logs in using their account, approves the action and...?

Ideally, they would log out completely, leaving the cashier to start from scratch. Alternatively, they could re-login into a "dummy" account, leaving the solution open for anyone to (re)log in and start working immediately. What are the dangers here?

Re your issue, I think you have two options, depending on the exact privilege: if it can be defined as conditional, than use that with Get (ApplicationVersion); if not, deny the privilege and make it accessible through script only.

it may be possible to create n extended privilege that can determine whether the user is on FM GO

How exactly would that work?

[Vaughan]

How exactly would that work?

Errrrmmm...

... it won't. Extended privileges aren't anything like I expect them to be. I haven't really played with them in the past. I expected some kind of calculation engine to appear, but no it just allows the definition of a key word and it's assignment to a privilege set.

I can see their utility to allow privileges to be assigned outside the rla dialog by people without full access.

[RodSierra]

All good info, I just hope fmi will also listen, there needs to be access to privileges on a more controlled basis. Right now its full access or nothing, I've wanted to be able to allow a user administrator to assign privileges to end users within the realm I define for a long time. Right now there is no way to do this, in a complex solution the variations are just too wide to try and write all the different options into separate priv sets.

[Vaughan]

This is exactly what extended privileges can be used for. Unfortunately there is some assembly required. The ability to assign (not create) extended privileges can be assigned to any privilege set. The extended privileges then need to be checked in any action that requires the control.

Eg, the ability to change a table of tax codes.

Create a extende privilege "changetax". In the rla for the tx table, use the calculation:

not isempty( filtervalues( Get( currentextendedprivileges ) ; "changetax" ) )

At least that how I THINK it should work. Haven't tried it yet. :

[bcooney]

Still not seeing why you need two priv sets. You will control the functionality available with the limited interface that they'll be trapped in when they login.

Also, I will definitely build all multi-record edits using Todd's transaction model (if mobile users even get access to a transaction button).

[bcooney]

Greek labels for login/password are needed, but the rest of the interface can be in English? Or, I suppose the entire interface is multi-lingual...

[Vaughan]

Still not seeing why you need two priv sets. You will control the functionality available with the limited interface that they'll be trapped in when they login.

If the mobile access only allows view of certain records, I want the privilege set to ONLY allow that. Restricting the interface does not guarantee security.

I could possibly do this right now, but it would mean going into the RLA setup screen and for every table setting the view, edit, and delete options to limited and adding a calculation that checks the application version. Then doing he same for layouts, scripts, and value lists. That is a large amount of work and a potential maintenance headache. It might be a performance hit too.

Tell me more about Todd's transaction model. :

[bcooney]

OK, whatever, I suppose I put more faith into controlling navigation (probably misplaced).

http://www.geistinteractive.com/blog/2010/07/transactions-cheat-sheet

[Vaughan]

Oh wow that's cool. Very sensible stuff.

I was fearing it would be some kind of transaction system emulating what Oracle has, something that becomes an end in itself. Where each edit has a record record what happened.

[panchristo]

Greek labels for login/password are needed, but the rest of the interface can be in English? Or, I suppose the entire interface is multi-lingual...

Unfortunately, if you live and work outside the "known universe of common languages" you simply do not exist. Therefore, I'm trying to substitute as many app dialogs I can with custom ones in Greek. No question on the Layouts and Custom Menus too.

I wish there is a greek update in the future ( ) - I could even imagine myself contributing to it...

... using Todd's transaction model (if mobile users even get access to a transaction button).

What's this? Any links available?

[Vaughan]

Trivia Q: which foreign language has been standard on Macintosh and Windows since their first release?

A: Symbol font, it's Greek.

Fot Todd's method follow the link at the bottom of Barbara's post above.

[comment]

It's all Greek to me, but I believe the Symbol font and support for the Greek language are two very different things.

[panchristo]

It's all Greek to me, but I believe the Symbol font and support for the Greek language are two very different things.

Can't agree more than that. We 're talking about app messages etc.

[RodSierra]

With regards to Greek localization, this may be of interest:

http://www.winsoft-international.com/en/press/filemaker-pro-85-czech-polish-and-extended-english.html

Although not specific to Greek, these folks seem to have the ability to do it, and this link does mention Greek in some aspects.

[Steven H. Blackwell]

I am in transit to DevCon activities and so cannot get really deep into this question just now.

But I would not as a general rule that these ersatz log-ons really are not secure and present various vulnerabilities for manipulating things in the file. I'd have to test the specific instances here to render a further opinion.

Stick to what FileMaker has given you including External Server Authentication. That's your best bet for maintaining Confidentiality, Integrity, and Availability of your system.

Steven