surprise when 2 VIs have the same password

[Antoine Chalons]

Say I have 2 VIs a.vi and b.vi and both are password protected with the exact same password.

Then try that :

- open a.vi

- hit "ctrl + e"

- enter the password

>> you see a.vi's block diagram.

- open b.vi... surprise, it's unlocked and you don't need to enter the password to see the block diagram.

For me it's a bug because if a.vi and b.vi have different passwords it does not happen.

I thinks I should move this to the bug list section, any objection ?

[EDIT]

The only reason why I didn't go straight to bug list section is that I was trying to imagine the nightmare for those NI lads working on some NI password protected code... if they have to enter the password for every single password protected VI

[Grampa_of_Oliva_n_Eden]

QUOTE (Antoine Châlons @ Jan 29 2009, 09:02 AM)

Say I have 2 VIs a.vi and b.vi and both are password protected with the exact same password.

Then try that :

- open a.vi

- hit "ctrl + e"

- enter the password

>> you see a.vi's block diagram.

- open b.vi... surprise, it's unlocked and you don't need to enter the password to see the block diagram.

For me it's a bug because if a.vi and b.vi have different passwords it does not happen.

I thinks I should move this to the bug list section, any objection ?

[EDIT]

The only reason why I didn't go straight to bug list section is that I was trying to imagine the nightmare for those NI lads working on some NI password protected code... if they have to enter the password for every single password protected VI

Bug?

Based on the fact that we have an option undr tools (?) "Clear Password cache" NI did put some thought into keeping the password in a cache. Ibeilive this is what makes it mposible search an entire hiarchy and only have to enter the pasword once for all VI protected by that password.

Just sharing my thoughts,

Ben

[gmart]

QUOTE (neBulus @ Jan 29 2009, 09:24 AM)

Bug?

Based on the fact that we have an option undr tools (?) "Clear Password cache" NI did put some thought into keeping the password in a cache. Ibeilive this is what makes it mposible search an entire hiarchy and only have to enter the pasword once for all VI protected by that password.

Just sharing my thoughts,

Ben

Once a password is entered, it stays cached until you restart LabVIEW or clear the cache.

[Antoine Chalons]

QUOTE (neBulus @ Jan 29 2009, 03:24 PM)

Based on the fact that we have an option under tools (?) "Clear Password cache" NI did put some thought into keeping the password in a cache. Ibeilive this is what makes it impossible search an entire hierarchy and only have to enter the password once for all VI protected by that password.

QUOTE

Once a password is entered, it stays cached until you restart LabVIEW or clear the cache.

Well true... That's what I put in my EDIT, but.. I don't know..

I didn't know about that "clear password cache" option and so I made an utility VI that will recursively get all the VIs in a folder and lock/unlock them with a password ; when I noticed the behaviour I was really surprised and even if now I do understand it makes sense I'm still a bit doubtful...

But ok, feature then. Not bug.

[Yair]

I would say that in the strict sense of "what is a password?" this is a bug. For the purpose of the argument, suppose I open a web browser and log into NI. Does that mean that when I go to LAVA I should be logged in automatically if I use the same name/pass combo? Suppose that someone decided to lock their VI and they just happened to choose the same password I did. That would mean that unlocking my own VIs would unlock theirs as well, even though I would probably not think of trying my password on their VI.

Obviously, most people who really care about protecting their code probably choose a password which would be unlikely to be used by anyone else, so in the real world this is more an ease of use feature which allows you to unlock a group of VIs together.

[gmart]

QUOTE (Yair @ Jan 29 2009, 11:42 AM)

I would say that in the strict sense of "what is a password?" this is a bug. For the purpose of the argument, suppose I open a web browser and log into NI. Does that mean that when I go to LAVA I should be logged in automatically if I use the same name/pass combo? Suppose that someone decided to lock their VI and they just happened to choose the same password I did. That would mean that unlocking my own VIs would unlock theirs as well, even though I would probably not think of trying my password on their VI.

Obviously, most people who really care about protecting their code probably choose a password which would be unlikely to be used by anyone else, so in the real world this is more an ease of use feature which allows you to unlock a group of VIs together.

I see your point, but I think a better analogy is that when you log into your Amazon account and select the web site to remember you, a cookie is placed that lets you log back in again without having to enter your information (including passwords). Obviously, a password entered in another app should not apply to LabVIEW. Within LabVIEW, I am guessing (I do not know for a fact) that the caching is for ease of use. While "better" security might be to ask for passwords at all time, it makes operations such as mass compile or common development actions could become unwieldly. Could two VIs from different developers have the same password? Yes. I think that scenario would be rare though (so don't make your passwords "12345" ).

[Aristos Queue]

I suspect that if LV made you enter your password for every individual VI while you're developing -- say, when you double click on a subVI to open it, and then when you tried to open the next subVI, and the next -- someone would come to NI and shoot whoever made that change. It is DEFINITELY NOT A BUG.

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Jan 29 2009, 07:01 PM)

I suspect that if LV made you enter your password for every individual VI while you're developing -- say, when you double click on a subVI to open it, and then when you tried to open the next subVI, and the next -- someone would come to NI and shoot whoever made that change. It is DEFINITELY NOT A BUG.

