LINUX.ORG.RU

История изменений

Исправление KivApple, (текущая версия) :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть ограниченное количество попыток. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам. Второе реализуется не легко, а очень легко, для первого нужны определённые ресурсы, но шансы на успех есть.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Разумеется, можно придумать альтернативы хешу - например, учитывать IP запроса и т. д. Но это сложнее в реализации и имеет больше граничных случаев (IP мобильного юзера может внезапно меняться в самый неподходящий момент из-за переключения между сетями, например, много юзеров сидит за NAT и т. д.). А тут решение лежит на поверхности и на первый взгляд не имеет недостатков (кроме того, что @quester может не разобраться и создать тему на ЛОР с обвинением авторов в употреблении запрещённых веществ, но это такая мелочь).

Исправление KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть ограниченное количество попыток. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам. Второе реализуется не легко, а очень легко, для первого нужны определённые ресурсы, но шансы на успех есть.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Разумеется, можно придумать альтернативы хешу - например, учитывать IP запроса и т. д. Но это сложнее в реализации и имеет больше граничных случаев (IP мобильного юзера может внезапно меняться в самый неподходящий момент из-за переключения между сетями, например). А тут решение лежит на поверхности и на первый взгляд не имеет недостатков (кроме того, что @quester может не разобраться и создать тему на ЛОР с обвинением авторов в употреблении запрещённых веществ, но это такая мелочь).

Исправление KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть ограниченное количество попыток. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам. Второе реализуется не легко, а очень легко, для первого нужны определённые ресурсы, но шансы на успех есть.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Разумеется, можно придумать альтернативы хешу - например, учитывать IP запроса и т. д. Но это сложнее в реализации и имеет больше граничных случаев (IP мобильного юзера может внезапно меняться в самый неподходящий момент из-за переключения между сетями).

Исправление KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть ограниченное количество попыток. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам. Второе реализуется не легко, а очень легко, для первого нужны определённые ресурсы, но шансы на успех есть.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Исправление KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть ограниченное количество попыток. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Исправление KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть только одна попытка. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на некоторое количество конкретных. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретным юзерам.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.

Исходная версия KivApple, :

на кой черт этот кейс с «hash» вместо просто передачи телефона и pincode на третьем шаге? это личные наркотические пристрастия автора или оно так принято в среде laravel/php?

Чтобы быть уверенным, что именно этот юзер запросил ПИН-код на этот номер. Иначе возможны как минимум два кейса:

  • На ввод кода есть только одна попытка. Шлём 100500 запросов со случайными кодами либо на случайные номера, либо на один конкретный. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретному юзеру.

  • На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.