I'm about to add some user account and password functionality to my software, so I'm reading about password hashing.

So my understanding is Hashing is a one way function, and it works like this:

  1. User Bob Types in password box: “MyPassword”
  2. Request Sent to server for Bob’s Salt, and hash from database: Hash: 8912ep98as89uasdp Salt: 89asdjklasdo11jdsa
  3. “MyPassword” + Salt is hashed using same function and compared to retrieved hash
  4. If they match access is granted.
  5. The hash is stored in application memory for future comparisons.

Is that accurate? So that above has granted the user the ability to click around the application, but say my application is retrieving data from a server. I want things to be secure, so for each request from the service I pass along the authentication details (stored hash from step 5), and the service checks it against the database hash before returning a set of data.

Isn't knowing the hash kind of just as bad as knowing the password? If you found out the hash, you could use the service for nefarious means because all the password is used for is generating the hash, and the hash is used for all further authentication.

Edit, for clarification, this isn't a web app. It's going to be a WPF application, probably using WCF service to talk to a server.

  • It sounds to me like the client is doing the hashing, do you trust the client? (The answer is usually no - unless it sits on your own servers). If not it shouldn't be hashing. Password should go to the server over a secure connection (https) but unhashed then it's hashed on the server and the server compares the hash with a stored hash. Commented Feb 7, 2016 at 11:11
  • what do you mean by "Request Sent to server"? Do you mean the application server sending a request to the database server, or the client to the application server? Commented Feb 7, 2016 at 11:13
  • @CodesInChaos I'm only working on the UX side of things at the moment, but ultimately there's going to be a server hosting a WCF service. I don't have much experience with WCF though, and I presumed this would be pretty language/technology ambiguous!
    – Joe
    Commented Feb 7, 2016 at 13:01
  • @RichardTingle To send the password, I'd be storing it wouldn't I? Certainly if I needed to validate user requests for data - every time I requested data from the server I'd be sending a plaintext password. That can't be a good idea, even if it's sent using https?
    – Joe
    Commented Feb 7, 2016 at 13:03
  • @joe a token can be issued and stored (see OAUTH 2.0). This token can provide time limited access before reauthentication is required. You're right that a password shouldn't be stored unhashed at rest if you can at all avoid it Commented Feb 7, 2016 at 16:11

1 Answer 1


Use a session cookie. Use an existing and proven design for session authentication. You will likely find the Information Security stack exchange helpful.

One of the key lessons of computer security is that when you invent it yourself, you're building in security holes. Improved treatment of this problem is one of the key things that differentiates Bruce Schneier's book Cryptography Engineering from the book it replaces, Practical Cryptography.

Further reading:

  1. https://www.sans.org/reading-room/whitepapers/webservers/authentication-session-management-web-1545
  2. https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

This question also partially duplicates Authentication, Authorization and Session Management in Traditional Web Apps and APIs over on stackoverflow.

  • 1
    Thanks, there's clearly more to this than i originally thought. I'll have a look at how cookies work with WPF client apps. Thank you for those resources.
    – Joe
    Commented Feb 7, 2016 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.