Неадекватные требования к паролям, небезопасная обработка токенов и многое другое.
В настоящее время данные являются одним из самых ценных активов компании. Его нужно оберегать любой ценой, поскольку утечка может иметь катастрофические последствия с точки зрения доверия пользователей и развития бизнеса. Однако многие компании совершают огромные ошибки, когда речь идет о безопасности. Особенно это касается малого и среднего бизнеса, хотя даже крупные предприятия иногда подвергаются взлому из-за роковой ошибки, что может привести к скандалам.
Требования к неверным паролям для пользователей
Для использования большинства веб-приложений требуется зарегистрировать учетную запись. Мы все знакомы с требованиями к паролям, которые предъявляют определенные системы входа в систему, от минимальной длины до использования хотя бы одного специального символа. Некоторые компании, однако, понимают это совершенно неправильно.
Какое самое глупое правило пароля вы можете придумать? Вероятно, вы можете найти его в этом репозитории GitHub. Он содержит список неадекватных требований, предъявляемых реальными компаниями к своим клиентам.
А как насчет Bank of America, который не разрешает использовать более 20 символов или запрещает использование специальных символов? Разве это не должно сохранить ваши деньги в безопасности?
Что вы думаете вместо запрета паролей длиннее 10 символов? BlackRock действительно сделал это!
Применение таких ограничений значительно сокращает время взлома хэша, а также совершенно бесплатно сообщает хакерам, как выглядят пароли для конкретного веб-сайта.
Обработка токенов как паролей
Многие компании предоставляют свои услуги через какой-либо токен аутентификации. По своей сути это не является плохой практикой, но вы всегда должны проверять, получены ли токены из надежного источника или они могли быть скомпрометированы. Вы не должны ни разрешать использование одного и того же токена сеанса на разных устройствах, ни позволять одному токену предоставлять доступ к аутентифицированному сеансу.
Проблема с токенами заключается в том, что их можно относительно легко украсть, так как они в основном хранятся в браузере под небольшой защитой. Это открывает ваше приложение для атак перехвата сеанса или даже поддельных страниц входа. Недавно я столкнулся с компанией-разработчиком программного обеспечения для управления школами, имя которой я не буду называть, поскольку они в настоящее время не исправили проблему, которая не выполняет проверки своих токенов сеанса и запроса на вход.
Хранение паролей в виде обычного текста
Это может показаться ошибкой, которую может совершить только неопытный разработчик, но многие крупные компании, такие как Facebook, Google и GitHub, действительно сделали это.
Мы все знаем, что в случае утечки данных в ваших системах баз данных все ваши учетные записи пользователей могут быть легко скомпрометированы. Однако вы можете и не думать об утечке конфиденциальной информации через неправильно настроенные системы ведения журналов. В 2019 году пароли миллионов пользователей Facebook и Instagram были найдены в логах, хранящихся в удобочитаемом формате (about.fb.com).
Придание слишком большой силы паролю
Паролей не должно быть достаточно для выполнения любой важной операции в любой системе. Привилегированные роли всегда должны быть защищены двухфакторной аутентификацией, поскольку одна скомпрометированная привилегированная учетная запись может стать причиной катастрофических атак.
Другая похожая проблема заключается в том, что вы не предоставляете своим пользователям возможность двухфакторной аутентификации. Невероятно, сколько компаний до сих пор вообще не поддерживают этот метод.
Принудительная периодическая смена пароля
Не секрет, что чем больше времени проходит, тем больше вероятность того, что пароль будет взломан. Вот почему многие компании требуют, чтобы их клиенты периодически меняли свои учетные данные для аутентификации, возлагая на них ответственность за выбор надежных паролей.
Однако это может быть проблемой, поскольку пользователи обычно придерживаются предсказуемых шаблонов, таких как изменение Summer2020 на Summer2021, и они обычно пытаются обойти небезопасные политики паролей. Вместо такого подхода Национальный институт стандартов и технологий (NIST) рекомендует ввести список запрещенных паролей, чтобы запретить пользователям выбирать слабые и предсказуемые секреты, включая словарные слова, имена пользователей и последовательные символы, такие как 1234. .
Кроме того, учетные данные следует периодически проверять по общедоступным базам данных утечки данных, чтобы выяснить, безопасно ли использование определенного пароля. Будьте осторожны, однако, не отправляйте свои драгоценные строки в незашифрованном виде через Интернет: это намного безопаснее, если это делается локально.
Не солить и не перчить
Несмотря на то, что компьютеры стали мощнее, чем когда-либо, взлом паролей никогда не был быстрее. Проблема в том, что технологии сильно развиваются, а общие пароли остаются прежними.
Посол заключается в добавлении уникальных рандомизированных данных в качестве дополнительных входных данных для функции хеширования пароля. Затем случайная соль будет храниться в базе данных и извлекаться по запросам на вход.
Peppering заключается в добавлении секретного фрагмента данных в качестве дополнительного входа в функцию хеширования пароля. Перец, в отличие от соли и хэшей, хранится отдельно, чтобы не утекла информация в случае взлома базы данных.
Эти дополнительные данные, которые добавляются к паролю, делают его уникальным и, следовательно, более сложным для взлома с помощью радужных таблиц. Добавление соли и перца может повысить безопасность слабых паролей и сделать сложные пароли практически неподдающимися взлому.
Заключение
Подводя итог, безопасность не означает 100% отказоустойчивость. Это скорее исследование лучших практик по защите систем от уже известных угроз и поиск новых уязвимостей до того, как это сделают злоумышленники.
Это лишь некоторые из множества ошибок, допускаемых при работе с паролями, но они, тем не менее, существенны, и их следует избегать в любых приложениях, требующих определенного уровня безопасности.
Надеюсь, вам понравилась эта статья. Если вам известны какие-либо другие серьезные ошибки, связанные с паролями, поделитесь ими в комментариях. Спасибо, что прочитали!
Если вам понравилась эта статья, я предлагаю вам также ознакомиться с этой историей ниже:
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку здесь.
