hide password from an hardcoded script

[pho01]

To request a high security service response, I need to hardcode my account password in the script itself. This creates a big security hole. Is there anyway to not display the password in the script or other methods to hide it?

the script is on a location that can be viewable by other people in the lab. This is not good in term of my own account login/pwd.

Thanks!

 

[PaulTEG]

pho01,
First off why are you running an unattended high security app?

The fact that the source code is visible is a massive hole.
Is the account an admin account? Can a seperate account with read-only privs be set up, and used only in the script?
Is the information its retreiving sensitive?

Have you root access to the server/machine?
Can you prompt for the username password at runtime?
What's the scope of the application?

Hope something helps

Paul

It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...

 

[pho01]

We (I and other team members) maintain several NT global groups to access sensitive data. we try to create readonly method for people to see who under what group for troubleshooting.

we need to put the code at the location so other team members can edit it as well. But others in the lab who are not our team members can access the folder. To maintain the single focal point of the service, there should be minimum people who would know what the nt services login/pwd for the application (not necessary all team members). That's the point. a seperate account is used for this purpose, but we don't want to share that info to other people due to security risk...

how do I encrypt the password so that only machine would understand it. (acts like .htaccess and .htpassword file)? or any other methods?

 

[fishiface]

Please don't think that the encryption used in .htaccess or .htpassword would delay a curious hacker for more than a few minutes.

http://www.password-crackers.com/pwdcrackfaq.html

enlightens.

Yours,


fish

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
--Maurice Wilk

 

[Haunter]

This may or may not solve you problem. But can you write a simple web service or low level socket interface to do authintication. This would eliminate holding the user/pass local or in the script. It would be a bit more work but is very do able with soap::lite.

Interesting question? I would also ask. Maybe a scripting language is not really suitable in this instance due to code visibility.


haunter@battlestrata.com

 

[PaulTEG]

Good point Haunter. Look at Perl2exe, and build up your password from a few variables in the code so it doesn't appear as a single string - use reverse, and some decryption.

Again if someone really wants to, and they know the password is in there they can get it, but make life as difficult as possible.

Your overhead here is rebuilding the exe from "secured" sources each time the password changes - please tell me the passsword changes

HTH
Paul

It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...

 

[fishiface]

You also need to check whether the password is crossing your LAN in clear text or not. If it is, the rest is a bit redundant. I think Haunter's suggestion is the only one you could call "high security".

Yours,


fish



"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."
--Maurice Wilk

 

[PaulTEG]

What would stop other scripts being "authenticated" by this service if the source is in the 'public' domain?

There's no "High Security" solution to this problem if the scenario remains the same as stated.

My advice would be to rethink the problem in terms of security, as opposed to trying to retrofit a pseudo-secure solution inot your existing infrastructure

my €0.02
Paul

It's important in life to always strike a happy medium, so if you see someone with a crystal ball, and a smile on their face ...