Легкий способ преобразовать запоминаемый пароль в 65-символьный хэш для защиты ваших аккаунтов

Приветствую, друзья! В этой статье я хочу поделиться своим опытом создания расширения для браузера, которое превращает обычный, запоминающийся пароль в надежный 65-символьный хэш на основе SHA‑256 (да-да, я помню, что SHA-256 генерирует 64-символьную строку). Признаюсь честно, я не являюсь фронтенд-разработчиком и у меня весьма скудный опыт в JavaScript

Откуда появилась идея?

Наблюдая, как многие пользователи часто используют один и тот же пароль на разных сайтах (или имеют одинаковый паттерн создания паролей, я, кстати, тоже отношусь к этим людям), я задумался: а почему бы не сделать процесс автоматического усиления пароля?

Идея проста – вместо того, чтобы придумывать длинный и сложный пароль, пользователь вводит привычное слово, а расширение на его основе генерирует длинный хэш. Более того, с учетом требований многих сайтов (наличие хотя бы одной заглавной буквы и спецсимвола), хэш дополнительно форматируется: первая встреченная латинская буква становится заглавной, а в конце добавляется точка, как спец. символ (это и есть 65-ый символ)

Чем это может помочь?

Если везде одинаковый пароль, то будет везде одинаковый хэш

Действительно, это здравая мысль. Но по-моему скромному мнению перебрать пароль из 65-и символов довольно таки сложно, по крайней мере кратно сложнее, чем тот же 8-12 символьный пароль

Тем более для пользователя мало что меняется, то есть ему не нужно запоминать все 65 символов. Он помнит стандартный пароль, а, например, через любое API может построить хэш

НО, тут стоит помнить о тех условиях, которые применяются в том проекте: специальный символ в конце хэша и первая встречная буква - заглавная, а также стоит помнить алгоритм, который использовался для вычисления хэша

Хоть это и не решает проблему того, что везде будет один и тот же хэш, тут у меня есть пара мер минимизации, так сказать

Минимизация

  1. Хочу в автоматическую часть добавить получение домена текущего сайта, на котором было запущено расширение. Я не уверен, что такое возможно встроенными средствами, но суть в том, что домен сайта, где пользователь хочет использовать пароль будет служить "солью". Данная мера должна помочь избежать "один и тот же хэш везде"

  2. Добавить настройки для продвинутых пользователей. Можно будет выбирать алгоритмы вычисления хэшей, длину, сложность, ввести кастомную "соль", которая будет использоваться вместе с доменом

Заключение

Код я представил в репозитории

Первые минуты использования пока что радуют меня. Но насколько это удобно на горизонте продолжительного времени использования, пока непонятно

@RaisonCollab
09.04.2025 23:11 UTC
Первоисточник

Комментарии

@ferosod
09.04.2025 18:18 UTC
+2

Насчёт домена в качестве соли: сайты иногда переезжают на новый домен, или имеют несколько доменов в разных зонах (.com, .ru)

Это следует учесть

@RaisonCollab
09.04.2025 18:32 UTC
+1

Справедливое замечание. Даже проблема не в доменной зоне, а в домене второго уровня (вроде так называется), когда с x.ru переезжает на y.ru, хоть как по мне это и редкость, но тем не менее. Спасибо за замечание

@kafeman
09.04.2025 18:29 UTC
+2

Добавить еще несколько тысяч итераций, чтобы замедлить брутфорс для тех, кто в курсе вашего скрипта, сделать длину пароля настраиваемой, изобрести заново какой-нибудь PBKDF2 или лучше Argon2, и будет норм.

@RaisonCollab
09.04.2025 18:33 UTC
0

В планах было как раз Argon2 использовать ))

@inkelyad
09.04.2025 18:42 UTC
+7

Этот велосипед изобретают постоянно.

Раз (у него даже вариант в виде браузерного расширения есть)

Два

