Обычно парольная защита производится через веб-сервер, который проверяет пароль и выдаёт контент. Стандартный способ:
.htaccess и htpasswd. Но что, если нужно выложить зашифрованную веб-страницу и файлы на публичном хостинге, где у нас нет контроля над сервером? Эту проблему решают инструменты StatiCrypt и Portable Secret.Для шифрования HTML перед публикацией StatiCrypt использует AES-256 и WebCrypto, а расшифровка происходит с помощью ввода пароля в браузере на стороне клиента, как показано в демо (пароль test).
StatiCrypt генерирует статическую страницу, которую можно безопасно заливать на любой хостинг, в том числе бесплатный сторонний хостинг, такой как GitHub Pages.
Страница будет расшифрована в браузере посетителя, когда тот введёт известный ему пароль. В принципе, эту систему можно использовать для шифрования личных заметок, если вы хотите выложить их на общедоступный сервер, чтобы всегда иметь к ним доступ, но при этом надёжно защитить от посторонних глаз.
Расшифровка происходит на обычном JavaScript, то есть со стороны клиента не требуется скачивание и установка дополнительных инструментов, кроме стандартного браузера. Ни хостинг-провайдер, ни интернет-провайдер не получают доступ к этой информации в процессе расшифровки её расшировки в браузере.
Проверить шифрование можно в веб-версии StatiCrypt. Сверху поля для исходного HTML и пароля:
Снизу — результат с зашифрованным HTML:
Есть даже веб-редактор для HTML и различные опции оформления интерфейса:
Консольная утилита StatiCrypt доступна для скачивания на Github, а также в виде пакета NPM. В консольной программе настройка интерфейса для поля ввода пароля производится изменением шаблона
lib/password_template.html в комплекте утилиты с указанием потом пути к шаблону через флаг -t path/to/my/file.html. Важно только не изменять фрагмент шифрования в этом шаблоне, в том числе формат переменных /*[|variable|]*/0 с обязательным нулём на конце.Существует готовый шаблон для создания и хостинга одностраничного зашифрованного сайта на GitHub Pages.
По умолчанию поле ввода пароля содержит флажок «Запомнить меня» (Remember me). В этом случае пароль хранится в localStorage (в хешированном виде с солью). Опять же по умолчанию нет срока хранения пароля. Для отключения данной опции при генерации страницы из консоли можно использовать флаг
--remember false. Срок хранения в днях указывает опция --remember NUMBER_OF_DAYS.Страница шифруется с помощью AES-256 в режиме CBC, который в контексте StatiCrypt лишён характерных для него уязвимостей. Пароль хешируется с помощью функции PBKDF2: 599 тыс. операций хеширования SHA-256 и 1000 операций SHA-1 (для легаси), что составляет рекомендуемой значение 600 тыс. операций.
По сути, генерируется новая веб-страница (зашифрованная), которая вмещает содержимое старой.
Для наилучшей безопасности рекомендуется использовать пароли длиной более 16-ти символов (буквы, цифры, спецсимволы) и менеджер паролей. Например, опенсорсный Bitwarden. Хотя AES-256 считается надёжным современным шифром, но для лучшей защиты от брутфорса лучше использовать пароли как можно большей длины.
Утилита также умеет генерировать ссылку, которая уже содержит хешированный пароль, для доступа к странице без ввода пароля непосредственно в веб-форме браузера. Такую ссылку можно передавать доверенным лицам или использовать самому, а контент при этом хранится на сервере в зашифрованном виде, недоступном для просмотра ни хостером, ни третьими лицами.
Похожий проект, но для шифрования файлов — Portable Secret. Его можно использовать для шифрования конфиденциальных файлов, которые хранятся в небезопасном месте: на USB-флешке, облачном хостинге, на веб-сайте и т. д. А также для шифрования файлов перед отправкой по открытому каналу: по почте или в мессенджере. В принципе, это современная удобная альтернатива PGP. Есть веб-демо для шифрования в браузере (в офлайне).
Комментарии (22)
pae174
22.12.2024 19:18насколько при современных вычислительных мощностях будет устойчив 16-символьный пароль
Если ваши вычислительные русурсы позволяют перебирать один триллион хэшей в секунду, то на полный перебор всех возможных 16-значных комбинаций [a-zA-Z0-9] у вас уйдет примерно 1.5 миллиарда лет. Триллион хэшей в секунду, возможно, могут выдать только все суперкомпьютеры из списка Топ500 суммарно.
MrSmitix
22.12.2024 19:18Главная уязвимость - это люди. Берём список из самых популярных паролей и поехали)
rznELVIS
22.12.2024 19:18"Берём список из самых популярных паролей" и добавляем к ним год рождения админа или опса
SanSYS
22.12.2024 19:18Кстати говоря, не обязательно иметь этот список, достаточно лишь проверить, как часто пароль фигурирует в утечках и отвергать те, что более N раз попадались, см. https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange
Хотя да, локально список для ускорения - норм оптимизация
Metotron0
22.12.2024 19:18Искомый хеш, скорее всего, будет где-то в середине. Все перебирать не придётся. Делите ожидаемое время на два. Но это, конечно, среднее время при переборе множества паролей. А если найти нужно только один хеш, то он может оказаться и последним в списке, но и первым тоже.
pae174
22.12.2024 19:18Злоумышленник не знает заранее какого размера ломаемый пароль. Поэтому перебирать он будет сначала пароли минимально допустимого размера, наращивая размер на каждой следующей итерации. Так что до того, как он начнет перебирать все 16-знаки, ему сначала надо будет перебрать все 15-знаки (24 миллиона лет), а еще раньше надо будет перебрать все 14-знаки (390 тысяч лет), ну и так далее.
Metotron0
22.12.2024 19:18Зачем перебирать пароли? Он будет перебирать сразу конечные хеши.
dreesh
22.12.2024 19:18Тут хеш соленый, а значит нет готового "конечного хеша" для предполагаемого пароля.
Metotron0
22.12.2024 19:18Он же хранится в localStorage, насколько я помню статью, поэтому не важно, какой пароль, нужно просто положить в хранилище правильнй хеш.
orekh
22.12.2024 19:18Вы не понимаете, документ уже был зашифрован с помощью ключа, ключ был образован необратимой операцией от пароля и соли. Если мы поменяем соль сейчас, то это никак не скажется на уже зашифрованном документе.
Metotron0
22.12.2024 19:18Я не про замену соли, я про подбор хеша вместо подбора ключа, раз уж ключ так долго генерировать.
pae174
22.12.2024 19:18Зачем перебирать пароли? Он будет перебирать сразу конечные хеши.
Для экономии времени. Количество всех возможных хэшей существенно больше количества всех возможных 16-значных случайных паролей. В AES-256 возможно примерно 1e77 ключей, а паролей вида [a-zA-Z0-9]{16} "всего" примерно 1e28.
Metotron0
22.12.2024 19:18Ну, 16 — это только рекомендация, он может быть длиньше. Или короче. Однако, как выше заметили, стоит учитывать затрачиваемое время на генерацию хеша из пароля. Требуются более детальные подсчёты.
orekh
22.12.2024 19:18Есть физические ограничения, человечеству просто не хватит ни времени, ни энергии внутри солнечной системы, чтобы лишь пересчитать числа от 0 до 2 в 128 степени. Если я правильно расчитал, то до потухания Солнца мы сможем передвинуть лишь 2 в 112 степени битов. Ни о каких полных переборах 256-битных ключей речи быть не может.
alexnozer
22.12.2024 19:18Использовал StatiCrypt для ограничения доступа к статическому сайту (собран с помощью Eleventy). Полезная штука для Jamstack-сайтов.
Spyman
Учитывая что расшифровка будет происходить локально и почти мгновенно, то интересно - насколько при современных вычислительных мощностях будет устойчив 16-символьный пароль. Наверняка можно приспособить какую нибудь cuda и перебирать ооочень быстро, а верефицировать по наличию валидных тегов например.
makkarpov
Если используется правильная криптография - то этап преобразования пароля в ключ специально делают очень ресурсоемким как раз против этого. Причём не только по вычислениям, а еще и по объему требуемой памяти. Условно, расшифровка самого текста может занимать миллисекунду, а восстановление ключа для неё из пароля - секунду и требовать 128 мегабайт быстрой памяти. Примеры - scrypt, argon2.
SanSYS
Буквально на днях по фану то же самое делал и соль в том, как остальные 4 аргумента будут заданы для PBKDF2, например число итераций – существенно замедляет перебор, думаю не большая проблема для пользователей даже если задержка на обработку одного пароля составит более секунды
orekh
16 символов 64-значного алфавита - это 2 в степени (16 * 6) паролей. 4090 расчитывает 30 мегахэшей в секунду PBKDF2. Итого, делим первое на второе и получаем примерно 10^11 лет, что примерно в 6 раз больше возраста вселенной. Это без учёта времени необходимого на расшифровку AES-256 и проверку что расшифровалось что-то осмысленное.