Encrypting strings for safe password storage

[BowenM]

---

@Hooovahh wrote:

---

---

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.

 I do understand the continuous operation requirement and logging out and logging back in makes the Windows option less useful because of that.

---

I have seen that problem multiple times and had CARs written against it (luckily not vs software I wrote...).  It has even gotten to the point that I have had to write programs that will validate the checksum of critical files a couple times per day to verify nothing is changing.

As for logging out and back in, if you look at my code it does NOT require a user to log out.  It just requires that the user exist on the computer or domain.

[deceased]

If the windows domain controller credentials is no use, it would be best to use a hash function such as SHA256.

You store the hash locally, then when the user enters their password, you compute the hash and compare to the stored hash. If they match it is the correct password.

Best practice is to also salt the hashes https://en.wikipedia.org/wiki/Salt_(cryptography) such that rainbow tables are less useful. It also means that if two idiots used the password "password" their hashes are still different from each other!

This works better than "encrypting" the passwords, since your application would need the key to decrypt the passwords built in.

I have seen labview code for MD5 and SHA1 hashes, though these are less secure than SHA256, in that with sufficient effort it is possible to find hash collisions.

Happy googling.

Deceased

[Daikataro]

Well luckily these are not parts meant for customer, but long-term destructive tests for lab analysis purposes, but I can definitely see why change of parameters would be such a heavy concern. That said, I have worked at a couple places (won't say names) where the set of passwords was identical for every single computer in each assembly line, and pretty much anyone knew them, this was a rather large brand too, so the problem might be a bit more widespread than I thought.

Will get to playing with the encryption when I'm not working at this solution, that's for sure, and if they agree to implement a more robust solution, I will have something ready.