To test it against previous passwords, you clearly have to store something. When I've had to test confidential info, I've used ScriptMaster to hash the password to store it in a table and then when the new password is entered, hash the new password to test against the stored hash value.
If I had these business rules imposed, I would do the same, but would probably use a custom function to hash the password so that Go was supported.
I suppose you could store the old password in a global variable and use this to prevent the user changing the password back to the original during the same session. A partial solution with nothing stored permanently.
I tend to agree with Josh and Paul. I don't know how you would verify a password history without storing a password history. If the business rules don't allow you to store at least a hash of the password in the database, it might be worth pointing out that a hash of the current password is already being stored in the database (else there's no way to validate credentials) ... so why would storing a hash of previous passwords be more of a security risk?
I think JO's encrypted table approach is where you will end up. Further, I think you will need to do it entirely via a scripted process as opposed to the built-in FM account system. This would, naturally, include the 90 day timer in the open script.
You don't say but in some requirements the password can not have been used by anyone / ever.
You will essentially be creating a new account and then deleting the previous account in the same swing.
Following all the inputs with great interest. The solutions suggested are not far from our thoughts, and I believe that in most cases we could get accept for storing hashed versions of passwords per user - to check against.
And the business rules like
- Must contain capital/non capital letters.
- Must contain both numbers and digits.
- Must contain at least one non alpha/digit value.
could be handled by letting the user enter the new password in a global field, check it with a script and then setting the password. Most of the time we need the global field (or variable + scriptparametres) because we are usually deploying multi file solutions.
If FileMaker should choose to strengthen this part of the security model
Which options would we like FileMaker to give us?
- New password must not have been in use for this user within the last [#] days.
- Validation of other business rules up against calculation engine?
- Validation against the friendly FileMaker interface with click buttons for [must contain both numbers and letters] - [must contail capital/non capital letters] - [must contain non alpha/digit values] etc?
There is one other rule I see as a benefit, especially in business situations where specific non-FM passwords are commonly used by multiple staff for shared access to specific areas of servers, etc.:
Prohibit the use of password strings in this list: [provide a place for entering return-delimited lists of passwords which are not allowed by anyone for anything in FM].
This would stop users who attempt to use a password that is known for non-FM access by mutliple users in the business.
When I first took over an in-house system, I found that over half of all staff were using the same password for logging into FM that they used for other network-wide access to specific server areas, etc., and that was the same password for all users. This effectively allowed me to guess and use passwords to login into FM as anyone of many of our users. I took this as proof that we needed to change the account management system -- one of my earliest revs of the full FM system. Staff hated having to have a separate PW for FM, but they all quit complaining after it had been in place a few months.
Staff hated ... but they all quit complaining after it had been in place a few months.
It only took a few months for the complaints to die down?
I've just looked at a system that was exposed to the web and it had the account open with very high privileges assigned to it. Every staff member had their own login and the web account had specific low level privileges so I turned the account off. Within 24 hours the head honcho was complaining that they weren't able to work in the database. The previous developer had set up accounts in this way so that head honcho would not have the indignity of logging in to the system that they owned.
In my case the security was approved at the top, when I pointed out that these commonly-known passwords left our data wide open to Former staff via web access -- so the rest of the staff had to adjust to the decision.
From a brief reading of this thread, I believe an obvious point is being missed: External Authentication! From my memory, either AD or OD (or both) allow this level of "password paranoia"... ;-)
Hi Jens, you are right. But in a lot of scenarios OD or AD is not in use or realistic. I am actually hoping that FileMaker will add the calculation engine and the possibility to automatically store the previous passwords hashed - to check against.
I was looking yesterday and saw that in addition to ScriptMaster, 2empowerFM also has a plugin that will do the hashing for you ( their Text Toolkit plugin, and it's free also ).
Thanks, and yes. The case is that I have no problems solving those issues with plugins, a frontend in front of the account model etc. etc. But I do find it important to raise the issue and hear what you other developers are thinking about this issue: And consider whether to ask FileMaker to add the calculation engine to set up Password requirements instead of the checkbox/expiration/number-of-characters.
Agreed. I find that when FileMaker sees a lot of people using specific features in plugins...they tend to adopt those features more quickly.