We use a home rolled system that requries user accounts be created first by an administrator. The password starts out as the UserID and the user is required to change it on first access. All password access routines are within FileMaker so we control the file management. So a user changes a password, it then runs through various steps to make sure the FileMaker password is also changed in all files that the user accesses. So the user logons with the FileMaker system password dialog once, that's it, but any password / account manipulation goes through our routines in order to keep the files synchronized.
We use an SHA-512 one-way hash so the actual password is never stored. The administrator can always "reset" the account password to UserID if it is forgotten; user then has to change once more on access. I've also toyed with one of the 64 bit binary encryptions you can find on Brian Dunning's website and they seem to work fine also if you don't want to use a plugin for the hash.
Additionally, the user has the option to create a PIN in there account, handled pretty much the same way, for them to use on sensitive operations as extra security.
FileMaker already hashes user account passwords, though I don't think FileMaker has released such details as which cryptographic hash algorithm they're using. It seems redundant to hash a password before FileMaker hashes it again. If the first hash is any good, the second hash doesn't really have much to add in the way of information entropy.
The setup you describe would indeed make it difficult for an intruder with user-facing account credentials and a physical copy of your database to bypass your scripted log-in routines, but they could still get in via your scripted log-in routines, so I doubt that meaningfully improves security. It only makes it harder for you to get in without your scripted log-in routines, should that need arise (such as to debug the scripted log-in routine).
Removing the original account shouldn't be necessary for your password recovery scripting. The Reset Account Password script step works fine.
I personally prefer tokenized password recovery mechanisms over "we'll email you your new password" workflows, but if users are forced to reset the password themselves on their first login after the reset, it almost amounts to the same workflow anyway. The difference with the tokenized reset is that the user never has to enter the temporary reset password because the token is already in the reset link, and you can script a time limit on the token.
In your system, you have not improved data security, you have simply added a layer of obfuscation to one interface. Will you provide the same level of obfuscation on all interfaces, eg, CWP, WD, Go, xDBC, Pro?
What’s the point of saying “123” is pathetic. I’ll convert that to “xentdealfdergaeochtd” behind the scenes. If staff use the password “123” in the UI that is all a thief/attacker needs.
We always have a user table but a password is never stored there. We use a scripted process to provide users with a eight character password which is randomly generated. This is sent to them via email and their user record is flagged and timestamped. When they login they must create their own password. We force the user to change their password to ensure that the email records cannot be mined for passwords. The timestamp is used to ensure that the first login occurs within a set period of time. The flag allows us to control user access to data. Until the flag is cleared the user only has access to their user record.
Thanks chaps - three interesting views from which avoiding storing user passwords in the user table is the clear view - with 2 of 3 also liking forcing the user to reset - which has the advantage that they may be able to remember it and the disadvantage I guess that one then has to police use of trivial passwords?
The reset option avoids a lot of security design and testing but I haven't come across it myself amongst bigger systems.
The advantage I see of hashing between user input and the FM login is that it does protect ones IPR a little since no users know the password by which FM provides direct access.
The disadvantage is having to manually input a second pw when opening full access or saving security amendments.
The weight of the pros and cons would vary I imagine depending on the type of deployment?
Malcolm - I don't follow your first two paras - but I like your third.
Perhaps my focus is more on protecting IPR and yours on protecting data?
If for example one is licensing some users to undertake limited development work perhaps there may be some merit in permitting them only to access through the front door?
Our users don't actually have a two X logon. The administrator let's them know that the initial pw is their userid and then their first logon it is a forced change. After that we control everything involved with Filemaker accounts; password changes, enabling/disabling accounts, etc., using the account commands. We have two main files and we don't want them having to go through the process more than once whenever there is a change so the UI file talks to the other file(s) to synchronize changes. They just logon with the FileMaker logon dialog. It's all been setup and synchronized with the administrators setup of the account. The PIN is used as a non-FileMaker stored hashed pw for when they need to sign reports or do some other sensitive action, only known to them, it's maanged in their "My Account" page.
Perhaps my focus is more on protecting IPR and yours on protecting data?
How are you protecting IPR?
You are simply switching passwords - your system does that for the user so a password attack can be done via the UI and your system will look after the rest.
Malcolm - I suspect that your type of use of FM may be a little different to mine hence you have a different pov. I am primarily concerned with developing frameworks which make it relatively easy to customise different products from the same base.
I have been developing frameworks in FM since 2004 - the new Deskspace very useful free App is the first result of the second FM framework I have designed which I have been working on since April 2012 - so I spent 8 years on the first one.
A challenge I didn't solve was how to licence the framework to other developers as a tool without effectively making it open source - not that open source isn't a good thing in itself of course.
I am not sure you are quite correct in stating that an attack through the Ui is no different to a direct attack. Your comment assumes - I think - that your only security is provided by the FM security bit? That controls access to four elements data, layouts value lists and scripts plus some other features.
However, control of access to the rest of the developer Ui is surely also controlled by menus which are outside the security bit system?
So - perhaps there is a method - this is just a suggestion - of creating a priv set which would give sub developers the ability to do most things short of Full Access - controlled through the Ui - because they could only login in through the front door - so that holding down alt on startup and entering their un and pw would not provide any access? That would mean I think that they could be given the ability to do most things through a developer's menu but couldn't do anything requiring the correct response to the FM access privileges dialogue - for example neither change security nor use the debugger?
I don't know - this has just come from thinking about your and the other responses on this thread - I haven't yet tried this in practice - but I have the germ of an idea here - what do you think?
Thanks J - I think the hashing can perhaps add something - as I outlined in my response to Malcolm - what do you think - distinguishing between the pw a user requires for scripted access and the pw they would require for direct access?
William, thanks for the additional detail - and I like the idea of the users each having a PIN as another layer of authority. You are also creating artificial account names which is inherently much more secure than using plain user names.
control of access to the rest of the developer Ui is surely also controlled by menus which are outside the security bit system?
Menus are set on the layout, so the layout privileges cascade down to them. That’s probably as big a security hole as you can get. You may want to give someone the ability to modify a layout so that they can play with the design elements. Instead you are allowing them the opportunity to switch menu sets.
FileMaker Go has problems with Custom menus too. It doesn’t do them. FMGo users should get FMGo layouts and the status bar should be switched off and locked.
So - perhaps there is a method - this is just a suggestion - of creating a priv set which would give sub developers the ability to do most things short of Full Access - controlled through the Ui - because they could only login in through the front door - so that holding down alt on startup and entering their un and pw would not provide any access?
I have developed frameworks too. We established a hierarchy of roles. Role zero is full access. Role one is Owner. Role two is Director, then Senior Manager, Manager, Staff, Accounts, etc. When users login they are silently switched, using re-login, to one of these roles. The Account Name is the role, so the account name controls everything. Scripts fork based on Role level, Layouts bounce users to different layouts based on Role level, etc.
In these systems we allow the Owner to do everything possible without giving full access. There is a bunch of scripting which is locked, to ensure the system will keep working but the bulk of the UI can be tweaked. There has to be an ongoing relationship because they can’t edit tables. In some cases we take a licence fee and provide a full access password. The non-exclusive licence stipulates that the IP remains with us.
Thanks Malcolm, sounds like we have a similar approach - we normally build with eight different priv sets - which was quite tricky before the debugger arrived. Since everything in our systems is scripted it is not difficult to retain control.
We order all the tables layouts value lists and scripts by the priv set of users permitted to use them to make managing the privs as the framework develops easier.
We use a special script which is always called at the beginning of any user interaction within which we can set any required control measures.
All goto layouts are calced so that they automatically put users on the correct layout for their priv set and nowadays their device.
The significant difference with our new framework was building the developer Ui into the main Ui and controlling all the Nav and functions through an onscreen menu system - ie not FM menus - where the items available to each user are automatically calced according - again - to their priv set. No doubt you do something very similar.
This has meant for example with WD we can have foreign translators access the App and do their work from their browser and see their work in context in the Ui - which for me is a big step forward in our localisation procedures - no doubt others have been much smarter!
Thanks for a useful discussion - cheers Nick