Безопасность PIN-кода PHP-клиента
В настоящее время я занимаюсь разработкой системы, которая имеет функциональность, в которой клиенты могут просматривать детали своих покупок / продлений / и т. Д., Вводя PIN-код "номер".
PIN-код используется вместо информации для входа в систему из-за типа клиентов, на которые мы ориентируемся. ПИН печатается на отправленных им документах.
Представление, отображаемое при предоставлении PIN-кода, не раскрывает очень конфиденциальную информацию, такую как кредитная карта и т. Д., Но менее чувствительную, такую как название продукта, тип, цена, штрих-код, ремонт и т. Д.
Речь идет о ПИН-коде. Я решил использовать случайный 5-значный PIN-код (0-9, az AZ) - с учетом регистра. Я буду удалять некоторые гомоглифы ("I", "1", "l", "0", "O", "rn", "vv"), поэтому фактическое количество комбинаций на самом деле меньше.
У меня есть пара вопросов по этому поводу:
- Является ли эта практика приемлемой?
- Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов при большом количестве неудачных попыток?*
- Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?
- * Должен ли я использовать систему кодирования?
6 ответов
Что касается CAPTCHA и блокировки - я бы пошел на CAPTCHA и задержал 1) клиентов, которые не проходят CAPTCHA, и 2) недействительных входов в систему: перед проверкой, спите 1 секунду при первой попытке, 2 секунды при второй, 4 секунды третье, 8 секунд при последующий. Это не доставит много неудобств обычным пользователям, но значительно замедлит атакующего. Неважно, что вы делаете, люди поймут это неправильно - не нужно их прямо запрещать.
Контрольная сумма - может быть полезна в качестве 6-го символа для обнаружения ошибок ввода, а не для безопасности.
Что касается надежности пароля, то это слабый пароль - я бы не использовал его в качестве единственной формы авторизации для чего-либо более сильного, чем "обмен изображениями lolcats" - рассмотрим более длинный, иначе ваши клиенты могут даже случайно получить доступ к каждому данные других (и они, как правило, очень расстраиваются, когда это происходит: "вы имеете в виду, что кто-то может видеть мои данные в таком виде?!").
PIN-код используется вместо информации для входа в систему из-за типа клиентов, на которые мы ориентируемся. ПИН печатается на отправленных им документах.
Очень странно, но да, можно написать так. Я думаю, что вы должны действительно пересмотреть, если это действительно необходимо. Но если я правильно вас понял, вы отправили документ по почте? Например, нельзя ли отправить пользователю PIN-код, а затем попросить его войти в openID ( LightOpenID). Я бы заблокировал его только у провайдера OpenID от Google, потому что эти учетные записи "безопасны". Таким образом, вы добавили еще один уровень безопасности. Также Google использует капчу для подтверждения аккаунта (сделать его "безопасным").
Является ли эта практика приемлемой?
Я думаю, что это приемлемо, хотя и очень странно.
Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов при большом количестве неудачных попыток?*
Я думаю, что вы должны написать механизм блокировки, потому что пароль взлома методом взлома уже легко осуществить, но взлом ПИН-кода методом взлома может быть осуществлен без каких-либо усилий. Хотя я не думаю, что вы должны делать это через IP, потому что конечный пользователь может сидеть за маршрутизатором, и тогда он будет заблокирован. Также хакеры могут иметь ботнет для выполнения подобных атак. Я прочитал сегодня о HashCash благодаря stackru.com, и я также нашел его очень интересным. Может быть, вы могли бы использовать это, чтобы защитить себя от атак.
Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?
Я так не думаю.
Должен ли я использовать систему кодирования?
Единственный верный способ предотвратить автоматизированные атаки - это CAPTCHA, так что я думаю, что вы должны. Google/Twitter/ и т. Д. Используют не CAPTCHA, потому что они удобны для пользователя, а потому, что это единственный рабочий способ остановить автоматические атаки. Если бы вы внедрили в мою систему этот ПИН-код с OpenID от Google, вы можете пропустить этот шаг, потому что Google уже предоставил вам покрытие.
Прежде всего, спросите не только PIN-код, добавьте что-то простое, что клиент знает, например, в системах обычной почты, где вас часто спрашивают ваш ZIP-код. Это сортирует людей, которые не знают какой-то "общей тайны".
Капча, если не сложно, имеет смысл, так как помогает уменьшить попытки "угадать" ботами. Как отметил Стефан, запрет по IP проблематичен из-за общих IP-адресов.
Вы также можете реализовать своего рода "tar pit", когда сообщения формы неправильны, основываясь на вашей проверке ошибок, например, вы задерживаете обработку входящих соединений. Простая алгоритмическая проверка ошибок помогает избежать бесполезного поиска в базе данных данного PIN-кода.
1) Да, зависит от целевой аудитории. 2) Иногда это имеет смысл, иногда это не будет работать из-за того, как используется система и сколько клиентов используют общий IP-номер. 3) Какую ценность это добавит? Разве это не поможет людям, пытающимся найти работающий PIN-код? 4) Зависит от целевой аудитории, и что за капча.
- да, но это зависит от ценности информации, если ценность информации высока, и вы думаете, что кто-то может попытаться взломать вас, следует рассмотреть дополнительные меры защиты
- Это может быть хорошей идеей, если информация, которую вы защищаете, имеет высокое значение, в этом случае вы должны предупредить пользователя о том, что он имеет ограниченное число возможностей, создать также файл журнала для отслеживания сбоев при вводе кода и учитывать, что если Пользователь находится за NAT, многие пользователи могут использовать один и тот же IP-адрес (например, все пользователи в офисе или в школе, а также соединения типа fastweb используют один IP-адрес для большой группы людей), поэтому не блокируйте IP-адрес для длительное время (15-30 с каждые 3-5 сбоев должно быть достаточно, чтобы избежать атак методом перебора, вы можете удвоить его каждый раз, когда пользователь отказывает во второй раз) и, самое главное, блокировать только отправку кода, а не весь сайт.
- это не нужно, но вы можете реализовать это, как я сказал, это также зависит от ценности информации
- Это хорошая идея - избегать прокси и сканеров, но я рекомендую что-то другое: используйте изображение с вопросом типа "пять плюс 2 =" или "какого цвета красное яблоко?", их гораздо сложнее понять. сканеры, но гораздо проще для пользователей.
Я также рекомендую использовать mt_rand() для рандомизации пин-кода (намного более эффективный, чем случайный по умолчанию, статистически правильный случайный случай и он встроен в php по умолчанию), удаление гомоглифов должно быть хорошим способом избежать ошибок при вводе, но я могу рекомендуем также создать более длинный код с разделителями, такими как
AXV2-X342-3420
поэтому пользователь должен понимать, что это код, и легко подсчитать, сколько символов осталось или, если он ввел неправильный код.
Я могу избежать вывода с учетом регистра, так как символы верхнего регистра легче читать, и некоторые пользователи просто вставят его в нижний или верхний регистр, даже если вы четко напишите, что код чувствителен к регистру.
Аксиома "Если вы собираетесь свернуть свою собственную безопасность, вы уже потерпели неудачу", применяется здесь.
Для вашего 5-символьного вывода [0-9, AZ, az] вы генерируете менее 8,27 бит энтропии (64 310 = 2 ^ n). [фиксированный]
Злоумышленнику потребуется менее одного дня (1000 угаданий в секунду, что очень медленно) для взлома вашей системы. Это приемлемо? Может быть, для тривиальных систем, где обход безопасности имеет очень мало влияния.
Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов при большом количестве неудачных попыток?
IP-адреса могут быть подделаны.
Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?
Это на самом деле уменьшит количество бит в вашей энтропии, упрощая проникновение в вашу систему.
Должен ли я использовать систему кодирования?
Если вы чувствуете, что вам нужно упражнение. Капчи были сломаны и бесполезны для чего-либо кроме скорости
Обновить
К сожалению, нет единого решения для компьютерной безопасности, так как это все еще незрелая (недоразвитая?) Область. Любой, кто говорит: "О, делай то-и-то, и у тебя все будет хорошо", пропускает одну из самых фундаментальных проблем безопасности.
Безопасность - это всегда компромисс
К защищенной системе невозможно получить доступ. С другой стороны, в конечном итоге доступная система не имеет препятствий для входа. Очевидно, что обе крайности недопустимы.
Ваша работа как разработчика программного обеспечения заключается в том, чтобы найти сладкое место между ними. Это будет зависеть от нескольких факторов:
- Техническая экспертиза ваших пользователей
- Готовность ваших пользователей мириться с безопасностью
- Затраты (время и деньги) на внедрение и обслуживание (т. Е. Более сложная система вызовет больше обращений в службу поддержки)
- Влияние казенной части на ваших пользователей и компанию
- Вероятность казенной части: вы министерство обороны США? Visa? Вы, вероятно, сейчас под атакой. Магазин велосипедов Боба в Охае, Калифорния, находится на другом конце спектра.
Из вашего вопроса я понимаю, что вы эффективно генерируете их "пароль" для них. Что если вы перевернули его с ног на голову? Сделайте пин-код своей учетной записью, и при первом входе в вашу систему им нужно будет создать пароль *, который затем потребуется с этого момента.
* Да, если это банк, то это не очень хорошая идея.