c# - Dangerous to store a well hashed password and the method used to hash it in plain sight? -

i developing client-side application in c# communicate server (php page) credentials , critical services. wondering if it's dangerous store hashed password on client's machine? "well hashed", mean random seed using well-known secure hashing function. purposes of discussion, assume source freely available (as binaries can reverse engineered).

my thought store username , hashed password on user's computer , username , hash sent in plain text on unencrypted http connection server validation. of course not prevent hacker using else's username , password hash own without knowing source password (with code tweaks).

1. would malevolent individual able hashed password , code used produce hash? (other log in other user if obtained information)
2. what other client-side applications prevent 1 user logging in other user, if hacker not have access source password? (for example steam)
3. is there easy, cheap (both cost , time), more secure way handle this?

example of how hacker spoof else's login credentials using current logic:

1. legit user signs in first time, credentials stored
2. hacker gains access file system, locates username , hashed password
3. hacker modifies source code (or uses code injection) send acquired username , hashed password instead of program do

the product producing not going next ebay, facebook, or stackexchange, , low budget. not need top notch, , don't care thefts planing use "pay want" model. posting curiosity's sake.

first off, let me not competent implement system securely. i'm not either. almost no 1 is. you need security professional work; if try roll own security wrong , produce system can compromised attackers.

that out of way: have identified weakness of system. storing password equivalent; if attacker obtains password equivalent not matter whether have password or not; have information sufficient impersonate user.

the solution clear. if hurts when that, don't that. not store password equivalent if system stores cannot trusted robust against attack.

if hell bent on storing password equivalent store in storage more difficult attackers obtain access file system. if determined store dangerous stuff on behalf of user can use windows data protection api store in encrypted storage encrypted user's credentials:

http://msdn.microsoft.com/en-us/library/ms995355.aspx

but better not store password equivalent in first place.

suppose not store password equivalent. not done yet. still need consider replay attacks. suppose attacker eavesdrops upon unsecured channel. user types in password, hashed , sent server. eavesdropper records hashed password, , have it.

to solve this, server sends random number client. number never used again; one-time-only. client xors hashed password random number , encrypts result public key of server. encrypted xor'd message sent server.

the server decrypts hash using private key, xors random number sent previously, , determines decrypted hash matches password equivalent storing. eavesdropper cannot replay captured password equivalent because never see same random number again.

now, vulnerable man-in-the-middle attack if client not know public key of server! if server sends public key client man-in-the-middle can intercept server's public key , replace his public key. man-in-the-middle can provide public key and "random" challenge, , client give password equivalent.

like said, hard stuff. don't try yourself. get professional.