наркомания это норма?

На все вопросы - да -это наркомания.

Oauth2 = это только про делигирование прав доступа приложению от лица пользователя.

Логин и регистрация - это задача Identity Provider’a, что в свою очередь чать протокола OpenID Connect (OIDC), который, в свою очередь, надстройка над OAUT2.

Всё остальное -это наркомания от неспособности/нежелания/лени реализовать протокол полностью.

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

В зависимости от того, что за hash, возможно, вариант защиты от брутфорса пинкода. Может, автор хотел, чтобы продолжить процесс регистрации мог только пользователь запросивший код, а не его оператор связи (если sms - лишь один из факторов, это логично).

В зависимости от деталей реализации, возможно, защита от user enumeration (сбора номеров зарегистрированных пользователей).

вариант защиты от брутфорса пинкода

брутфорс пинкода заканчивается на первом же запросе: если пинкод верный - подтверждаем телефон если пинкод не верный - затираем отосланный пинкод не давая возможности попробовать подобрать ещё (это то как должно работать без всяких hash)

передача по https

что насиловать сервер затираниями, повторными посылками, ПОДУМОЙ.

повторными посылками занимается атакующий, можно исключить и затирание задавая время жизни пинкода и прекращая сравнение после этого времени

говоря про затирание я имею ввиду затирание внутри OAUTH2 сервера, точнее мутанта кроме OAUTH2 реализующего еще и регистрацию

можно исключить и затирание задавая время жизни пинкода и прекращая сравнение после этого времени

Времени должно быть достаточно, чтобы легитимный пользователь успел воспользоваться. SMS приходит не мнгновенно, могут быть серъёзные задержки (5-15 минут). За это время можно подобрать 4 цифры точно. Решается с помощью rate limit, но к чему привязывать? Если к IP, будут долбить с нескольких. Если к номеру - организуют DoS (это к вопросу о «затирании» тоже). Остаётся спец. hash номера.

ну соответственно время это должно быть меньше чем возможный брутфорс, а еще лучше как я писал выше все же затирать на сервере pincode после первого же обращения (на корню пресекая брутфорс). вообщем наркомания этот hash в чистом виде.

а еще лучше как я писал выше все же затирать на сервере pincode после первого же обращения

Если хочешь DoS своего сервиса, можно и так. А атакующий сделает скрипт, который будет долбить произвольные номера с неправильными кодами, делая невозможным вход/регистрацию для этих номеров.

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

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

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

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

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

Если хочешь DoS своего сервиса, можно и так. А атакующий сделает скрипт, который будет долбить произвольные номера с неправильными кодами, делая невозможным вход/регистрацию для этих номеров.

сам то в это веришь? какова вероятность того что выбранный атакующий номер совпадет с моментом регистрации нормального номера? вычислительную сложность всего этого представляешь?

в случае если ограничиваем количество попыток одной - то действительно в этом случае можно поднасрать конкретному человеку который хочет зарегистрироваться. какова вероятность того что X знает о желании Y зарегистрироваться и долбит сервис чтобы не допустить этого? в реальной жизни таких придурков будет один на миллион, но надо признать найтись такие могут.

поэтому свою идею о блокировке после одной попытки я пожалуй снимаю, спасибо.

пусть блокировка будет после X секунд - это время будет не достаточно для брутфорса, при этом никто не помешает зарегистрироваться легальному пользователю.

теперь вопрос разобравшемуся: нафига hash когда у нас https и вместо hash можно просто передавать phone? и даже если бы не было https все одно можно просто передавать phone и pincode это никак не понижает защиту.

пусть блокировка будет после X секунд

С какого момента? С момента отправки СМС? Плохая идея. Она может идти и пару минут, юзер не успеет ввести код. С момента первого ввода кода? Тогда поднасрать юзеру ничего не мешает, так как мы постоянно долбим запросы с его номером и вызывам протухание кода.

И не обязательно вредить одному юзеру. Пул номеров не бесконечен. Отправить несколько миллионов запросов с разных ip реально. И статистически значимое количество юзеров почувствует неудобства при входе.

