LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Daily password generation/expiration

Solved!
Go to solution

What I'm looking to do is lock a feature of a program with a password that is only good for 24 hrs.  The user has to call in and request a new password that I am able to provide without having any contact with the user's computer.  I was thinking of some sort of password generator that runs on my computer and the user's computer that works off the current date and a computer id to make passwords for each user unique.  Do you know of any code or suggestions that would work as a jumping off point?

0 Kudos
Message 1 of 9
(5,387 Views)

From your description I don't see why anything would have to run on the users computer.

 

Create a spreadsheet string and store it into a file. The first coluimn contains a string password, the second column a timestamp for the expiration, a third column containing the user it was assigned to, and a fourth for the computer it was assigned to.

 

You would have a login vi that would take the username, computer name and password as input and it would check the timestamp to see if it is expired and verify the password. You might even have another column for number of failed logins so you can mark the password as expired.

=====================
LabVIEW 2012


0 Kudos
Message 2 of 9
(5,374 Views)

The problem is that I have no contact with the user's computer other than the person on the phone.  I'm mainly trying to come up with a hash program that is based off the user's date and computer ID so that I can provide the answer that unlocks the feature.  Thanks for the help and hope this clarifies my problem.

0 Kudos
Message 3 of 9
(5,364 Views)

Are you saying you need to verify they are who they say they are and/or that the computer is the computer it claims to be? That is different. I thought you just wanted to answer the phone and give a password to them verbally. They enter this password which is sent over the network along with the user name and computer name and you verify it on your end.

=====================
LabVIEW 2012


0 Kudos
Message 4 of 9
(5,359 Views)

Like this

verify.png

=====================
LabVIEW 2012


Message 5 of 9
(5,356 Views)
Solution
Accepted by topic author esd proof

Will something like this work for you?  It's an example of security by obscurity, but you can mix it up a bit to decrease the likelihood of someone guessing your algorithm.

 

password.png capture.png

 

The MD5 Digest vi is OpenG, here.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Message 6 of 9
(5,327 Views)

Thanks for both your time and input.  I think jcarmody is understanding more of what I need to accomplish.  There is no network acess to the remote user's computer so his and my computer have to generate the same accepted password, only I have the solution.  Thanks again, now it's time to fiddle around 'til I can get it perfect.

0 Kudos
Message 7 of 9
(5,308 Views)

Ok I think I understand. You want functionality very similar to a time limited evaluation license. For some reason I read "no access" to mean that you have no way to connect to their computer and not as "the computers have no network access".

 

Are these computers not on the network at all? Is high security a requirement?

 

The reason that I ask the second question is because the solution is easily defeated by the user adjusting their system clock. The solution I posted checks using your system clock.

 

If you need tight security this is a question that you might want to bring up on a security forum somewhere since the problem is not specific to any particular programming language.

=====================
LabVIEW 2012


0 Kudos
Message 8 of 9
(5,296 Views)

It isn't a high security issue.  We previously just had a backdoor overiding password that everyone ended up using to get into the software which, of course, made it pointless.  Its going to be running in a public environment (but out of reach of 99% of people) and accessed only a couple times a month by an authorized individual so the issue of changing the date to use an old password  for simplictiy shouldn't really be an issue. There just needs to be a better perceived level of security on the software.

0 Kudos
Message 9 of 9
(5,288 Views)