Я уже устал писать про пароли, но как налоги, электронная почта и красные глаза, они никуда не денутся.
Несмотря на то, что в мире придумано много способов аутентификации и контроля доступа, именно пароль самый распространенный и одновременно наиболее уязвимый.
Множество интернет-порталов и сервисов в целях безопасности запрещают пользователям создавать простые пароли. Самым ненадежным паролем к интернет-аккаунтам по итогам 2014 года оказалась комбинация цифр 123456. Что я могу сказать, исходя из опыта: неважно, что вы скажете пользователям, они будут выбирать простые пароли, и они будут использовать один и тот же пароль везде. Если повезёт – два пароля.
Что с этим можно сделать разработчику?
- прекратите требовать пароли и разрешите авторизацию через Google, Facebook, Twitter, Yahoo или любой другой сервис. Лучший пароль – тот, который не нужно хранить.
- поощряйте браузеры к поддержке автоматических встроенных систем создания и управления паролями. В идеале – поддерживаемых и операционками, но тут уже требуется всеобщая привязка к облачным технологиям. В эту сторону двигается Chrome.
Делайте замечания пользователям, когда они вводят:
- слишком короткие пароли: UY7dFd
- пароли с минимумом энтропии: aaaaaaaaa
- пароли из словаря: anteaters1
Обычно это делается при помощи показателя сложности пароля, которая работает в интерактивном режиме. Это применяют тогда, когда никак нельзя избежать хранения паролей.
Проще всего усилить пароль, сделав его подлиннее. При прочих равных экспоненциальный закон говорит, что чем пароль длиннее, тем он лучше. Я люблю секретные фразы, хотя их очень тяжело вводить на сенсорных экранах в нашем мобильном мире. Но насколько длинным должен быть пароль?
При разработке Discourse надо было выбрать минимальную допустимую длину пароля. Я выбрал 8, на основании быстрого исследования. Это не так уж и много, но если вы используете достаточное количество разных символов, должно хватить для того, чтобы защита данных от атак обеспечивалась.
И я не имею в виду те атаки, когда подбор паролей происходит через перезагрузку страниц или форм ввода. Это может сработать для самых популярных паролей, но обычно сайты и приложения защищаются от частого повторного ввода данных. Я имею в виду высокоскоростной оффлайновый подбор хэшей, где у хакера есть в распоряжении база утёкших паролей. Такие утечки были и будут.
Если вам не повезло, разработчики приложения, сервиса или сайта хранят пароли в открытом виде. Это не часто бывает в последнее время – прогресс. Но даже если они сохранили пароль в хэше – молитесь, чтоб это был медленный и сложный алгоритм хэширования, типа bcrypt. И они выбрали достаточное количество итераций. Это было актуально уже давно, в средние века, около 2010 года. Я хотел сказать, что в качестве алгоритма нужно выбирать scrypt.
И всё будет нормально. Да?
- возьмём случайный набор из 8 символов. Заметьте, что и у генератора это дефолтная длина. Я получил «U6zruRWL»
- впишем его в поле ввода сервиса проверки сложности паролей GRC password crack checker
- получим, что при применении «Большого массива для взлома» скорость его обнаружения составит 2.22 секунды
- пойдём, полежим с тёплым полотенчиком на лице
Вы скажете, что «большой массив для взлома» – это экзотика. Извините. Массив из 24 обычных GPU, оптимизированных для быстрого подбора хэшей, доступен любому агентству и среднему бизнесу. Кроме того, их не обязательно покупать, а можно арендовать – например, в облаке. А представьте, на что способно агентство национального масштаба.
Даже если отбросить этот сценарий, то в графе «простой оффлайновый перебор» значится всего лишь 37 минут.
Попробуем удлинить пароль. Что получится?
9 символов — 2 минуты
10 символов — 2 часа
11 символов — 6 дней
12 символов — 1 год
13 символов — 64 года
Может, добавим спецсимволов?
8 символов – 1 минута
9 символов – 2 часа
10 символов – 1 неделя
11 символов – 2 года
12 символов – 2 века
Уже неплохо, но безопасной кажется лишь отметка в 12 символов, содержащих верхний и нижний регистр, цифры и спецсимволы. И «большие массивы для взлома» медленнее становится не будут. Всегда будет такое количество символов, которое благодаря экспоненте будет недостижимо, но со временем мощности процессоров будут лишь расти.
Вот что я скажу, несчастный пользователь: если Ваш пароль короче 12 разных символов, Вы в опасности, а защита данных становится уязвимой. Создавайте случайные пароли не короче 12 символов.
Конечно, все эти расчёты зависят от используемого алгоритма хэширования. Придётся принять, что все используемые вами пароли будут хранится с шифрованием самым глупым и быстрым алгоритмом. Слишком много ещё старых программ и алгоритмов, которые будут жить долгое-долгое время.
Разработчики:
- выбирайте алгоритмы хэширования внимательно. Обновляйте свои системы. Используйте хэши, которые трудно подбирать на GPU, например scrypt.
- выбрав правильный хэш, выбирайте и правильные настройки для его работы. Матсано рекомендует такие настройки:
- scrypt: N=2^14, r=8, p=1
- bcrypt: cost=11
- PBKDF2 with SHA256: iterations=86,000
Но это лишь советы – вам надо подогнать настройки под реалии ваших серверных систем. Например, у нас был случай, когда баг в Discourse позволял пользователям вводить пароли длиною до 20000 символов, и подсчёт хэша этого пароля занимал много секунд. А теперь пойду-ка я поменяю свой пароль на PayPal.
