I was reading a thread on here recently which reminded me of a conundrum.

Basically, how to store an actual password within a client application securely.

* I do NOT mean storing as a hash to be checked against!



How do password managers do it? Is that concept available across platforms (for me Linux, OSX, Windows, Android, ...)


Obviously I'm assuming the host system has been compromised (even if just parents or evil friend playing prank, etc)

Was it perhaps this thread?

I posted this because I was working on a personal project and wanted to know how it was done. Hash was suggested, but you can look at the KeePass/Thunderbird source code.

Pass the salt.

It was that thread, and I did start looking into KeePass, but didn't dl the source / binary.

The wiki states this:
https://en.wikipedia.org/wiki/KeePass#Offline_security


So, in the original versions it either requires a password or keyfile, but they must be stored somewhere. (Same as Habitual's salt concept)

* TBH I'm not too interested into making this a service. So the startup and decrypting being linked to OS login isn't the way I'm looking, even though I'd be interested in knowing more about that mechanism.)


For a networked application I considered that when the password is initially entered it is sent to the server which returns a one-time code, and every time the user starts up a new code / token is issued. So if the code is stolen, when used twice would log out all parties forcing the original password to be re-entered. However, this does tie each user to a single device (and I am interested for games on one project which I'd like to be able to use multi devices, e.g. phone at work and tablet at home.)

Generally speaking, you don't want to store any kind of password. For that matter, you really don't want to use passwords for authentication, "period." Especially when an application is talking to a remote server.

The strategy that you should be using is: digital certificates, embedded as a simple resource within the application, and encrypted such that the application can decode it. The certificate, if possible, should be unique. If not, it should be easily field-replaceable. Existing crypto technologies such as Kerberos can provide the necessary infrastructure.

Once setup here's how I see Kerberos works (overly simplified, msg details ignored, timestamps, etc):

1. User uses own password to encrypt a msg to the KeyServer requesting authentication
2. The KeyServer generates a session key and secret, it then encrypts it with the users password and sends back to the user
3. The user decrypts the msg storing the session key and secret.

4. The User requests a Service Ticket by encrypting the request and secret with the session key.
5. The KeyServer replies with a new service session key and generates another msg for the Server containing the service session key, encrypting it with the Servers password
6. The User sends the msg for the Server to the Server.
7. The Server uses its own key to decrypt the msg from the KeyServer via the User
* The User and Server now share a service session key


* It appears that the User password is unlocked when the User logs onto their physical machine, it is then stored in volitile ram

So, it comes back to using the operating systems login and associated services to store the keys.


I'm not really considering the key exchange protocol here, moreover how to store a password or key locally in a secure fashion, without having to rely on the underlying systems' login




Yes, but how to store it securely independent of system login?