PHP: эффективное использование password_hash - PullRequest
0 голосов
/ 09 июня 2019

Для (почти) каждого действия приложение Android выполняет запрос к php-скрипту, расположенному на сервере, для отправки / получения данных. Для каждого такого запроса имя пользователя / пароль пользователя приложения передаются в сценарий для авторизации.

Однако скрипт использует функцию php password_hash () для проверки учетных данных пользователя при каждом доступе. Так как password_hash () работает медленно, это приводит к плохому взаимодействию с пользователем, потому что APP нужно долго, пока запрошенные данные не будут обработаны / возвращены сценарием в APP.

Интересно, как решить эту проблему.

Один из подходов, которые я собираюсь использовать, заключается в том, что сценарий отправляет в дополнение к имени пользователя / паролю также идентификатор сессии. Сценарий, в свою очередь, запускает функцию password_hash () только каждые X минут и / или каждый запрос Y вместе с обновлением sessionID (в случае, если учетные данные пользователя действительны). Во время других обращений проверяется только допустимость sessionID. Идентификатор сеанса сохраняется на сервере в виде простого текста, поэтому эта проверка выполняется быстро.

Поскольку учетные данные пользователя и идентификатор сеанса могут быть угаданы третьей стороной, вероятно, нет большой разницы в том, чтобы избежать недопустимого доступа.

Единственный недостаток предлагаемого подхода, который я вижу, может заключаться в том, что sessionID хранится в виде простого текста, так что он может быть прочитан третьей стороной (которая каким-то образом получила доступ к базе данных). Однако этот риск можно уменьшить, адаптируя соответствующие значения X и Y, следовательно, адаптируя период времени, когда идентификатор сессии действителен.

Есть ли альтернативы или недостатки этого подхода?

1 Ответ

0 голосов
/ 12 июня 2019

Замена имени пользователя / пароля токеном доступа является очень распространенным подходом и повышает безопасность, поскольку

  1. не нужно отправлять пароль для каждого запроса и
  2. потому что токен обычно намного надежнее паролей пользователя.

Это то, что в конце концов делает сервис аутентификации, такой как OAuth2 .

Идентификатор сеанса похож натокен доступа, потому что здесь также пароль не отправляется для каждого запроса.Идентификатор сеанса должен быть достаточно строгим (например, случайная последовательность из не менее 20 символов 0..9,1..z, A..Z), тогда он не может быть угадан и не нуждается в медленной функции хеширования пароля длясохраняется.

...