LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Password Protecting VIs is Security Through Obscurity

Interesting, but only to the extent that It relies to a large extent on trusting the individual who edited the email address out of the article.

I think that this argument of trust by implication has already been hinted atSmiley Wink

So are you willing to put your reputation on the line and ..... verify the effectiveness of the proposed work-around?

In fact what is more interesting, is the extent to which users will then continue to trust the proposed mechanisms. Where this trust is undermined, it matters not how good the mechanism may or may not be.


Message Edited by Conseils on 07-13-2008 09:26 AM
0 Kudos
Message 11 of 13
(1,506 Views)

At the VI level, we're talking about protecting source code and source libraries that could be sold as part of a service offering or as a set of tools to a client.  It is more likely that those types of clients have little in-house expertise at at using Labview, and would unlikely spend time & efforts to break a password.  If they do, then they have too much time on their hands...

However, those same VI's could end-up into a competitor's hands...  So I guess that's where security becomes an issue.

Again, as in any programming language or application, some people will want to break it either because of it's value or for the vanity to be the first to succeed at breaking it.  That's unfortunately part of the technological reality.  I don't know that a totally secure system does exist.  And I don't know enough to actually comment on how secure is secure..  I still don't trust on-line banking 😉

R

 

0 Kudos
Message 12 of 13
(1,491 Views)

Ray.R wrote:

At the VI level, we're talking about protecting source code and source libraries that could be sold as part of a service offering or as a set of tools to a client.  It is more likely that those types of clients have little in-house expertise at at using Labview, and would unlikely spend time & efforts to break a password.  If they do, then they have too much time on their hands...

However, those same VI's could end-up into a competitor's hands...  So I guess that's where security becomes an issue.

Again, as in any programming language or application, some people will want to break it either because of it's value or for the vanity to be the first to succeed at breaking it.  That's unfortunately part of the technological reality.  I don't know that a totally secure system does exist.  And I don't know enough to actually comment on how secure is secure..  I still don't trust on-line banking 😉

R

 


The only way to keep your code really secure from others is really to copy it to a disk or something, lock that disk in a safe, bury that safe in a huge pile of concrete and throw away the key into the ocean. And of course destroy any other copy you may have too.

 

So is there anyone so much concerned about his code to go to do that? Smiley Very Happy

 

Password protection of anything is not complete protection at all. And complete protection is very unpractical as everybody can see from above example. So do we have to be concerned?

 

Just for the record I can much more easily get at the gist of an algorithme from a compiled DLL than from a password protected VI. Anyone going to password protect compiled object file formats yet? Some paranoid people (especially virus writers) do! Does it help? Of course not Smiley Very Happy

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
0 Kudos
Message 13 of 13
(1,318 Views)