While I'm not easily tending to violent actions I sure would scream hell and fire if someone did this change. The hypothetical chance to unlock someone elses VI because it uses the same password as one I know for another VI is no justification to make the password a complete useless feature . Also VIs would then need to remember that they were unlocked as otherwise you would have to reenter the password everytime after closing the diagram. OMG!!!

Rolf Kalbermatter

[Daklu]

One workaround is to leave the source code unprotected and apply a password when you build the code. OpenG Builder has an option that sets a random password at build time.

[vugie]

Can't this "feature" be used to overcome brut force protection for VIs? If someone will find a way to fill the cache with a number of passwords, it can be used to try multiple passwords almost at once without any artificial pause.

[Grampa_of_Oliva_n_Eden]

QUOTE (vugie @ Feb 16 2009, 09:53 AM)

Can't this "feature" be used to overcome brut force protection for VIs? If someone will find a way to fill the cache with a number of passwords, it can be used to try multiple passwords almost at once without any artificial pause.

At about LV 6.0 NI introduced a delay when entering a password programatically to make sure the brute force attack will take a millenium to complete.

Ben

[vugie]

QUOTE (neBulus @ Feb 16 2009, 04:14 PM)

At about LV 6.0 NI introduced a delay when entering a password programatically to make sure the brute force attack will take a millenium to complete.

But is this delay also used when applying passwords from cache?

[Rolf Kalbermatter]

QUOTE (vugie @ Feb 16 2009, 10:24 AM)

But is this delay also used when applying passwords from cache?

No but in order to fill the cache you have to apply a password to a VI through VI server. At around 100ms per execution you will wait a long time to fill that cache significantly. And I believe that if the password does not match it will not be added to the cache! So you need to apply a new password to some VI, clear it and add another one, at about 100ms for each operation

Shutting down LabVIEW destroys that cache too.

Rolf Kalbermatter

[crelf]

QUOTE (rolfk @ Feb 16 2009, 10:39 AM)

No but in order to fill the cache you have to apply a password to a VI through VI server.

Are you sure that's the only way to get passwords into the cache? We're talking about the development environment here, not our code, so maybe there's another way to do it - maybe have LabVIEW load up with a few commonly-used passwords? I have no idea, and, of course, only pose these questions in the hopes of making LabVIEW better.

[Rolf Kalbermatter]

QUOTE (crelf @ Feb 16 2009, 11:48 AM)

Are you sure that's the only way to get passwords into the cache? We're talking about the development environment here, not our code, so maybe there's another way to do it - maybe have LabVIEW load up with a few commonly-used passwords? I have no idea, and, of course, only pose these questions in the hopes of making LabVIEW better.

Well I can't say with absolute authority that there couldn't be some method to initialize the password cache somehow, but I am not aware of any other way to get the password cache filled than by applying a new password to a VI or entering a valid password for an existing VI. Nothing else seems to work and shouldn't either. It does not make sense either so why should NI add such a thing?

Rolf Kalbermatter

[LAVA 1.0 Content]

QUOTE (crelf @ Feb 16 2009, 10:48 AM)

Are you sure that's the only way to get passwords into the cache? We're talking about the development environment here, not our code, so maybe there's another way to do it - maybe have LabVIEW load up with a few commonly-used passwords? I have no idea, and, of course, only pose these questions in the hopes of making LabVIEW better.

You can add multiple passwords to the cache and store them concurrently. You do have to add the passwords one at a time to the cache. In 8.6 this seems to take 10-11 ms per password.

I have a small VI that I use to store all of the passwords that I have and call the VI to add all the passwords to the cache. This VI could be called automatically from the link you use to start the LV environment.

EDIT: It looks like this feature is not fully exposed. I must have received this VI from R&D a long time ago as I have been using it for quite a few years.

[crelf]

QUOTE (rolfk @ Feb 16 2009, 01:47 PM)

Well I can't say with absolute authority that there couldn't be some method to initialize the password cache somehow, but I am not aware of any other way to get the password cache filled than by applying a new password to a VI or entering a valid password for an existing VI.

Oh - Okay. I thought that, from the tone of your message, you were speaking with some authority - my mistake.

QUOTE (rolfk @ Feb 16 2009, 01:47 PM)

It does not make sense either so why should NI add such a thing?

This is why:

QUOTE (LV_FPGA_SE @ Feb 16 2009, 01:48 PM)

I have a small VI that I use to store all of the passwords that I have and call the VI to add all the passwords to the cache. This VI could be called automatically from the link you use to start the

LV

environment.

I'm not saying that access to the password cache should be exposed - I'm just trying to find out if it is.

[vugie]

I found a way to significantly speed up brute force method. There are private methods in application class for dealing with password cache. Password may be verified using Get Lock State method of VI (it returns Pwd in Cache boolean).

For the test case I created simple VI and locked it with "asd" password (to guarantee it will be found fast enough). I assumed (for test case only) that password consists of 3 non capital letters. For naive brute force method (providing password to Open VI Ref) password was found in ~50 sec (~600 checks). When using cache the same password was found in 5 sec.

Of course 120 checks per second is not enough to seriously think about using this method to break VIs passwords. I didn't check yet what is more time consuming: adding to cache or getting lock state.