-1

For (nearly) each action some Android APP performs a query to a php script located on a server for sending/receiving data. For each such query the username/password of the APP's user are transmitted to the script for authorisation purposes.

However, the script uses php's password_hash() function for verification of the user credentials during each and every access. Since password_hash() is slow, this leads to a bad user experience because the APP needs long until the requested data is processed/returned by the script to the APP.

I wonder how to deal with this issue.

One approach I intend to use is that the script sends in addition to username/password also a sessionID. The script in turn runs the password_hash() function only every X minutes and/or every Y requests along with a renewal of the sessionID (in case the user credentials are valid). During the other accesses it is only checked if the sessionID is valid. The sessionID is saved in plain text on the server so this check is fast.

Since the user credentials as well as the sessionID both might be subject to guessing by a third party there seems probably no big difference regarding avoiding not permitted accesses.

The only drawback with the proposed approach I see might be that the sessionID is stored in plain text so that it can be read by a third party (which obtained somehow access to the database). However, this risk might be reduced by adapting the values of X and Y appropriate, hence adapting the period of time the sessionID is valid.

Are there any alternatives to or drawbacks of this approach?

1 Answers1

0

Replacing the username/password with an access token is a very common approach and improves security, because

  1. there is no need to send the password for every request, and
  2. because the token is usually much stronger than user passwords.

This is what an authentication service like OAuth2 does after all.

A session id is similar to an access token, because here also the password is not sent for each request. The session id should be strong engough (e.g. a random sequence of min 20 characters 0..9,1..z,A..Z), then it cannot be guessed and doesn't need a slow password-hash function to be stored.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87