What safe practices can I use to store a password in desktop applications?

Asked

Viewed 81 times

3

I plan 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 application. I would like to keep this user authenticated after this "first access", so he doesn’t need to put the password every time he opens the application.

The problem is, the last time I had the idea to do it, I was in doubt about how I should store the user credentials. As I have no experience with desktop applications, I have no idea how to proceed.

In browsers, you usually use cookies to obtain session information.

But in the case of desktop apps?

  • 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, as I would always send these credentials to this API, without the user having to intervene at each request?

  • There is some specific technique in desktop applications to maintain session data (even if the application is closed and then opened), 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

    Is there any restriction on you not using the token idea similar to what it would be with the web application? The difference in this case is that you would save the token in the desktop application instead of in the browser.

  • 2

    For me the question is broad, but part of a possible answer is in this item: "For example, if my API does not have a token, as I would always send these credentials to this API, without the user having to intervene at each request?" - Simply put the token in the API :) However, you would not send the password open, so another exit would be to hash and save only it. But every exit along this path leads to the ability to copy credentials. The good thing is that each client application saves a token and a separate nonce

1 answer

0

Interesting your question!

(This suggestion is not for mission-critical or sensitive data applications, banking apps etc - so be careful where you use this ok?!)

EASY SOLUTION:

I’ll give you a hint: use a simple layer of encryption, a PIN, purely and simply. This helps and does not interfere in anything and combined with a symmetric key algorithm of the years 80/90, without being AES.

When creating the user’s registration, you ask them to 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 CIPHER that token and guard.

User (id, email, passwd, pin, token) (a structure similar to this)

Very well, you will not store the pin in the desktop system. Only in the remote bank.

When you first log in, the API will return the encrypted token (if you pass authentication).

Every time the subject enters through the desktop, will have to enter the pin (the pin vc never stores locally), at that time vc sends a request to the authentication API saying: I have this pin and this token, check there hehehehe...

The API will decrypt the token using the pin as key, if hitting, hallelujah ;-)

On the desktop side you will store the encrypted token :-D only with the encrypted token, stored in a file, has some degree of protection.

(oh God, now I saw that your question is 2 years old! But ... since I wrote everything, follow the suggestion)

MARKET SOLUTION:

Use certificates, asymmetric key exchanges, correctly variable initialization vectors with synchronization functions. Ensure both HTTPS transport in your API as well as preferred AES encryption of an elliptic curve-based algorithm. This is a course, 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 pair of keys on both the client and server side.

Public keys are exchanged between user and server: the user’s public key "goes up" to the authenticator and the public key of the "authenticator" goes down to the client.

Basically, the client’s private key NEVER goes up on the server. Never. If this happens it compromises the security and never the server’s PRIVATE key will stop on any client, if this happens, the security and integrity of the authentication server, will be totally compromised.

Still, we didn’t get there. Your system would store a CERTIFICATE. And the authentication would use the CERTIFICATE and not a password. This certificate would authorize the user. There depending on the case, could or not be "selfsigned" but for systems of high security, self-signed certificates without a certification entity, are not accepted.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.