6 Replies Latest reply on May 12, 2016 6:39 AM by wimdecorte

    Customer-generated user accounts


      I have read with interest and empathy the discussions on never storing passwords as data in the solution.  I appreciate the concerns, and would like to avoid the pitfalls.


      I have a solution that needs to allow the customer to create their own user accounts.  Scripting and managing that is easy: all done.  At the point of upgrade to the next version we would have an import routine to import all of their data.  As they will have created their own custom accounts we also need to replicate those into the upgrade clone.  We can do that easily if we store the account names - and hence the passwords - in the database; but that is what is frowned upon, bigtime.

      The users are often workgroups of 4-5 PCs - they have no need nor interest in a Domain and its Account management facilities.  How can we avoid storing Account names and passwords in the database, yet have an upgrade routine that allows them to see exactly the same data and access features as they had before?

        • 1. Re: Customer-generated user accounts

          If you don't store the passwords in your solution, you cannot recreate the accounts with the pre-existing passwords. and there is no way to extract the passwords from a solution.  The best you could do would be to recreate the accounts with generic passwords, and set the FileMaker accounts to require a new password on next login, and then allow the users to reset their passwords.

          • 2. Re: Customer-generated user accounts

            Thanks, brsamuel - that's exactly what I thought.  I have been in paroxysms of religious anguish thinking how the 'ell can I avoid storing passwords, but still give the users a nice upgrade experience?  I just assumed there was an obviously better way to do it as everyone flames the idea of storing passwords (even if they are accessible only to the Admin account), but apart from using External Authentication no-one suggested any alternative.  I read references to using the passwords MD5 hash, but I couldn't see how that avoided the issue.


            If I set the password to a random set of numbers (say) then:

            - I would have to be able to find out what that password is so that I could inform the user(s).  Obvious problems all round, there.

            - I would have to have a method such as 'Reset it to be the username', and, well: 'see above', as people catch on that immediately after an upgrade "I can guess your password, nah nah nah-nah nah!".

            - The customers have serious problems remembering any passwords (strictly: they log in with a 'Group' password, for all staff in a department across all shifts, to determine their access rights. The 'individuality' is that they can only do more actions after a 'signing in' process with a unique PIN.  Which is stored.  (Which they can change at will.  Which has then the same characteristics as the 'Account Password' issue.)


            I appreciate your pointer that 'they are required to change their password at next log-in'.  Maybe that is the key: a little bit of upset ('Famous last words', across teams of 20+ people working over 4 shifts) in exchange for the additional security afforded by a password that... only 20 people know because they had to make sure that "Hank who only works on a Tuesday also knows it."


            Thanks very much: you've cleared my mind that there isn't an obvious way I've overlooked, and you've given me food for thought with the '...at next log in' option.


            Thanks again.

            • 3. Re: Customer-generated user accounts

              I have come up with a half-assed answer.


              - Script the creation of Account names and Passwords (as before)

              - Capture the password and 'encrypt' it.  (This is the half-assed part):

              - take each character entered and convert it into a Unicode number.

              - pad it to be always 5 characters, say (Right ( "00000" & Character ; 5 )

              - 'fudge' the number - oh, go on: add 13 to it or something

              - (optionally add more characters randomly, but store the true number of characters as the last 'number' in the string)

              - store the converted sequence as a string

              - create the Account using the correct password

              - delete the stored password

              - hence, 'No, I swear the password is not stored as data in the file  ...ish'


              When recreating the custom account names and passwords at upgrade the 'encrypted' password can be parsed and the true password rebuilt.

              I've done it, and it works.  A cleverer 'encryption algorithm' would be the key, of course.

              If someone can tell me how to truly encrypt and decrypt a password (bearing in mind the needs of practicality in this real-world scenario) that would be great.

              • 4. Re: Customer-generated user accounts

                Better than storing things in plain text obviously but still not truly safe and less secure than FM's native security.


                I would really think hard about doing this.  Especially if the only reason is to avoid having the users have to reset their pw.  Many organizations require their users to change their pws every 60-90 days anyway so doing it at update time should not be too big of an intrusion and would leave your solution safe.


                The thing is: if your solution can decrypt it then anyone can if they can find a way into your solution, because all the required pieces are there.

                • 5. Re: Customer-generated user accounts

                  I can appreciate all of your points, Wim - thanks.  The practical side of this is that there are 4 shifts of people who need access to the system.  The local Admin person and the Manager need to be able to create ,delete, and change the password of user accounts.  It would be distributed across maybe 20 customers.  There is no problem until the point of releasing an upgrade, and I just know it would create a huge problem for each customer to recreate and distribute a new set of passwords.  They just wouldn't put up with it.

                  The only way someone could decrypt the passwords is to have Admin access to the file, and if they've got that far, there are a lot of other Big Problems to worry about...


                  If I can think of a way to store the decryption 'Key' remotely, that might be a trick.  Or issue one, unique to each Customer, which has to be entered at the point of upgrade (to decrypt and re-encrypt) the passwords.  But then it would also be needed every time an Account is added or a password changed.  Which might not be a big problem.


                  As long as someone can't hack in as Admin there shouldn't be a problem.  And if someone can hack in, then they can do all sorts of damage without ever knowing what any other users' passwords were, so there is part of me thinks that the 'Password' security problem can line up behind the 'Admin access hack' problem in terms of priority.


                  I'll keep musing on it, but I can't think of any field where a solution could lie that wouldn't be exposed by someone having Admin access to the file.


                  Thanks for your help.

                  • 6. Re: Customer-generated user accounts

                    alangodfrey wrote:



                    The only way someone could decrypt the passwords is to have Admin access to the file,


                    That may or not may be true depending on how you implemented security, so don't assume that it requires [Full Access]...