How can I store a string as an encrypted password string?


Can I encrypt a string before it is stored, in this case as an internal password? Can I unencrypt the stored password to compare to a user input string as a lock to open a certain portion of access to code functions?


I am creating DEMOs where the main procedure file has a #pragma hide=1, where I ADOPT the procedure into the experiment, and where HIDEIGORMENUS is part of the demo setup. By the time I am done, a typical user cannot see the adopted procedure file, access Igor Menus, or access the browser. The experiment just shows what I want the user to see.

I am toying with a way to incorporate a password string that is required to reopen the (hidden, adopted) procedure. I hope to store the password string in a root:Packages:MyPackage:password global string variable as the easiest path for me to administer. But, doing so means the string is accessible to anyone with some insights to the browser structure, e.g. after doing a ShowIgorMenus command.

Is this possible to do through string encryption as I think it could be?


If the cunning user can view the procedure but not edit it, then using a HASH may be a solution. For example:

String/G gsPW_HASH = "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8"

Function testPW_HASH(sPW)
    string sPW
    string sPW_HASH
    if (cmpstr(sPW_HASH,gsPW_HASH) == 0)
        return 1
        return 0

Function test()
    string sPW
    print sPW,testPW_HASH(sPW) // result=0

    print sPW,testPW_HASH(sPW) // result=1
    print sPW,testPW_HASH(sPW) // result=0

If is very hard for a user to guess the password that created the given HASH.

I would simply have your procedure look for a global variable in a certain location and, if it exists, check that its value is some expected value. If a user is familiar enough with Igor to find the code that checks that global variable (or, in your original idea, your encrypted password), they're very likely capable of short circuiting the check for the "password" in the first place.

You could store it in package preferences.

DisplayHelpTopic "Saving Package Preferences"


In my experience, a typical user would never have the willing to read or study the procedure, even you leave the procedure in the menus normally, not to mention that you have set so many obstacles  to keep them out from it.

However, if it is really needed, I would have a function in the adopped hidden procedure to do the check, just as KurtB's way, using a HASH string to store the password. If the check failed, the file can not be oppened, so the user dont have chance to make the check short circuiting.

I think wings is probably pretty much correct, though a determined user could use an external text editor if they really wanted to (unless you encrypt the procedure file).

If your aim is to protect proprietary information, I suppose all this effort is justified. If you are simply trying to make it difficult for a clueless newbie (such as we all were at some point!) to accidentally modify your demo, then it seems like this effort is not necessarily justified. It seems like you have already rendered it difficult to alter accidentally, and a persistent user gets what they deserve- a broken demo.

Thanks to everyone for the suggestions.

I am not needing to encrypt procedure files for this development. The request to have an encrypted password string is an idea I might add into an update to Demo Setup Tools to provide an additional step to lock-out switching a demo package back to full behavior, at least for the general user.

I tried the HASH method. Neat idea (thanks @KurtB)!! Unfortunately, even with this approach, I will still have to hide the (hashed) global password string in the browser. Otherwise, all that a clever user needs to do is to type showigormenus, open the browser, and delete the global password, hashed or not. Ultimately, there is no easy way around the fact that anyone who is clever enough can eventually get to see the procedure files included/adopted into an experiment regardless that they are initially hidden and/or adopted, which is likely what @Adam also meant.