На ваш первый вопрос:
Вы описываете Двухэтапную аутентификацию (иначе Двухэтапную верификацию ), о которой вы можете прочитать встраница Википедии: Многофакторная аутентификация (MFA) :
метод подтверждения заявленной личности пользователя с помощью чего-то, что он знает (пароль), и второго фактора, отличного от чего-либоу них есть или что-то, что они есть.Примером второго шага является то, что пользователь повторяет что-то, что ему было отправлено с помощью внешнего механизма.
Вы правы в том, что номер телефона может изменить владельцев (как и электронная почта).адрес хотя в течение более длительного периода времени в среднем).Вы используете их телефонный номер в качестве механизма внеполосной передачи, описанного выше.
Если пользователь недавно прошел проверку подлинности с помощью своего пароля, когда вы отправляете ему внеполосный код, и он вводит зановочто в поле ввода у вас есть определенная степень уверенности в том, что конечный пользователь знает и пароль, и имеет доступ к SMS-сообщению, и решает доверять этой ассоциации.
Вам нужно будет подумать, если и какдолго, вы можете доверять этой ассоциации в контексте безопасности варианта использования.
Например, добавление двухэтапной проверки при обнаружении того, что конечный пользователь только что прошел аутентификацию на устройстве, которое вы никогда не видели, является хорошей дополнительной защитой.Однако использование внеполосной SMS-проверки при восстановлении учетной записи может открыть большую дыру в безопасности.Вы не хотите обойти аутентификацию с чем-то, что они знают (пароль) в потоке сброса пароля, просто имея доступ к этому номеру SMS.SMS также не является подходящим механизмом для одноразовых паролей (OTP).
Если вы хотите предложить пользователям больше средств защиты своих учетных записей, изучите возможность реализации настоящего MFA с программными токенами (например, Google).Аутентификатор , Authy и т. Д.) И жесткие токены (например, FIDO U2F устройства, такие как Yubikey , Google Titan ,так далее.).
На Ваш второй вопрос:
Вы правы, ограничение на основе IP недостаточно.С помощью служб SMS вы, скорее всего, будете выполнять API-вызов на стороне сервера для поставщика SMS.Сначала проверьте, какие функции безопасности есть у вашего провайдера.Затем защитите вашу конечную точку, которая инициирует вызовы API для поставщика SMS.
Ограничение скорости количества сообщений SMS для любого данного получателя (например, нетболее X SMS-сообщений на один номер в одном окне Y-минут)
Ограничение скорости количества SMS-сообщений, которые один человек может отправлять на разные номера (например, не более X разных телефонных номеров)на пользователя в день).
Не разрешать неаутентифицированные запросы.Пользователь должен уже выполнить первый шаг аутентификации (что-то, что он знает, например, имя пользователя / пароль) перед выполнением шага внеполосного SMS.
Защита формы SMS от Межсайтовая подделка запросов (CSFR) .Ваш сервер должен выполнять вызов API только для поставщика SMS, если он знает, что запрос поступил от вашего интерфейса, а не от другого хоста.
Защитите форму SMS от атак ботов.Существует множество подходов, в которых Google ReCaptcha является одним из наиболее распространенных.