Extend Password-Protection of a VI to the Front Panel

[Ben_J1]

Most of the time the only part of a VI that needs protection is the block diagram but there are a few instances of why including the front panel in the password-protection would be needed. Someone can see the front panel of a subVI during run-time even if it is under layers of password-protected subVIs.

For instance, an encryption application. Except for the Top Level VI, all other VI's are password-protected.

During run-time, the Key for the encryption algorithm, which should never be known, is shown on the front panel of the Key Generation VI as well as the Encryption SubVI.

Of course one work around for this would be to hide all items on the front panel of each subVI but this will slow down further development in the future. The ability to just type in a password would allow a developer to instantly return to work.

Also, an alternative solution would be to allow password-protected Source Distributions.

Can anyone else think of an application in which the front panel of a VI should be password-protected?

Other Notes:

It is important to mention that it is possible to do things like Remove the Front Panel or Remove the Block Diagram, but this does not allow the VI to be recompiled for different targets. This is why a password-protected Source Distribution would be ideal.

[RavensFan]

Not sure if this helps in your specific case, but you could set the Key display format to be "password display".

[AristosQueue (NI)]

FYI, that won't help if someone has VI server access... even if the string is hidden... even if it uses password display... if the other person can do "Get All Controls" and then do "Get Control Value", the string will be the raw string.

In a built application, VIs are saved without panels and that keeps the panel from being accessible.

[AristosQueue (NI)]

To clarify, when I said "that won't help", I was referring to the "password display" workaround. Hiding the controls doesn't help either.

Your idea to add a password could work, as long as when we added the feature, we made all VI server methods/properties return an error unless the password was provided.

[Mr.Mike]

If you don't want to put something on the front panel, why not put it on the block diagram?  I'd like to see a more convincing example of why this is useful.

[Ben_J1]

Mr. Mike,

  In order to have modular coding, you need front panels objects in the subVIs to pass in controls and read out indicators. The idea behind this entry is to have the ability to modularly develop code that can be securely distributed for further integration and compilation.

  Perhaps in this simplified example you could take everything in Keygen and Encryption and just put it on the top level VI instead of being subVI's but in a more advanced application subVI's (and passing information into them) is important.

[AristosQueue (NI)]

I did some experimentation... if you mark the VI as inlined (LV 2010 VI Properties dialog >> Execution page), the inlined code does not talk to the source VI's panel. You are safe from someone opening the front panel and from all VI Server attacks.

[StephenB]

still can't inline a lot of VIs though because of properties/methods

[AristosQueue (NI)]

Stephen B: I wouldn't expect that most of the restrictions on inlining would apply to encryption algorithm VIs. Such VIs are almost always functional transformations; as such they should fit easily within the inline restrictions.

[Darin.K]

I would also consider Subroutine Priority to prevent displaying the FP contents.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.