13 Replies Latest reply on May 11, 2012 6:35 AM by jormond

    Discussion - Password change - business rules!

    CarstenLevin

      Case:

      Busness rule: Users has to change password at least every 90 days.

      Paswords has to be at least 8 characters.

      Users may not use the same password again - ever or maybe within 180 or 360 days.

       

      Procedure:

      You can force a password change every 90 days. Fine.

      You can force the passwrod to be at least 8 characters. Fine.

      The procedure in FileMaker will not permit you to re-enter the old password. Nearly Fine

       

      Problem:

      When changing you can not use the old password as the new one. Perfect!

      But then you can go back and change password again, and now you can choose the previous one.

       

      Solutions:

      If the business rule also says that we must not store the users password in any form in a table, then we can not solve this.

      If the business rule permits that the developer stores the passwords in a very protected form in a filemaker file, then we can test for repeated use and more tricky rules (like using of capital/non capital letters, special characters, numbers etc). This is easy to do with FileMaker ... but in many cases will be a breach of business rules.

       

      Discussion:

      Have you had to solve this?

      How?

      Should FileMaker build in more complex rules for passwords and password change?

       

      pw01.jpg

      pw02.jpg

        • 1. Re: Discussion - Password change - business rules!
          jormond

          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.

          • 2. Re: Discussion - Password change - business rules!
            Paul Jansen

            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.

             

             

            Regards

             

            Paul Jansen

            • 3. Re: Discussion - Password change - business rules!
              Mike_Mitchell

              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?

               

              Mike

              • 4. Re: Discussion - Password change - business rules!
                usbc

                Carsten,

                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.

                Chuck

                • 5. Re: Discussion - Password change - business rules!
                  CarstenLevin

                  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?

                  or

                  • 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?
                  • 6. Re: Discussion - Password change - business rules!
                    Stephen Huston

                    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.

                    • 7. Re: Discussion - Password change - business rules!
                      Malcolm

                      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.

                       

                      Malcolm

                      • 8. Re: Discussion - Password change - business rules!
                        Stephen Huston

                        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.

                        • 9. Re: Discussion - Password change - business rules!
                          Fimano

                          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"... ;-)

                          • 10. Re: Discussion - Password change - business rules!
                            CarstenLevin

                            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.

                            Best regards

                            Carsten

                            • 11. Re: Discussion - Password change - business rules!
                              jormond

                              Carsten,

                              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 ).

                              • 12. Re: Discussion - Password change - business rules!
                                CarstenLevin

                                Hi Joshua,

                                 

                                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.

                                 

                                Best regards


                                Carsten

                                • 13. Re: Discussion - Password change - business rules!
                                  jormond

                                  Agreed.  I find that when FileMaker sees a lot of people using specific features in plugins...they tend to adopt those features more quickly.