What secure practices can I adopt to store a password in desktop applications? [closed]
want to improve this question? update the question to focus on just one problem when edit it .
Closed yesterday .
improve this questionI intend to make an application with PyQt5 to issue notifications based on an API I have. The user, obviously, in a first access would have to use the login and password, to access the applicative. I would like to keep this user authenticated after this "first login", so he doesn't have to put the password every time he opens the app.
The problem is that the last time I had the idea to do it, I was left in doubt about how I should store the user credentials. Since I have no experience with desktop applications, I have no idea how to proceed.
In browsers, it generally uses cookies to be able to obtain information from a session.
But what about desktop applications?
-
Would it be correct to store the user's password in a file, for example, and then retrieve it? For example, if my API does not have a token, how would I always send these credentials to that API, without the user having to intervene with each request?
-
Is there any specific technique in Desktop applications to keep data from a session (even if the application is closed and then open), just like browsers can do with cookies?
-
In the specific case of PyQt( or QT), is there any solution for this type of storage?
1 answers
Interesting your question!
(this suggestion is not for mission-critical or sensitive data applications, banking apps etc-so be careful where you're going to use it ok?!)
EASY SOLUTION:
I'll give you a suggestion: Use a simple layer of encryption, a PIN, purely and simply. This helps too much and does not get in the way of anything and combined with a symmetric key algorithm from the 80s/90s, without being AES.
When creating the user registration, you ask for it create a 4-digit numeric password (a pin) the PIN you save in the user's registration in the bank. The first time you generate the first token and encrypt that token and save.
User (id, email, passwd, pin, token) (a structure similar to this)
Very well, you will not store the pin on the desktop system. Only in the remote bank.
Upon first login, the API will return the encrypted token (if it passes authentication).
Every time the subject enters through the desktop, you will have to enter the pin (the VC pin never stores locally), at that moment vc sends a request to the Authentication API saying: I have this pin and this token, check there hehehe...
The API will decrypt the token using the pin as the key, if hit, Hallelujah ; -)
On the desktop side vc will store the encrypted token: - D only with the encrypted token, stored in a file, has a certain degree of protection.
(oh God, now I saw that your question is 2 years old! But ... since I wrote all, follow the suggestion)
MARKET SOLUTION:
Use certificates, asymmetric key exchanges, properly variable boot vectors with sync functions. Ensure both HTTPS transport in your API as well as AES encryption preferably an algorithm based on elliptic curves. This is a course, you can not answer here, please understand me: it is quite complex, but if this is your case, let's go.
First step: understand how to generate par of keys both on the client side and on the server side.
Public keys are exchanged between user and server i.e.: the public key of the user " goes up "to the Authenticator and the public key of the" authenticator " goes down to the client.
Basically, the client private key never goes up to the server. Never. If this happens compromises the security and never the private key of the server will stop in any client, if this happens, the security and integrity of the authentication server, will be fully compromised.
Yes, we're not there yet. Your system would store a certificate. And authentication would use the certificate and not a password. This certificate would authorize the user. There depending on the case, it could or could not be "selfsigned" but for systems of high degree of security, self-signed certificates without a certifying entity, are not accepted.