Login security and authentication in Ionic 3 using access token generated by PHP

0

I'm developing an application where the user can login by providing their email and password. After that, I make a request to my server PHP that checks in the database if the data exists and are correct (if yes, returns a status = true and some more data, otherwise, returns status = false ). / p>

It turns out that I want the user not to have to log in every time they open the app, but what is the best way to do this?

I know I should not save the email and password through Ionic Storage (I use only for non-sensitive data, such as: name, surname, photo, etc). I also took a look at Secure Storage (to store sensitive data, only), however, it does require that the user has a certain level of security on your device (lock screen password) to work, and this is not feasible for my app. (not all use passwords on the lock screen)

From my research, I saw that most of the recommendations would be, upon login, the PHP server will generate an access token, store it in the database (linking the token to the user), return it to the app and save it to Ionic Storage , and then, every time the app is opened, send that token through the request and check in the database if it exists and is valid.

Faced with this, I thought of the following:

Save the user id (I'll use it in almost all actions in my app) and the token in Ionic Storage , then, at the time of authentication, verify that the token exists for the given id, because this discards the possibility of some malicious user accessing the app's storage, simply changing the id and passing the user corresponding to the given id, because in addition to the id, it would have to get the token generated for that user.

Is this a secure way to authenticate? If not, how to do it?

    
asked by anonymous 27.11.2017 / 20:31

1 answer

1
  

Is this a secure way to authenticate? If not, how to do it?

Set your goals, otherwise it is impossible to determine what is safe. Raising the height of your house wall does not make it difficult to break into the gate.

There are some unknowns:

  • How big is the token?
  • How is the token informed to the customer?
  • How will the token compare?
  • How is the token generated?
  • With the information that has been said: anyone who reads the data from the database, who hears the communication or who has physical access to the client device will have how to login, if passing through it. Anyone can still predict the generated token, can measure the time taken for each attempt, and can still retrieve saved tokens from abandoned disks.

    If you believe that all of the above problems are "insignificant," then you have something secure. If not, you have something insecure.

    A very simple construction that would reasonably solve all problems would be:

  • Use HTTPS, TLS 1.2, do not traffic information under HTTP.

  • [SRV] Specify in the application what are the trusted public keys (add some reservation keys, of course).

  • When you log in:

  • [APP] Generate an Ed25519 key (or rely on a NIST curve).

  • Enter the email / password and public key (extracted from step 1).

  • [SRV] Check email / password, it is not scope here. If true, add the public key as trusted for this email.

  • When you use the token:

  • [SRV] Create a challenge. Create random 128 bits, evenly and indistinguishable from a truly random result.

  • [APP] Sign the challenge using EdDSA and report the id of the user.

  • [SRV] Checks, at constant time, whether the signature matches any public key of that user and has never been used before.

  • Additionally you can encrypt the key, requiring a password or PIN. This would prevent someone with physical access, with little available time, being able to log in. It would also hinder an offline attack, giving the user the ability to revoke the key.

        
    27.11.2017 / 23:38