История изменений
Исправление 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 запросов со случайными кодами либо на случайные номера, либо на один конкретный. В первом случае ваш сервис будет рандомно выдавать юзерам ошибку при регистрации, когда им не повезёт с номером телефона. Во втором случае можно поднасрать конкретному юзеру.
-
На ввод кода есть неограниченно много попыток. Код можно отбрутфорсить, задача защиты не выполняется.