[RESOLVED] Alternative to Hardcode Username & Password in built

Hi All,

I am trying to figure out what is the best way to go by puting username and password for domain users in a project.

What my software does is it runs cmd with runas administrator command. (Process.StartInfo.Domain / Username / Password)

Now the problem is password for domain changes every week so i have to recreate the project with new password. I am trying to figure out an alternative.

Three things come to mind:-

1- Save password in Text file somehow with md5 hash (no clue how to but just an idea)

2- User SQL database and store username and password. (Its kinda off a overkill i think)

3- In my program have an option to compile the project (built) and export the exe file with hardcoded username and password.

i know this is almost like recompiling from vb 2010 studio. But without having to install vb 2010. I have seen this in some remote administration softwares and spywares.(no i am not making virus)

I would like to use the 3rd option since its the best for my requirement.

Has anyone implemented something like this from any of the above options. I would love some pointers.

Thanks.

Mega

:afrog:

I'd say the alternative is to create a safe desktop, and allow input of the new user name and/or password, for encrypted retrieval.
Check out my article, found below in my signature for User Account Control.

Don't trust Vista and Windows 7 to run as different user, because as the article explains/prooves that system window is vulnerable to keyloggers.
How could Microsoft possibly have let that one slide? Oops.

Anways, once you have things running, an invalid or changed password will bring you to the prompt to change the password in a safe place.
That way there is no need to continually hard code it.

I have the UAC built into several of my apps that require frequent admin privileges. It's relatively easy to modify the article sample so that it's built into your app upon start.

Hardcoding is not the best way to implement that. Not only it opens a security hole but it's very inconvenient to both end-users and you.
Normally, if something needs to be done by the domain administrator it can (and should) be done using remote administration tools.
You can have your domain/password in the encrypted form in the .settings file, I suppose, but this is not the best way to do it.
Normally, I'd looked for some alternative ways of running that shell command of yours. What it does that it requires higher access level?

Thank you TTn & cicatrix for your suggestions.

I am going through TTn posts and i agree with cicatrix about the remote administration tools. Problem with remote administration tools is that they cannot do the custom things we require and we require alot and we face weird problems.

For example the reason i required higher access level is to change ip from non admin user when he/she logs on the virtual machine. Now you would say are you crazy why dont you just use DHCP well the answer is simple it doesnt work well in production with 700 vm; we use Thin-Client Sunray 270 with SunRay Server Software - SRSS 5.

A month ago we move to DHCP and we had 100 users coming every day cause DNS was not being updating in time. Yes we did try to fix it in time but didnt work out so we went back to manual ip. Now when the user logs in for the 1st time it checks the computer name and from DB it assigns the ip that computer name has been assigned. Admins dont even have to log in to change it. It runs from normal user with no rights at all (XP SP3) tested and still working. Another thing it does is it adds the user to Remote Desktop Users group since SRSS works on RDP protocol and needs remote desktop access enabled for that user.

:)

I am closing this and marking it as solved. I will probably use db with username and password.