Комментарии 22
Учитывая что расшифровка будет происходить локально и почти мгновенно, то интересно - насколько при современных вычислительных мощностях будет устойчив 16-символьный пароль. Наверняка можно приспособить какую нибудь cuda и перебирать ооочень быстро, а верефицировать по наличию валидных тегов например.
Если используется правильная криптография - то этап преобразования пароля в ключ специально делают очень ресурсоемким как раз против этого. Причём не только по вычислениям, а еще и по объему требуемой памяти. Условно, расшифровка самого текста может занимать миллисекунду, а восстановление ключа для неё из пароля - секунду и требовать 128 мегабайт быстрой памяти. Примеры - scrypt, argon2.
Буквально на днях по фану то же самое делал и соль в том, как остальные 4 аргумента будут заданы для PBKDF2, например число итераций – существенно замедляет перебор, думаю не большая проблема для пользователей даже если задержка на обработку одного пароля составит более секунды
16 символов 64-значного алфавита - это 2 в степени (16 * 6) паролей. 4090 расчитывает 30 мегахэшей в секунду PBKDF2. Итого, делим первое на второе и получаем примерно 10^11 лет, что примерно в 6 раз больше возраста вселенной. Это без учёта времени необходимого на расшифровку AES-256 и проверку что расшифровалось что-то осмысленное.
насколько при современных вычислительных мощностях будет устойчив 16-символьный пароль
Если ваши вычислительные русурсы позволяют перебирать один триллион хэшей в секунду, то на полный перебор всех возможных 16-значных комбинаций [a-zA-Z0-9] у вас уйдет примерно 1.5 миллиарда лет. Триллион хэшей в секунду, возможно, могут выдать только все суперкомпьютеры из списка Топ500 суммарно.
Главная уязвимость - это люди. Берём список из самых популярных паролей и поехали)
Берём список из самых популярных паролей и не даём их устанавливать.
"Берём список из самых популярных паролей" и добавляем к ним год рождения админа или опса
Кстати говоря, не обязательно иметь этот список, достаточно лишь проверить, как часто пароль фигурирует в утечках и отвергать те, что более N раз попадались, см. https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange
Хотя да, локально список для ускорения - норм оптимизация
Искомый хеш, скорее всего, будет где-то в середине. Все перебирать не придётся. Делите ожидаемое время на два. Но это, конечно, среднее время при переборе множества паролей. А если найти нужно только один хеш, то он может оказаться и последним в списке, но и первым тоже.
Злоумышленник не знает заранее какого размера ломаемый пароль. Поэтому перебирать он будет сначала пароли минимально допустимого размера, наращивая размер на каждой следующей итерации. Так что до того, как он начнет перебирать все 16-знаки, ему сначала надо будет перебрать все 15-знаки (24 миллиона лет), а еще раньше надо будет перебрать все 14-знаки (390 тысяч лет), ну и так далее.
15-ти значные это 1/10 часть 16-ти значных, что гораздо меньше половины.
Зачем перебирать пароли? Он будет перебирать сразу конечные хеши.
Тут хеш соленый, а значит нет готового "конечного хеша" для предполагаемого пароля.
Он же хранится в localStorage, насколько я помню статью, поэтому не важно, какой пароль, нужно просто положить в хранилище правильнй хеш.
Зачем перебирать пароли? Он будет перебирать сразу конечные хеши.
Для экономии времени. Количество всех возможных хэшей существенно больше количества всех возможных 16-значных случайных паролей. В AES-256 возможно примерно 1e77 ключей, а паролей вида [a-zA-Z0-9]{16} "всего" примерно 1e28.
Ну, 16 — это только рекомендация, он может быть длиньше. Или короче. Однако, как выше заметили, стоит учитывать затрачиваемое время на генерацию хеша из пароля. Требуются более детальные подсчёты.
Есть физические ограничения, человечеству просто не хватит ни времени, ни энергии внутри солнечной системы, чтобы лишь пересчитать числа от 0 до 2 в 128 степени. Если я правильно расчитал, то до потухания Солнца мы сможем передвинуть лишь 2 в 112 степени битов. Ни о каких полных переборах 256-битных ключей речи быть не может.
Использовал StatiCrypt для ограничения доступа к статическому сайту (собран с помощью Eleventy). Полезная штука для Jamstack-сайтов.
Парольная защита статичной HTML-страницы на JS