Какие именно (уже изобретенные) стандарты используются - в описаниях по ссылкам.

Но проблема вот в чем - просто хэш не получается. Очень быстро выясняется, что нужно хранить особенности. И получаем базу данных, по сценариям использования ничем не отличающуюся от такой же у менеджера паролей. И смысл тогда? Боимся, что используемую для шифрования этой базы криптографию сломают?

@garm
09.04.2025 18:52 UTC
+5

Не все сайты позволяют использовать пароли длиной 65 символов, к сожалению.

@NickDoom
09.04.2025 18:54 UTC
+1

Correct horse battery staple.

@inkelyad
09.04.2025 18:55 UTC
0

Не работает, если таких запоминать надо больше где-то дюжины.

10.04.2025 08:17 UTC
+3

и тут мы возвращаемся к идее менеджеров паролей

10.04.2025 08:35 UTC
0

и тут мы возвращаемся к идее менеджеров паролей

Именно.

@mlnw
09.04.2025 18:54 UTC
+9

Вы всё еще пользуетесь одинаковым паролем на всех сайтах в интернете? Я думал, с появлением встроенных в браузер менеджеров паролей эти времена давно прошли. И пароль можно сразу делать криптостойким, и не компрометируешь пароль при постоянных происходящих утечках и сливах, т.к. на каждом сайте пароль уникален. И не надо ставить расширения непонятного происхождения, доверяя им самое ценное.

@HepoH
09.04.2025 18:57 UTC
+1

Что делать если нужно авторизоваться в приложении с телефона?

@Metotron0
09.04.2025 19:09 UTC
-1

Достать пароль из браузера (автор пишет, что есть копирование в буфер), отправить себе через условный телеграм, добавив для пущей надёжности какие-нибудь символы в середине, такие, чтобы по виду было не ясно, где именно добавили.

10.04.2025 02:45 UTC
+9

Вот это вот знакомое холодеющее чувство, когда открываешь свой текстовый файлик с ключами к криптокошельку, смотришь на них, помнишь, что добавил к каждому по два символа, но не помнишь куда..

@apevzner
09.04.2025 19:03 UTC
+4

Если везде одинаковый пароль, то будет везде одинаковый хэш

Он утечет с какого-нибудь сайта и станет общедоступным в среде кибершпаны.

И еще есть такая проблема: есть сайты, которым только цифры подавай. Есть сайты, которые понимают только цифры и буквы. А есть такие, которым нужно, чтобы в пароле обязательно были и цифры, и буквы (причем маленькие и большие) и знаки препинания.

Всё равно придется как-то помнить, кому чего надо.

