#php #security
#php #Безопасность
Вопрос:
Я пытаюсь разработать двухфакторную систему аутентификации (на PHP), используя SMS в качестве второго метода аутентификации. Это для тестового проекта, поэтому кто-нибудь может помочь мне разработать этот сервис?
Это будет веб-система, и ниже приведено то, что я сделал до сих пор.
-
Как только клиент введет имя пользователя и пароль, веб-сайт отправит безопасный HTTP-запрос на наш сервер с MSISDN, UID (для идентификации сеанса), их идентификатором пользователя и паролем.
-
Наш сервер добавит запрос в базу данных MySQL и ответит веб-сайту кодом, UID и некоторой другой информацией.
-
Наш сервер отправит клиенту SMS с одноразовым паролем.
-
Как только клиент введет OTP на веб-сайт, веб-сайт отправит другой HTTPS-запрос с зашифрованным OTP на наш сервер, и мы отправим код успеха или сбоя в качестве ответа.
это поток, о котором я думал. У кого-нибудь есть лучший поток? или предложения?
Спасибо.
Комментарии:
1. Звучит интересно, что касается потока аутентификации: если удаление пользователя не вызывает беспокойства или безопасность и / или предотвращение спама вызывает серьезную озабоченность, я бы сказал, что это нормально. Craigslist недавно начал требовать аутентификации с помощью SMS-сообщений и действительного телефонного номера в США.
2. Да, это для местного банка в Шри-Ланке, поэтому я не должен беспокоиться о спамерах, я полагаю 🙂 но да, я всегда могу добавить объект CAPTCHA в форму начальной аутентификации или в форму OTP. Спасибо за мысль, приятель …. 🙂
3. Как я уже сказал в своем ответе, это не двухфакторная аутентификация… Кстати, вы также можете попробовать задать как security.stackexchange.com
Ответ №1:
Это может работать нормально, однако это не двухфакторная аутентификация.
В дополнение к паролю, вторым фактором может быть:
- Что-то, что у вас есть (например, secureid, смарт-карта и т.д.).
- То, чем вы являетесь (т.е. Различные формы биометрии).
Поскольку я предполагаю, что вы не стремитесь к биометрии ;), позвольте мне пояснить, почему я говорю, что это не 2-й фактор (то, что у вас есть).
Чтобы квалифицироваться как 2-й фактор, вам нужно было бы гарантировать, что владелец устройства (т. Е. предварительно зарегистрированный мобильный телефон) является единственным, кто мог бы получить SMS.
В современных сотовых сетях это просто не так. Существуют способы копирования, например, SIM-карты; операторы сотовой связи могут перехватывать; на смартфонах могут быть приложения, которые перехватывают и повторно отправляют; и т.д.
Кроме того, если пользователь вводит код обратно на веб-сайт, это позволяет выполнять все стандартные веб-атаки на этот дополнительный пароль: прослушивание, перехват, MITM, захват сеанса и т.д…
Теперь, чтобы было ясно, это все еще определенно имеет ценность — внеполосная связь может помочь гарантировать, что кажущийся пользователь не становится жертвой простой веб-атаки, XSS и т.д.
Я работал со многими телекоммуникационными компаниями, которым нравится это решение (это также является частью их бизнес-модели, но неважно ;))
Однако, в зависимости от вашей ситуации, в некоторых местах (например, банки, правительство) требуется реальный 2-й фактор — т. Е. криптографическое доказательство (обычно). И это не все.
Комментарии:
1. Hay AviD, спасибо за мысли, но, поскольку я прочитал в сети, что устройство физической безопасности в качестве второго фактора не является удобным для пользователя, кажется, что пользователю нужно носить с собой другое электронное устройство только для входа на портал. Следовательно, клиенты предпочитают, чтобы их мобильный телефон использовался в качестве второго фактора, и это будет тенденцией, по мнению отраслевых экспертов (к которым я не отношусь), так что есть предложения о том, как я могу сделать свою систему (используя SMS) более безопасной? Заранее спасибо, приятель
2. @megazoid, в зависимости от обстоятельств, использование SMS на мобильный телефон в качестве внеполосного средства аутентификации может быть очень хорошим решением (однако, учитывайте экономическую сторону этого, SMS обычно не бесплатны). Но это не второй фактор, даже если он получен с помощью «устройства». Для систем, которые требуют истинной двухфакторной аутентификации, этого недостаточно.
3. Что касается безопасности этой системы, она в основном кажется достаточно хорошей (такой, какая она есть). Конечно, не забудьте SSL, шифрование, безопасные файлы cookie, проверку входных данных и т.д. И т.п… Также смотрите этот вопрос в ITsec
Ответ №2:
Кажется, что механизм действует. Но что, если SMS-устройство не находится в зоне обслуживания? Или разрядилась батарея?
Комментарии:
1. или, что еще хуже, у них нет мобильного телефона.
2. @Ben: в этом случае, я предполагаю, что не было бы зарегистрированного устройства SMS, так что эта часть проверки не была бы предпринята.
3. Правильно …. Все зарегистрированные пользователи должны иметь мобильное устройство или CDMA-устройство с поддержкой SMS. Это основное требование при регистрации. 🙂 Но у wallyk есть действительный аргумент, если устройство не работает или вне зоны действия сети, или, что еще хуже, если SMS не было прервано на устройстве из-за сетевой ошибки. Я должен добавить опцию во второй форме аутентификации для повторной отправки OTP, и это будет другой OTP, чем первый. Поэтому мне также нужно сообщить об этом на веб-сайт.. Спасибо, ребята…
Ответ №3:
Я бы только добавил, что отправка OTP через SMS по-прежнему считается двухфакторной аутентификацией. Комментарий от Avid понятен
во-вторых, вам нужно будет гарантировать, что владелец устройства (т. Е. предварительно зарегистрированный мобильный телефон) является единственным, кто мог получить SMS.
Но то же самое применимо, скажем, к аппаратному токену на основе 2FA. Как можно гарантировать, что аппаратный токен используется только одним человеком? Украсть ключ (или посмотреть OTP на его экране) даже проще, чем перехватывать SMS
@megazoid, рассматривали ли вы возможность использования поставщиков «2FA как услуги»? Такие как Authy.com , Token2.com или DuoSecurity?
Ответ №4:
Всем по-прежнему нравятся SMS, но, на мой взгляд, это отстой. Независимо от того, насколько сильно SMS-пароль пытается улучшить рабочий процесс.
Злоумышленник может запросить SMS и перехватить SMS так, что пользователь этого не заметит. Для этого ему даже не нужно красть телефон. И, на мой взгляд, это худшая атака, поскольку жертва не поймет, что ее скомпрометировали.
При краже ключа пользователь знает, что он был скомпрометирован, и могут быть приняты соответствующие контрмеры.
Кража исходного кода ключа у поставщика — гораздо лучший вектор атаки, что также было показано в прошлом 😉
Вот почему вам следует подумать об использовании аппаратных токенов, которые вы можете заполнить самостоятельно. Таким образом, вы можете быть уверены, что исходное значение принадлежит только вам. Доступными для заполнения токенами являются yubikey, eToken Pass и eToken NG OTP.
В любом случае, для среды с «низким уровнем безопасности» даже использование SMS может быть приемлемым. Но вы должны быть осведомлены о последствиях. Кстати, все подобные токены поддерживаются проектом с открытым исходным кодом privacyIDEA.
Комментарии:
1. Обратите внимание, что NIST отказался от внеполосной аутентификации через SMS!
Ответ №5:
Я приглашаю вас поискать идеи в клиентах, которые мы открыли в Duo, для нашей системы двухфакторной аутентификации:
https://github.com/duosecurity/duo_web
Еще одно место, на которое следует обратить внимание, — это существующие сторонние протоколы аутентификации, такие как OAuth и OpenID.
Две вещи, о которых вы не упомянули:
- Подписанный ответ должен включать идентификатор пользователя для сравнения с локальным пользователем (вероятно, сохраненный в защищенном сеансе), чтобы избежать повторов
- Подписанный ответ должен включать срок действия или возвращать одноразовый номер, указанный в подписанном запросе
Комментарии:
1. Привет, Карл, 1. OTP будет уничтожен по истечении заданного периода времени, поэтому пользователю необходимо использовать OTP в течение этого периода времени (например, 1 минута), в противном случае ему придется запросить новый OTP. Ответит ли это на два ваших предложения?
2. Если я вас правильно понимаю, ответ от сервера, который указывает, прошел ли данный OTP или произошел сбой, должен быть защищен. Я рекомендую посмотреть и / или использовать сторонние протоколы аутентификации (что вы и делаете, даже если вы выполняете роли потребителя и поставщика аутентификации).
Ответ №6:
Рики из Twilio здесь.
Мы только что выпустили нетривиальный, готовый к использованию пример руководства по двухфакторной аутентификации, с которым вы можете ознакомиться, если ищете вдохновение для создания подобной системы.