Безопасность PIN-кода PHP-клиента

Question

В настоящее время я занимаюсь разработкой системы, в которой есть функциональные возможности, позволяющие клиентам просматривать детали своих покупок / продлений / и т. Д., Предоставляя PIN-код "число".

PIN-код используется вместо информации для входа в систему из-за типа клиентов, на которые мы ориентируемся. PIN-код печатается на отправленных им документах.

Представление, отображаемое при предоставлении PIN-кода, не раскрывает очень конфиденциальную информацию, такую ​​как кредитная карта и т. Д., Но менее чувствительную, такую ​​как название продукта, тип, цена, штрих-код, ремонт и т. Д.

Речь идет о ПИН-коде. Я решил использовать случайный 5-значный PIN-код (0-9, a-z A-Z) - с учетом регистра. Я буду удалять некоторые гомоглифы ('I', '1', 'l', '0', 'O', 'rn', 'vv'), поэтому фактическое количество комбинаций равно на самом деле ниже.

У меня есть пара вопросов по этому поводу:

1. Приемлема ли эта практика?
2. Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов при большом количестве неудачных попыток? *
3. Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?
4. * Должен ли я использовать систему кодирования?

Answer 1

PIN-код используется вместо информации для входа в систему из-за типа клиентов, на которые мы ориентируемся.PIN-код напечатан на отправленных им документах.

Очень странно, но да, можно написать так.Я думаю, что вы должны действительно пересмотреть, если это действительно необходимо.Но если я правильно вас понял, вы отправили документ по почте?Например, нельзя ли отправить пользователю PIN-код, а затем попросить его войти в openID ( LightOpenID ).Я бы заблокировал его только у провайдера OpenID от Google, потому что эти учетные записи «безопасны».Таким образом, вы добавили еще один уровень безопасности.Также Google использует капчу для проверки аккаунта (сделать его «безопасным»).

Является ли эта практика приемлемой?

Я думаю, что это приемлемо, хотя и очень странно.

Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов с большим количеством неудачных попыток? *

Я думаю, что вы должны написать механизм блокировки, потому что грубаяПринудительный взлом пароля уже легко осуществить, но взлом ПИН-кода методом взлома может быть осуществлен без каких-либо усилий.Хотя я не думаю, что вы должны делать это через IP, потому что конечный пользователь может сидеть за маршрутизатором, и тогда он будет заблокирован.Также хакеры могут иметь ботнет для выполнения подобных атак.Я прочитал сегодня о HashCash благодаря stackoverflow.com, и я также нашел его очень интересным.Может быть, вы могли бы использовать это, чтобы защитить себя от атак.

Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?

Не знаюне думаю.

Должен ли я использовать систему кодирования?

Единственный верный способ предотвращения автоматических атак - это капча, так что я думаю, что вы должны.Google / Twitter / и т. Д. Используют не CAPTCHA, потому что они удобны для пользователя, а потому, что это единственный способ остановить автоматические атаки.Если бы вы внедрили в мою систему этот ПИН-код с OpenID от Google, вы можете пропустить этот шаг, потому что Google уже предоставил вам покрытие.

Answer 2

Что касается CAPTCHA и блокировки - я бы пошел на CAPTCHA и задержал 1) клиентов, которые отказывают в CAPTCHA, и 2) недействительных входов в систему: перед проверкой, спите 1 секунду при первой попытке, 2 секунды при второй, 4 секунды8-е на последующие.Это не доставит неудобств обычным пользователям слишком много , но значительно замедлит атакующего.Независимо от того, что вы делаете, люди будут ошибаться - нет необходимости прямо их забанить.

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

Что касается надежности пароля, то это слабый пароль - я бы не использовал его в качестве только формы авторизации для чего-либо более сильного, чем «обмен фотографиями lolcats» - подумайтеболее длинный, или ваши клиенты могут даже случайно получить доступ к данным друг друга (и они, как правило, расстраиваются действительно , когда это происходит: "Вы имеете в виду, что кто-то может видеть мои данные такого рода?! ").

Answer 3

Прежде всего, попросите не только ПИН-код, добавьте что-нибудь простое, известное клиенту, как, например, в системах обычной почты, где вы часто запрашиваете свой ZIP-код.Это сортирует людей, которые не знают какой-то «общий секрет».

Капча, если не сложно, имеет смысл, так как помогает уменьшить попытки «угадать» ботами.Как упоминал Стефан, бан по IP проблематичен из-за общих IP-адресов.

