Повышение безопасности входа в систему через Интернет
Сейчас моя система входа в систему следующая:
- Пароль должен состоять не менее чем из 8 символов и содержать как минимум одну заглавную и строчную букву, число и символ.
- Пароль не может содержать имя пользователя в качестве подстроки.
- Имя пользователя, соленый + хешированный (с использованием SHA2) пароль, хранящийся в базе данных.
- Одноразовый номер (соль) уникален для каждого пользователя и хранится в виде открытого текста вместе с именем пользователя и паролем.
- Весь процесс входа в систему может быть выполнен только через TLS
Как бы вы оценили эффективность следующих мер для повышения безопасности?
- Увеличить длину пароля
- Заставить пользователя менять пароль каждые
Xпериод времени, и новый пароль может ' 4 и 6, конечно, эффективны только тогда, когда злоумышленник скомпрометировал базу данных (например, с помощью SQL-инъекции), но не файловую систему, в которой находится приложение.
5 ответов
3 Увеличьте размер nonce с 32 байт до 64 байт
4. Зашифруйте соль с помощью AES, при этом ключ будет доступен только приложению, выполняющему аутентификацию
. 5 Перехешируйте пароль несколько раз
Эти шаги применимы только в тех случаях, когда файл паролей (столбцы БД) украден и виден злоумышленнику. Одноразовый номер только побеждает предварительное хеширование (радужные таблицы), но это все же хорошо, и его следует сохранить.
(Опять же, если предположить, что вы пытаетесь свести к минимуму влияние скомпрометированной БД.) Шифрование одноразового номера означает, что злоумышленнику нужно выполнить дополнительный шаг грубой силы, но вы не сказали, где находится ключ шифрования для одноразового номера. хранится. Вероятно, можно с уверенностью предположить, что если БД будет скомпрометирована, одноразовый номер будет открытым текстом или тривиально расшифрован. Таким образом, усилия злоумышленника снова представляют собой перебор каждого хэша.
Повторное хеширование просто увеличивает время атаки грубой силы, но, возможно, ненамного больше, в зависимости от ваших предположений о взломах потенциального злоумышленника в секунду.
Независимо от ваших требований к составу пароля, пользователь все равно может создать «более угадываемый» пароль, например «P@ssw0rd», который соответствует правилу. Таким образом, грубая сила, скорее всего, будет успешной для некоторой группы пользователей в любом случае.(Под этим я подразумеваю принятие мер по предотвращению раскрытия паролей.)
Схема хранения паролей выглядит довольно неплохо с точки зрения защиты от раскрытия. Я бы удостоверился, что другие части процесса аутентификации также безопасны (ограничение количества попыток входа в систему, истечение срока действия пароля, меры противодействия SQL-инъекциям, трудно предсказуемые токены сеанса и т. д.), а не переусложнять эту часть.
- Увеличение длины пароля добавляет к паролю несколько битов энтропии.
- Требование частой смены пароля, как правило, вынуждает пользователей использовать менее безопасные пароли. Им нужно будет выяснить, какой пароль в мае, июне, июле. Некоторые@05x, Некоторые@06x, Некоторые@07x.
- Точно не могу сказать, но я ожидаю, что длина пароля в вашем случае будет иметь большее значение.
- Чуть безопаснее. Но если кто-то получит доступ к вашим данным, он, скорее всего, сможет получить доступ к ключу.
- Кроме увеличения затрат на ЦП, вы ничего не получите.
Существует ряд хорошо зарекомендовавших себя алгоритмов одностороннего шифрования паролей, которые являются достаточно безопасными. Я бы использовал один из них, а не изобретал свой собственный. Ваши исходные элементы 1, 2 и 5 хороши. Я бы отказался от 3 и 4.
Вы можете разрешить использовать парольные фразы, чтобы облегчить проблемы с длиной пароля.
Ответы могут в некоторой степени зависеть от характера веб-сайта, его пользователей и злоумышленников. Например, это тот сайт, на котором взломщики могут нацеливаться на определенные учетные записи (возможно, учетные записи администратора), или это сайт, на котором они просто хотят получить как можно больше учетных записей? Насколько техничны пользователи и насколько они заинтересованы в обеспечении безопасности своей учетной записи? Не зная ответов, я предполагаю, что они не технические и не мотивированные.
Меры, которые могут иметь значение
5) Перефразируйте пароль несколько раз. Это может значительно замедлить все атаки методом полного перебора — хэширование выполняется в 1000 раз, а атаки методом полного перебора становятся в 1000 раз медленнее.
4) Зашифровать соль с помощью AES, с ключом, доступным только для приложения, выполняющего аутентификацию. Как бы вы сделали его доступным только для приложения? Его нужно где-то хранить, и, скорее всего, если приложение будет скомпрометировано, злоумышленник сможет его получить. Могут быть некоторые атаки непосредственно на БД, где это имеет значение, поэтому я бы не назвал это бесполезным, но, вероятно, оно того не стоит. Если вы приложите усилия, вы также можете зашифровать сам пароль и любые другие конфиденциальные данные в БД.
6) Используйте соль, представляющую собой комбинацию более длинной соли для всего приложения + уникальной соли пользователя в базе данных. Если вас интересует только пароль, то да, это будет лучший способ добиться того же результата, что и 4), и, конечно же, его очень легко реализовать.
Неэффективные меры
3) Увеличить размер одноразового номера с 32 до 64 байт. Вычисление радужных таблиц уже совершенно непрактично с любой солью, поэтому это имело бы значение только в том случае, если бы соль не была известна злоумышленнику. Однако, если они могут получить хешированный пароль, они также могут получить соль.
Неэффективные и раздражающие меры
1) Увеличьте длину пароля Увеличение длины пароля свыше 8 не окажет практического влияния на время перебора.
2) Заставить пользователя сменить пароль Согласен, это всегда можно обойти. На самом деле, это может сделать сайт менее безопасным, потому что люди будут где-то записывать пароль!
Я бы посоветовал вам прочитать http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNothanks.pdf
Это В статье обсуждается часть причин, по которым трудно заставить пользователей следовать двум хорошим советам по безопасности; Короче говоря, затраты ложатся на пользователей, и они не получают почти никакой выгоды.
Увеличение длины пароля и принудительное использование более сложных паролей может снизить секретность, приводя к одному или обоим; переиспользование паролей между сайтами/приложениями и запись паролей.
Наилучшей защитой было бы избегать использования паролей целиком. . Если это корпоративное приложение, использующее Active Directory, рассмотрите возможность делегирования проверки подлинности вместо написания собственной. Другие подходы могут включать в себя использование информационных карточек, чтобы сделать ваше приложение осведомленным об утверждениях.