Поубивал бы :(

@nin-jin
09.04.2025 19:08 UTC
+1

Проще использовать base64 кодирование (btoa) - оно и спецсимвол добавит, и миксед кейс. Пример:

btoa( new Uint8Array( await crypto.subtle.digest( 'SHA-1', new Uint8Array ), 0, 4 ) )
// MjE4LDU3LDE2MywyMzg=
@Metotron0
09.04.2025 19:10 UTC
+2

Спецсимволы — это не обязательное условие. Если я правильно понимаю его работу, то они нужны когда length * 8 не делится нацело на 6.

09.04.2025 20:35 UTC
0

Хеши не кратны 6. Короче, я сделал PWA-приложение для этого, пользуйтесь: password.hyoo.ru

09.04.2025 23:24 UTC
0

Формально там еще есть + и /, но их появление не гарантировано (как и наличие и верхнего, и нижнего регистров, но это маловероятно). Однако, все хэши по степеням двойки по определению на 6 не делятся.

10.04.2025 06:32 UTC
0

Я про длину исходного текста в байтах. Оно же берёт биты и группирует по 6, да? Потому что 64 — это два в шестой степени. Соответственно, могут быть три случая: когда все биты поделились на 6, когда осталось два бита, и когда осталось четыре.

12.04.2025 18:19 UTC
0

При чем здесь степень? Она никак не влияет делимость. 2^3=8 и 8 никак на 3 не разделится, хоть тресни. Любая степень двойки не разделится на 6, поскольку это просто произведение двоек и такое число НИКОГДА не разделится на 3. Все хэши и блочные шифры ориентированы на длины блоков кратные степеням двойки. Во всяком случае я иных не знаю. В принципе, понятно почему так: необходимое быстродействие операций диктуют использовать разрядность микропроцессоров. Поэтому при кодировании хэшей в Base64 всегда будет оставаться хвост, который придется добивать паддингом из символов "=".

12.04.2025 18:37 UTC
0

Все хэши и блочные шифры ориентированы на длины блоков кратные степеням двойки.

Вообще, есть SHA-384, который разделится, но вживую я его, кажется, ни разу не видел.

13.04.2025 20:11 UTC
0

Да, он разделится. Но вряд ли его кто-то будет использовать, особенно для такой задачи, 64 символа, не считая самого имени домена - это не сказать, чтобы короткий URL.

12.04.2025 19:20 UTC
0

Ошибся. Не в байтах, а в битах, конечно. 24 бита делятся на 6 нацело.
Я показал даже скриншот такого base64, у которого не было = в конце.

@Tinkz
10.04.2025 03:23 UTC
0

лет 10 как использую lesspass

@nin-jin
10.04.2025 04:18 UTC
+3
@Q2WerProd
10.04.2025 05:00 UTC
-1

Очень крутая тема, но мне кажется что 65 символов может быть многовато, на некоторых сайтах видел устанавливают верхний порог длины пароля, необъяснимо, но факт…

Можно было бы добавить параметр длины пароля, чтобы обрезать просто

@Mad_Quaker
10.04.2025 07:00 UTC
+1

Видел ещё более занятный "баг". Когда при изменении/создании длинный пароль принимают, а вот при входе он тихо обрезается и в итоге "не подходит".

@Wolfdp
10.04.2025 05:04 UTC
+3

С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.

Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.

Ну и ещё несколько весёлых вещей:

  1. требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.

  2. пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.

  3. порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить

  4. если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)

@supercat1337
10.04.2025 05:10 UTC
-1

Тема с мастер-паролем довольно распространена. А вы какое решение предлагаете? Двухфакторку? Ее достаточно будет для получения доступа ко всем паролям?

И вообще, на каждую запись достаточно вполне полей ввода Заголовок и Содержание. В содержании можно было хранить хоть 10 паролей от разных учеток от одного ресурса с комментариями от одного ресурса.

10.04.2025 07:32 UTC
0

Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).

В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.

На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.

10.04.2025 07:44 UTC
0

(либо аппаратные ключи, но это не для обычных смертных)

В некотором смысле - для обычных. Ибо у них аппаратный ключ - это смартфон сам по себе.

@agseyn
10.04.2025 06:50 UTC
0

Интересное решение, но:

  • Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);

  • Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;

@polearnik
10.04.2025 08:31 UTC
+5

Используйте менеджеры паролей. точка. статью в мусор.

@edo1h
10.04.2025 14:27 UTC
+1

Ага, что стало с хабром? Какую-то дичь обсуждают на полном серьёзе, вместо того, чтобы сказать, что всё уже придумано, проанализировано сообществом на возможные уязвимости.

10.04.2025 20:45 UTC
0

Ну, вкинуть аргументы почему статья не очень всё же лучше. Так читающий школьник поймёт почему это плохо.

@underwit
11.04.2025 05:56 UTC
0

Давно написал для себя консольную утилиту. Просто вводим домен или кодовую фразу и получаем пароль для него. Пароль нигде не хранится, а получается из хэша секретного ключа и кодовой фразы. Так же сделал и приложение для телефона. https://github.com/underwit/hardpassword

@JobManKazakh
11.04.2025 05:57 UTC
0

А толку? Потом просто будут хэш на простые пароли подбирать