Security and login authentication in Ionic 3 using PHP-generated access token

Question

I’m developing an application where the user can login by providing his email and password. After that, I make a request to my server PHP which checks in the database if the data exist and are correct (if yes, returns a status = true and some more data, if not, returns status = false).

Turns out I want the user not to have to log in every time they open the app, though, what’s the best way to do that?

I know I shouldn’t save the email and password through Ionic Storage (I use only for nonconfidential data, such as: name, surname, photo, etc.). I took a look at the Secure Storage (to store the sensitive data, only), however, it needs the user to have a certain level of security on their device (password on the lock screen) to work, and this is impossible for my app. (not everyone uses passwords on the lock screen)

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

On that front, I thought the following:

Save the user id (I’ll use it in almost every action in my app) and the token on Ionic Storage, then, at the time the authentication is done, check if the token exists for the given id, as this rules out the possibility of some malicious user accessing the app’s storage, simply change the id and pass the user corresponding to the given id, because besides id, it would have to get the token generated for that user.

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

Answer 1

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

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

---

There are some unknowns:

1. How big is the token?
2. How the token is informed to the customer?
3. How will you compare the token?
4. How the token is generated?

---

With the information that was said: anyone who reads the data from the database, who listens to the communication or who has physical access to the client’s device will be able to log in, impersonating him. Anyone can still predict the generated token, measure the time spent for each attempt, and still be able to rescue saved tokens from abandoned disks.

If you believe that all the previous problems are "insignificant", then you have something safe. If not, you have something unsafe.

---

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

1. [APP] Use HTTPS, TLS 1.2, do not traffic information under HTTP.

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

When you log in:

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

2. [APP] Enter e-mail/password and public key (extracted from step 1).

3. [SRV] Check e-mail/password, is not the scope here. If true add the public key as trusted for such email.

When it is "use token":

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

2. [APP] Subscribe to the challenge using Eddsa and inform id user’s.

3. [SRV] It verifies, in constant time, if the signature matches some public key of that user and if it was never used such challenge previously.

Additionally you can encrypt the key by requiring a password or PIN. This would prevent someone with short-term physical access from logging in. In addition it would hinder an offline attack, giving the user the possibility to revoke the key.