В любом случае использование хеша повышает безопасность и никому не мешает. Это же один библиотечный вызов.

Аргументация, когда это может быть полезно есть. Реализация делается за 5 минут. Производительность едва ли пострадает (запись нового юзера в БД займет на порядки больше времени, чем вычисление хеша). Так что… Why not? Или для вас любое решение не подкреплённое 50 страницами обоснований - наркомания?

С какого момента? С момента отправки СМС? Плохая идея. Она может идти и пару минут, юзер не успеет ввести код.

С момента создания кода и отправки sms.

С момента первого ввода кода? Тогда поднасрать юзеру ничего не мешает, так как мы постоянно долбим запросы с его номером и вызывам протухание кода.

Как я уже написал выше я благодаря вам таки отказался от идеи протухать код после первой попытки подбора. Спасибо.

В любом случае использование хеша повышает безопасность и никому не мешает. Это же один библиотечный вызов.

Каким образом это повышает безопасность? Благоволите еще раз посмотреть на кейс в топике.

С момента создания кода и отправки sms.

СМС может идти пару минут. Вам всегда приходят СМС коды в течении 5 секунд и вы успеваете их ввести за это же время?

СМС может идти пару минут. Вам всегда приходят СМС коды в течении 5 секунд и вы успеваете их ввести за это же время?

формально оно и сутками может идти.

бог с ним. объясните мне дураку КАК hash в этом кейсе повышает безопасность?

Можно грохать код при первом же неправильном вводе, на корню зарубив брутфорс. При этом никто не сможет инвалидировать код зная или угадав номер пользователя. Так как хеш идёт по https и мы можем быть уверены, что код ввёл именно тот, кто его запросил.

Можно грохать код при первом же неправильном вводе, на корню зарубив брутфорс. При этом никто не сможет инвалидировать код зная или угадав номер пользователя.

Эту идею я уже отборосил, забудьте.

Так как хеш идёт по https и мы можем быть уверены, что код ввёл именно тот, кто его запросил.

Ну и нафига тут hash я хочу еще раз спросить?

Смотрите положим я знаю ваш телефонный номер, сформировал для вас pincode и отдал Маше. Маша принесла вам pincode. Теперь вы мне отправляете по почте письмо в котором ваш телефонный номер и pincode. Одновременно с этим злой Вася отправляет мне по почте еще 1000 писем с вашим номером и разными пинкодами. Как только я получу письмо с вашим номером и правильным пинкодом я крикну «куку» в окно.

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

Может быть я не прав) Объясните мне. Вы же разобрались!

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

KivApple что-же в этом есть логика, признаю что был не прав и идея с хешом не наркоманская.

Можно грохать код при первом же неправильном вводе, на корню зарубив брутфорс.

чем это отличается от того что я предлагал в начале? не тут другая идея: этот хеш просто так не создать, не угадать, по сути это аналог hmac, так что брутфорсу и правда хана поскольку за приемлемое время не создать этот хеш

собственно как о hmac я о нем сразу и думал, но идею что тут еще отсутствие создания пользователя пропустил. в любом случае спасибо это было полезно!

сам то в это веришь? какова вероятность того что выбранный атакующий номер совпадет с моментом регистрации нормального номера? вычислительную сложность всего этого представляешь?

Нафига ему совпадать с моментом регистрации? Оно будет в цикле долбить 24 на 7. Избранные номера «заблокировать» таким образом сможет даже школьник. Все для опред. региона - сложнее, но всяко проще обычного DDoS, расчитанного на забивание канала.

Нафига ему совпадать с моментом регистрации?

Есть период с момента формирования сервером pincode для sms до получения сервером кода pincode от клиента, вероятность что такая распределенная долбилка (заточенная под все номера) попадет в этот период крайне мала. Однако же если мы охотимся за конкретным номером, а не пытаемся гадить всем потенциальным номерам, то это вполне возможно, поэтому я от этой идеи отказался.

А дальше мне подсказали что DDOS в принципе можно предотвратить с помощью HMAC.

тут что, фестиваль безаватарочных?