Windows credential manager

[Albert_]

Hi there!

Getting to the point, I'm developing an OAuth-based application. The user must indicate an email and a password to log in the application and start it. What I would like to do is to give to the user the possibility to store its credentials in order to don't log in everytime the app is started. My intention is to store the credentials in the Cridentials Manager of Windows, as other applications do, in order to provide certain security level.

How can I achieve this in LabVIEW? I have searched .net methods or dlls and I'm not able to find how to do it.

Thank you very much for your time and help.

[rolfk · Accepted solution]

You want to access CredWriteA() and CredReadA() in Advapi32.dll.

[Albert_]

First of all, thank you for your quick response and time.

I found these functions and I called from the VI, but I don't know how to use it (configuration of the parameters and return and what to provide to the functions). I don't catch the documentation of the function. Also, I have downloaded the SDK of Windows 10 in order to use the 'wincred.h' with the dll import wizard (unsuccesfully).

It would be too much to ask for more info or an VI example?

Again, thank you very much.

[rolfk]

This API uses a single structures with embedded pointers. That’s not something the Call Library Wizard can handle as there are to many unclear things that can not be safely determined from the header file alone. It is even so that creating this interface directly on LabVIEW diagram requires more C programming knowledge than writing a wrapper DLL in C which translates between a LabVIEW friendly interface and this API!

I don’t have.currently any such code in either flavor available and therefore can’t give you a quick example.

[rolfk · Accepted solution]

I've been doing some work and started of trying to do it all in a LabVIEW diagram but quickly run into trouble that were pretty hard to debug. So I then started up Visual C and did this little library that I attached. It took less time to do it this way and has more functionality than the VI only variant which did no enumeration of the available credentials. And yes it has no documentation, sorry, you'll have to read the according MSDN pages about the CredRead and CredWrite functions to get the nitty gritty details of how it works.

For passwords for your own purpose you want to use the Generic type. Domain Passwords are treated speciall for the Windows Domain management.

It is a VI library that contains 4 methods.

- Enumerate returns a list of all currently available credentials.

- Read will return the values for a particular credential entry given its Target Name and Type.

- Write will add a new credential entry. You can't modify an existing entry in this way. If you want to do that you first have to delete it.

- Delete will remove a specific credential entry given its Target Name and Type.

The LabVIEW VIs are in version 2009 and there is a 32-bit and 64-bit version of the DLL prebuild. The C source code is in a subdirectory inside the archive.

[Albert_]

Wow! Simply amazing! Thank you very much for your help and time.

[IlluminatedG]

Heya Rolf, I'm using this now, thanks for it!

Do you mind if I package this up and post it to VIPM? Pairing it up with G-Unicode for UTF conversions is proving nice for my tooling use-case.

[rolfk]

Let me look at it. I might add a few more things to it and release it on VIPM. Give me until after the holidays. Also I want to review a few things, there might be a few optimizations and maybe, just maybe, it can be done without DLL, although the VIs doing that won't be for the fainthearted to look at. 😁

But I recently did a few libraries where I was really going into playing C compiler to a pretty deep level, trying to avoid a shared library. Granted that was not for Windows only features but for interfaces to some platform independent APIs, and there things start to get nasty if you need shared libraries but want to support more than just Windows. Yet for some APIs it is simply not a viable option, as it is very hairy to try to do it all in LabVIEW.

[IlluminatedG]

That just sounds like unnecessary work, LabVIEW aware bridge library seems like the way to go for those calls. If people can't handle the C they definitely shouldn't be poking at those VIs. Have you used Ryan's Memory Manager libraries at all? https://github.com/ni/labview-memory-management-tools

[rolfk]

I have my own set of such a library. So no I haven't looked at that, but I might. It's not just memory management though. That's just one part of the story.

The nasty part of doing it on the LabVIEW diagram mainly starts when dealing with structures that contain non scalar data. This really quickly starts to end in a total mess if you want to support different platforms and 32-bit and 64-bit. Having Conditional Compile structures all over the place is very hard to avoid in those cases. 

I see why I haven't noticed this before. It's hidden on the NI github page, if it would be in the downloadable VI packages from VIPM I might have noticed it earlier.