1 2 Previous Next 21 Replies Latest reply on Mar 6, 2009 8:56 AM by ninja

    Password Protect A Script

    dekade1

      Title

      Password Protect A Script

      Post

      I am wanting the execution of a script to be allowed ONLY AFTER the entry of a correct password. How do I get this accomplished? I would also like the field where I would type in the password to not show the actual characters of the password - maybe **** or something like that. Also, if possible, more than one password would have the capability to execute the script.

       

      I hope someone can help on this.

        • 1. Re: Password Protect A Script
          raybaudi
            

          dekade wrote:

           

          Also, if possible, more than one password would have the capability to execute the script.

           


          Hi dekade,

           

          where do you want to store those passwords ?

          • 2. Re: Password Protect A Script
            ninja
              

            Howdy dekade,

            Thanks for the post.

             

            I have password transactions in some of my databases.  THere are two main ways I've found to to this.

             

            1. (Higher maintenance method) Write the password into the script.  Start with a custom dialog step that prompts the user to enter a password (hidden is an option in the custom dialog).  This password would then be put into a field by the custom dialog step.  After that, you can have the script continue with checks for the password match.  If only two or three passwords are expected, you can write an "If" or "Case" function to check against a value written into the script.  (If (passwordentry not= "acceptablepassword" )...exit script...End If

             

            2. If #1 would be too much script maintenance, create a linked Password Table and do a find for the password typed in in the custom dialog.  If (Get(FoundCount)=0)...Show custom dialog "Password failed"...Exit Script.  Doing it this way, you can also use the typed in password field and the password field on the PasswordTable to link the tables together and import (ie. SetField) other info across to log whose password was used to run the script for tracking and accountability if you want.

             

            The main answer to your question is to build the password check right into the beginning of the script itself.

             

            Is this what you're after?

            • 3. Re: Password Protect A Script
              comment_1
                 Any solution that stores its own passwords is inherently insecure. The proper way to implement this is to require a re-login (there is a script step for this) and then proceed according to the privilege set gained by the re-login.
              • 4. Re: Password Protect A Script
                dekade1
                   I'm not sure Daniele. That is part of everything I am asking for help on.
                • 5. Re: Password Protect A Script
                  dekade1
                    

                  Ninja,

                   

                  Thanks so much for your help and suggestions. I do think idea #2 is what I am most liking. I'll have to study it for awhile to see what you are really getting at. The bad part is that I got delayed today and won't be able to get back at this for a week or so.

                   

                  If, at that time, I have trouble figuring it out in my environment would you mind if I got back to you again asking for help?

                   

                  Thanks Again,

                   

                  Dekade

                  • 6. Re: Password Protect A Script
                    ninja
                      

                    Howdy dekade,

                     

                    Anytime.  I didn't go way into detail since I've seen your previous posts and know you're well versed in design.  As you think it through, feel free to ask what you will.  There are always dozens of ways to skin a cat.

                     

                    Comment's point is well taken too, and I've since been considering it for some of my app's, though it really comes down to striking a balance between ease of use and the necessary level of security.  Both of these should get a sharp eye.  For my current apps, I don't think a relogin is appropriate, but I can easily imagine cases where it would be the best choice.

                    • 7. Re: Password Protect A Script
                      comment_1
                        

                      I don't see why a properly secured system would be any harder to use than an unsafe alternative. The user's experience is the same for both: you initiate an action, and you are asked to provide your credentials before you can proceed.

                       

                      As for implementation, I believe it's much easier to take advantage of the built-in wheel, rather than inventing a new one (which will be wobbly anyway).

                      • 8. Re: Password Protect A Script
                        ninja
                          

                        howdy,

                         

                        "you initiate an action, and you are asked to provide your credentials before you can proceed."

                         

                        Right and wrong.  I initiate an action and I need SOMEONE ELSE'S credentials before I can proceed...and after that action is complete I should be limited to my own credentials again.  The "buddy" should not have to wait around to verify that I logged back off of his account, or a subaccount that only he has the password for.  And relogin a second time to get back under my privilege set is a hassle when you do it 60-100 times a day (as do others).  Your point is understood, and given credit, but it is not a solve all...it is a very valid point to consider among the other methods based on thier strengths and weaknesses.  Databases are used in all types of industry...

                        • 9. Re: Password Protect A Script
                          comment_1
                             I am afraid I still don't see your point. Say there is a user and a supervisor. The user wants to do something for which a supervisor's approval is required. The supervisor comes over and enters his/hers credentials, the action is done, and the supervisor is logged out. This could all be done within the same script, so there's no need for the supervisor to hang around.

                          As for logging the user back in: if users log in with a password, then requiring them to re-enter the password is good practice, IMHO. Otherwise a third person could take over the computer when the script has run out. I don't think it's such a hassle, especially since the procedure protects not only the solution, but also the users themselves.

                          However, if you find it is too tedious, I suppose you could let the supervisor log in into another file and give their approval from there, while the user stays logged in the original file.


                          In any case, I cannot agree that these are two equally acceptable solutions, with pros and cons to each. One is secure, and the other is not - and security is the issue of this thread.



                          • 10. Re: Password Protect A Script
                            ninja
                              

                            howdy dekade,

                             

                            comment and I have started a discussion on your thread.  I think it's still appropriate since it's centered on your initial question, but if you feel we're hijacking the thread and going off of your desired topic, please speak out.  You started it...let's make sure you get the answers you need.

                             

                            That said, I'm willing to be sold a new way to handle password protection...even for my existing apps which I think are aptly secure (very biased opinion of course...I built them).  comment, please sell me otherwise.

                             

                            Define: User, provider, buddy, supervisor, manager (typically five different people)

                            *** means password entered

                             

                            Perspective:

                            1. user enters data and requires manager to review and sign off***.  No sign-off, no further progress. (manager does so at thier computer)

                            2. supervisor approval mandatory***, after manager review, before provider can go. (done at supervisor computer)

                            3. provider requires buddy to confirm data entry[***x3] (done at provider's computer)

                             

                            One person may have any combination of roles except provider and buddy which MUST be two people.  Only people with ALL ROLES have "Full Access" to Dbase and have access to the Password Layout based on the password table.

                             

                            Please show me how you would propose to do this more securely than I currently have it and explain what security threats I currently have.  I see loopholes, but consider them tolerable, I'll thank you for making me more secure if it costs equal or less labor to use it than the current dbase.

                            I know you're very good...I'm willing to learn.

                            • 11. Re: Password Protect A Script
                              dekade1
                                

                              Comment and Ninja:

                               

                              I think I'll chime in here. I can understand fully the re-login situation from Comment. However, let me elaborate on the whole scenario at hand. The database is a Raw Materials Inventory database. There are about 30 scripts that contain complex steps to enter raw materials into and out of inventory. There are customer allocations, there are shipments, there is stock, there is hypothetical stock available after all allocations, there is parts room amounts, there is on property amounts and the list goes on. Now, in order for all of that to happen there is employee interaction from the production department to the receiving department to the shipping department. The database has about 20 different layouts. Each layout has about 1 minimum to 4 maximum links that upon clicking on them triggers a given script into operation. Now, here comes my reason for not wanting to use a re-login. Let's take an example of one layout here. This would be the Pre Bin to Bin layout. A Pre Bin shows all the different parts, and quantites per each part, allocated out of stock for a particular customer. Now, comes into play the day that production wants to create an actual bin of parts for customer XYZ. Production goes to the Pre Bin to Bin layout. That layout shows all of the parts for customer XYZ. Also on the layout is a button to set into action the transfering of parts out of the imaginery Pre Bin status into the real world actual Customer Bin status. Also present on the layout is a field that you can enter an inventory part number that does not show on the current found set but can be found and the current found set can then be extended. Thus there is a button to initiate a script to find that part and extend the found set. So now we are at the real issue and need for a password protected script. SCENARIO: An individual has been through half the parts in the found set entering qauntity data for each part to show how many of a part is actually in a bin compared to the actual amount really needed in the bin. Why would they do that? Because the stock room my have 55 of part A for Customer XYZ. Customer XYZ actually needs 75 of Part A. Thus a trigger oocurs in inventory that shows Part A needs to be ordered. Then the individual discovers that Part H is not in the found set at all. Thus he wants to extend the found set to include Part H. Face it, many people (employees) get mouse happy and over anxious. Instead of clicking the button that extends the found set for the found part the individual clicks the button that sets the multiple entry Pre Bin to Bin procedure into action. Now that operation has been screwed up becasue it has incomplete data. THUS - I need a password enabled script. I cannot re-login in because I cannot not get back to the existing state of work without a humongous detailed script. Thus I totally believe there is very much a place for a password enable script to protect things from happening prematurely.

                               

                              See where I'm coming from?

                               

                              Many "respected thanks" to all of you in this discussion.

                               

                              Dekade

                              • 12. Re: Password Protect A Script
                                dekade1
                                  

                                By all means Ninja. This is great stuff I think. So let's all work together and solve it. Thank you so very much. This means a lot to me.

                                 

                                Comment and Ninja:

                                 

                                I think I'll chime in here. I can understand fully the re-login situation from Comment. However, let me elaborate on the whole scenario at hand. The database is a Raw Materials Inventory database. There are about 30 scripts that contain complex steps to enter raw materials into and out of inventory. There are customer allocations, there are shipments, there is stock, there is hypothetical stock available after all allocations, there is parts room amounts, there is on property amounts and the list goes on. Now, in order for all of that to happen there is employee interaction from the production department to the receiving department to the shipping department. The database has about 20 different layouts. Each layout has about 1 minimum to 4 maximum links that upon clicking on them triggers a given script into operation. Now, here comes my reason for not wanting to use a re-login. Let's take an example of one layout here. This would be the Pre Bin to Bin layout. A Pre Bin shows all the different parts, and quantites per each part, allocated out of stock for a particular customer. Now, comes into play the day that production wants to create an actual bin of parts for customer XYZ. Production goes to the Pre Bin to Bin layout. That layout shows all of the parts for customer XYZ. Also on the layout is a button to set into action the transfering of parts out of the imaginery Pre Bin status into the real world actual Customer Bin status. Also present on the layout is a field that you can enter an inventory part number that does not show on the current found set but can be found and the current found set can then be extended. Thus there is a button to initiate a script to find that part and extend the found set. So now we are at the real issue and need for a password protected script. SCENARIO: An individual has been through half the parts in the found set entering qauntity data for each part to show how many of a part is actually in a bin compared to the actual amount really needed in the bin. Why would they do that? Because the stock room my have 55 of part A for Customer XYZ. Customer XYZ actually needs 75 of Part A. Thus a trigger oocurs in inventory that shows Part A needs to be ordered. Then the individual discovers that Part H is not in the found set at all. Thus he wants to extend the found set to include Part H. Face it, many people (employees) get mouse happy and over anxious. Instead of clicking the button that extends the found set for the found part the individual clicks the button that sets the multiple entry Pre Bin to Bin procedure into action. Now that operation has been screwed up becasue it has incomplete data. THUS - I need a password enabled script. I cannot re-login in because I cannot not get back to the existing state of work without a humongous detailed script. Thus I totally believe there is very much a place for a password enable script to protect things from happening prematurely.

                                 

                                See where I'm coming from?

                                 

                                Many "respected thanks" to all of you in this discussion.

                                 

                                Dekade

                                • 13. Re: Password Protect A Script
                                  comment_1
                                     I am afraid I don't quite follow. If all you want to do is prevent an accidental mouse click, wouldn't a "Are you sure…" dialog be enough?

                                  Also, it seems to me that the procedure you describe has a problem of not leaving a trail (thus no way back). I am saying this with reservation, because I didn't really understand your description. But if this is so, I would concentrate on fixing that part.
                                  • 14. Re: Password Protect A Script
                                    comment_1
                                      

                                    Ninja wrote:

                                     

                                    Please show me how you would propose to do this more securely than I currently have it and explain what security threats I currently have.


                                    I feel this would really be trespassing on the thread. Just briefly: #1 and #2 do not seem to pose a problem, since the approvers are at their own computers. And I've already said what I think re #3.


                                    1 2 Previous Next