Вы также можете реализовать своего рода «tar pit», когда сообщения формы неправильны, основываясь на вашей проверке ошибок, например, вы задерживаете обработку входящих соединений,Простая алгоритмическая проверка ошибок помогает избежать бесполезного поиска в базе данных данного PIN-кода.

Answer 4

Аксиома "Если вы собираетесь бросить свою собственную безопасность, вы уже потерпели неудачу ," применяется здесь.

Для ваших 5 символов [0-9, AZ,az], вы генерируете менее 8,27 бит энтропии ( 64 310 = 2 ^ n). [исправлено]

Злоумышленнику потребуется менее одного дня (1000 угаданий в секунду, , что очень медленно ), чтобы взломать вашу систему.Это приемлемо?Может быть, для тривиальных систем, где обход безопасности имеет очень небольшое влияние.

Должен ли я написать механизм блокировки, чтобы "запретить" трафик с IP-адресов при большом количестве неудачных попыток?

IP-адреса могут быть подделаны.

Должен ли я написать систему проверки ошибок (аналог алгоритма Луна в номерах кредитных карт)?

Это фактически уменьшит количество битв вашей энтропии, облегчая проникновение в вашу систему.

Должен ли я использовать систему кодирования?

Если вы чувствуете, что вам нужно упражнение. Капчи были разбиты и бесполезны для чего-либо, кроме как для увеличения скорости.

Обновление

К сожалению, нет единого решения для компьютерной безопасности,как это все еще незрелое (недоношенное?) поле.Любой, кто говорит: «О, делай то-то-и-то, и у тебя все будет хорошо», пропускает одну из самых фундаментальных проблем безопасности.

Безопасность - это всегда компромисс

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

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

1. Техническая экспертиза ваших пользователей
2. Готовность ваших пользователей мириться с безопасностью
3. Стоимость (время и деньги)) для внедрения и обслуживания (т. е. более сложная система будет генерировать больше обращений в службу поддержки)
4. влияние , которое будет иметь место для ваших пользователей и компании
5. Вероятность казенной части: Вы Министерство обороны США?Visa?Вы, вероятно, сейчас под атакой.Велосипедная лавка Боба в Охае, Калифорния, находится на другом конце спектра.

Насколько я понимаю, вы действительно сгенерируете для них их «пароль».Что если вы перевернули его с ног на голову?Сделайте пин-код своей учетной записью, и при первом входе в вашу систему им нужно будет создать пароль *, который будет необходим с тех пор.

* Да, если это банк, то это не очень хорошоидея.

Answer 5

1. да, но это зависит от ценности информации, если ценность информации высока, и вы думаете, что кто-то может попытаться взломать вас, следует рассмотреть дополнительные меры защиты
2. Это может быть хорошей идеей, если информация, которую вы защищаете, имеет высокое значение, в этом случае вы должны предупредить пользователя о том, что он имеет ограниченное число возможностей, создать также файл журнала для отслеживания сбоев при наборе кода и учитывать что если пользователь находится за NAT, многие пользователи могут использовать один и тот же ip (например, все пользователи в офисе или в школе, а также соединение типа fastweb используют один ip для большой группы людей), поэтому не блокируйте ip в течение длительного времени (15-30 с каждые 3-5 сбоев должно быть достаточно, чтобы избежать атак методом перебора, вы можете удвоить его каждый раз, когда пользователь отказывает во второй раз) и, что наиболее важно, блокировать только отправку кода, а не весь сайт .
3. это не нужно, но вы можете реализовать его, как я сказал, это также зависит от ценности информации
4. отличная идея - избегать прокси и сканеров, но я рекомендую что-то другое: используйте изображение с вопросом типа «пять плюс 2 =» или «какого цвета красное яблоко?», Они намного сложнее понять сканерам, но гораздо проще для пользователей.

Я также рекомендую использовать mt_rand () для рандомизации пин-кода (намного более эффективный, чем случайный выбор по умолчанию, статистически правильный случайный случай и он встроен в php по умолчанию), удаление гомоглифов должно быть хорошим способом избежать опечатки но я могу порекомендовать также создать более длинный код с разделителями, такими как

 AXV2-X342-3420

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

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

Answer 6

1) Да, зависит от целевой аудитории. 2) Иногда это имеет смысл, иногда это не будет работать из-за того, как используется система и сколько клиентов используют общий IP-номер. 3) Какую ценность это добавит? Разве это не поможет людям, пытающимся найти работающий PIN-код? 4) Зависит от целевой аудитории и от того, что за капча.