Я уже устал писать про пароли. Но как и налоги, электронная почта и красные глаза, они никуда не денутся. Что я могу сказать, исходя из опыта:
Что с этим можно сделать разработчику?
Обычно это делается при помощи показателя сложности пароля, которая работает в интерактивном режиме.
Это применяют тогда, когда никак нельзя избежать хранения паролей.
Проще всего усилить пароль, сделав его подлиннее. При прочих равных экспоненциальный закон говорит, что чем пароль длиннее, тем он л��чше. Я люблю секретные фразы, хотя их очень тяжело вводить на сенсорных экранах в нашем мобильном мире. Но насколько длинным должен быть пароль?
При разработке Discourse надо было выбрать минимальную допустимую длину пароля. Я выбрал 8, на основании быстрого исследования. Это не так уж и много, но если вы используете достаточное количество разных символов, должно хватить для защиты от атак.
И я не имею в виду те атаки, когда подбор паролей происходит через перезагрузку страниц или форм ввода. Это может сработать для самых популярных паролей, но обычно сайты и приложения защищаются от частого повторного ввода данных.
Я имею в виду высокоскоростной оффлайновый подбор хэшей, где у хакера есть в распоряжении база утёкших паролей. Такие утечки были и будут.
Если вам не повезло, разработчики приложения, сервиса или сайта хранят пароли в открытом виде. Это не часто бывает в последнее время – прогресс. Но даже если они сохранили пароль в хэше – молитесь, чтоб это был медленный и сложный алгоритм хэширования, типа bcrypt. И они выбрали достаточное количество итераций. Упс, это было актуально уже давно, в средние века, около 2010 года. Я хотел сказать, что в качестве алгоритма нужно выбирать scrypt.
И всё будет нормально. Да?
Вы скажете, что «большой массив для взлома» – это экзотика. Извините. Массив из 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 символов.
Конечно, все эти расчёты зависят от используемого алгоритма хэширования. Придётся принять, что все используемые вами пароли будут хранится с шифрованием самым глупым и быстрым алгоритмом. Слишком много ещё старых программ и алгоритмов, которые будут жить долгое-долгое время.
Разработчики:
Но это лишь советы – вам надо подогнать настройки под реалии ваших серверных систем. Например, у нас был случай, когда баг в Discourse позволял пользователям водить пароли длиною до 20000 символов, и подсчёт хэша этого пароля занимал много секунд.
А теперь пойду-ка я поменяю свой пароль на PayPal.
- неважно, что вы скажете пользователям, они будут выбирать простые пароли
- и они будут использовать один и тот же пароль везде. Если повезёт – два пароля
Что с этим можно сделать разработчику?
- прекратите требовать пароли и разрешите авторизацию через 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.
