securing passwords in deployed executables

[Phil_Blaze]

How can I secure a password to a remote target (ni-9607) in a user interface application? The scenario is, I am going to deploy an RT system to a customer, and I don't want them to have access to the drive. I intend to password protect the drive, and provice a laptop executable program to transfer datalog files from the target to the laptop. I'd like to secure it from casual intrusion. The easiest thing to do would be to embed the targets user name and password as strings. 

I've done some google searches on executable string extraction tools, but I'd rather not explore random 'wares sights form my workstation. I'm tempted to just offset the ASCII codes in some constant or patterened way and just call it a day. 

Thoughts? Suggestions? I don't need to become an internet security expert, just a way that works to prevent casual snooping.

Phil

[James.M]

I think just having the strings in the executable would be fine if you're just trying to avoid casual snooping.

An option could be to encrypt those strings with another string (key) ahead of time and then use that key to decrypt them when needed. I've used the blowfish algorithm in my code before to encrypt/decrypt datafiles and it's really good at turning a string in to gibberish.

Here's what I mean:

[kingehp]

Crypto-G toolkit might be what you need!

Look at this thread.

Also, here's a simple "weak" way suggested by NI.

Hope it helps!!

[Sam_Sharp]

---

@James.M wrote:

I think just having the strings in the executable would be fine if you're just trying to avoid casual snooping.

An option could be to encrypt those strings with another string (key) ahead of time and then use that key to decrypt them when needed. I've used the blowfish algorithm in my code before to encrypt/decrypt datafiles and it's really good at turning a string in to gibberish.

---

If you want to be really secure, you should always use a one-way encryption algorithm so that the original password is never recoverable from the encrypted version - I'd imagine it wouldn't take too much work to find the 'key' string from a LabVIEW executable!

Of course, then you also need to talk about applying a salt to the password so that even if you have the encryption key, you still need another field to correctly compare the passwords and stops you being able to just look up the result of the encryption algorithm from a lookup table.

There's actually a pretty good article about it over on the PHP website: http://php.net/manual/en/faq.passwords.php

(Of course, what I'm talking about is pretty overkill...but I find it an interesting subject...especially given how many large sites/companies get 'hacked' these days)

[James.M]

---

@Sam_Sharp wrote:

If you want to be really secure, you should always use a one-way encryption algorithm so that the original password is never recoverable from the encrypted version - I'd imagine it wouldn't take too much work to find the 'key' string from a LabVIEW executable!

---

Right, so someone could potentially find the gibberish Encipher'd Password, find the Key, and combine them to decipher the password. This only keeps the user from finding the exact password in plain text sitting in the executable.

[Sam_Sharp]

---

@James.M wrote:

Right, so someone could potentially find the gibberish Encipher'd Password, find the Key, and combine them to decipher the password. This only keeps the user from finding the exact password in plain text sitting in the executable.

---

Exactly. If it's a one-way encryption then it's impossible to use the key to try to 'decipher' the password directly. This still allows you to brute-force the password - you can easily create/use a lookup table for common passwords/dictionary words (e.g. 'password', 'god' etc.) and then compare that to your one-way encrypted password. That's where the salt comes in - by adding and storing a random salt before generating the password, you can no longer 'look up' the plain password as you'd need to know the salt as well - basically rendering the lookup tables useless.