Greetings everyone, title might sum it up a bit but let me elaborate. I am currently working on an application that will both have user levels already defined, and will need new users with different privileges to be added to it later in the future. Thus, passwords cannot be hard-coded entirely, but instead will need a user/password database. Easy job for a .ini or .xml, but I don't want those with a basic understanding in computers to just look up the passwords database and read them all, so of course some basic encryption is needed, so all they see is unreadable gibberish.
This at first sounded like something LabVIEW should easily do with some "off the shelf" pack or addon, but so far search has proven unsatisfactory. I did try the blowfish VIs found here: http://www.ni.com/example/28473/en/
But the VIs were not exactly easy to use or understand, and I wouldn't feel comfortable adding such a thing to the code, so is there a more readily available solution? Something that can be more easily digested and more user friendly, text-in text-out style, it doesn't need to be FBI-proof or anything like that, just something that can't be cracked by someone with notepad++
Solved! Go to Solution.
Have you looked in the LabVIEW Tools Network (using VIPM, which you probably installed when you installed LabVIEW)?
I have, with so far unsatisfactory results. I found most of the solutions to be FPGA oriented (which I am not interested in at the moment), and the few that I found were a free to try, pay to implement one (Encryption Compendium for LabVIEW), that also causes a ton of dll errors, and another one (i3 External Encryption) that offers encryption capabilities but no decryption, hence useless to pretty much any purposes (what use a lock you don't have a key for).
I am taking a look at the encryption VIs found in LAVA, but it's proving way more difficult than I think it should, having a ton of difficulties for something I would think, should be rather simple, as I am getting all sorts of invalid parameters errors. At this rate I think I might actually have to build a simple obfuscation algorythm from scratch, and use that, since I'm delving into rather unexplored territory (MD5 and the such) that, while interesting, is not the main focus of my development.
Will keep looking, but don't think finding a "off the shelf" solution will be as easy as I initially thought.
There's a package called AES256 by VIgods which i use. Text + key in, text out..
It's available thru the VIPM.
The VIPM was a horrible experience, but once you go through that, the tool itself is trivially easy.
You sir, have saved me from a ton of extra work, and shed some light for future releases! I found it under the name "AES Crypto" in the VIPM and it is fairly easy to use with a few tweaks anyone with a basic understanding can do. As you said, the VIs are fairly simple to use, this is exactly what I was looking for! A simple, elegant solution that doesn't require Anonymous level of knowledge in encryption to work.
I did try the blowfish VIs found here: http://www.ni.com/example/28473/en/
But the VIs were not exactly easy to use or understand
Well, there is exactly one main VI in the LLB file and it has inputs for text, password and an encipher/decipher switch. What exactly don't you understand for this VI? Why is it "not easy" to use?
I admit this example VI is rather old and the block diagram doesn't follow the style guide, but "hard to understand" with all the comments in the BD?
You might remove the ZLIB compression part to avoid adding an additional DLL to your code - but that only requires to remove 2 subVIs from MainVI…
The NI DSC (Data Supervisory Control)Toolkit has user privileges functionality. You can easily do things like prompt the user to login, and then have buttons enabled or disabled based on who is logged in. Passwords and users aren't stored by your software.
But the easiest solution in my mind is to use the user privileges already built into Windows. Just query the user logged in and what groups they are a part of. I've set this up before and other customers sometimes like that their IT can manage what users are in the groups, and what users will get access to certain parts of the software based on who is logged in.
Doing this on your own is asking for trouble. And not just how you store the passwords, but what about minimum password size? Expiring passwords? Number of special characters? Timeout between logins to prevent brute force attacks? What happens if you are compromised are you at fault for data loss and financial loss? In my mind we should never be doing login stuff in LabVIEW. Not that it can't, but it is just so much easier to pay for a toolkit that has been certified and tested, or using the tools built into the OS.
Hooovahh is correct - it is very easy to make calls to the Windows API and check either local or domain accounts for a user / password.
The thread he linked was on LAVA... and while I can't download the VIs it looks like they are doing the exact same calls I use for this. Two simple .net calls and you can check login credentials.
Yeah, the thing is I tried to understand what was I adding to my code, and most of the block diagrams were not exactly easy to understand to me. I also ran into a few "missing dll" errors which oddly, I am not having now that I opened a new VI and added blowfish. It was more on having a hard time understanding what was going on.
As for the windows users, it was proposed, but ultimately declined by the end users of the software, as it will be running somewhat continuously, and they want to be able to switch user quickly without interrupting a test that has to run for 5-10 hours. Expiring passwords, strength, brute force attacks and the such are currently non-concern for the customer, and thus not contemplated in the requirements, they only want a regular, no password protected operator account, and engineering with full priviledges, whith the option to add more along the way as required.
Will definitely look into the windows users option for future developments, but you know what they say, perfection is what your customer wants.
Expiring passwords, strength, brute force attacks and the such are currently non-concern for the customer, and thus not contemplated in the requirements, they only want a regular, no password protected operator account, and engineering with full priviledges, whith the option to add more along the way as required.
They say that now but in 6 months when bad parts are getting passing results, because an operator changed a limit or test parameter they'll question why you didn't do something to better lock them out. Okay maybe that won't happen to you but has happened to me. I do understand the continuous operation requirement and logging out and logging back in makes the Windows option less useful because of that. Really it seems like DSC is you best bet in my opinion, but you certainly can make other solutions work.