Комментарии 38
Насчёт домена в качестве соли: сайты иногда переезжают на новый домен, или имеют несколько доменов в разных зонах (.com, .ru)
Это следует учесть
Добавить еще несколько тысяч итераций, чтобы замедлить брутфорс для тех, кто в курсе вашего скрипта, сделать длину пароля настраиваемой, изобрести заново какой-нибудь PBKDF2 или лучше Argon2, и будет норм.
Этот велосипед изобретают постоянно.
Раз (у него даже вариант в виде браузерного расширения есть)
Какие именно (уже изобретенные) стандарты используются - в описаниях по ссылкам.
Но проблема вот в чем - просто хэш не получается. Очень быстро выясняется, что нужно хранить особенности. И получаем базу данных, по сценариям использования ничем не отличающуюся от такой же у менеджера паролей. И смысл тогда? Боимся, что используемую для шифрования этой базы криптографию сломают?
Не все сайты позволяют использовать пароли длиной 65 символов, к сожалению.
Correct horse battery staple.
Вы всё еще пользуетесь одинаковым паролем на всех сайтах в интернете? Я думал, с появлением встроенных в браузер менеджеров паролей эти времена давно прошли. И пароль можно сразу делать криптостойким, и не компрометируешь пароль при постоянных происходящих утечках и сливах, т.к. на каждом сайте пароль уникален. И не надо ставить расширения непонятного происхождения, доверяя им самое ценное.
Что делать если нужно авторизоваться в приложении с телефона?
Если везде одинаковый пароль, то будет везде одинаковый хэш
Он утечет с какого-нибудь сайта и станет общедоступным в среде кибершпаны.
И еще есть такая проблема: есть сайты, которым только цифры подавай. Есть сайты, которые понимают только цифры и буквы. А есть такие, которым нужно, чтобы в пароле обязательно были и цифры, и буквы (причем маленькие и большие) и знаки препинания.
Всё равно придется как-то помнить, кому чего надо.
Поубивал бы :(
Проще использовать base64 кодирование (btoa) - оно и спецсимвол добавит, и миксед кейс. Пример:
btoa( new Uint8Array( await crypto.subtle.digest( 'SHA-1', new Uint8Array ), 0, 4 ) )
// MjE4LDU3LDE2MywyMzg=
Спецсимволы — это не обязательное условие. Если я правильно понимаю его работу, то они нужны когда length * 8 не делится нацело на 6.
Хеши не кратны 6. Короче, я сделал PWA-приложение для этого, пользуйтесь: password.hyoo.ru
Формально там еще есть + и /, но их появление не гарантировано (как и наличие и верхнего, и нижнего регистров, но это маловероятно). Однако, все хэши по степеням двойки по определению на 6 не делятся.
Я про длину исходного текста в байтах. Оно же берёт биты и группирует по 6, да? Потому что 64 — это два в шестой степени. Соответственно, могут быть три случая: когда все биты поделились на 6, когда осталось два бита, и когда осталось четыре.
При чем здесь степень? Она никак не влияет делимость. 2^3=8 и 8 никак на 3 не разделится, хоть тресни. Любая степень двойки не разделится на 6, поскольку это просто произведение двоек и такое число НИКОГДА не разделится на 3. Все хэши и блочные шифры ориентированы на длины блоков кратные степеням двойки. Во всяком случае я иных не знаю. В принципе, понятно почему так: необходимое быстродействие операций диктуют использовать разрядность микропроцессоров. Поэтому при кодировании хэшей в Base64 всегда будет оставаться хвост, который придется добивать паддингом из символов "=".
Все хэши и блочные шифры ориентированы на длины блоков кратные степеням двойки.
Вообще, есть SHA-384, который разделится, но вживую я его, кажется, ни разу не видел.
Ошибся. Не в байтах, а в битах, конечно. 24 бита делятся на 6 нацело.
Я показал даже скриншот такого base64, у которого не было = в конце.
лет 10 как использую lesspass
Очень крутая тема, но мне кажется что 65 символов может быть многовато, на некоторых сайтах видел устанавливают верхний порог длины пароля, необъяснимо, но факт…
Можно было бы добавить параметр длины пароля, чтобы обрезать просто
С точки зрения безопасности это конечно никуда не годиться: просто подсматриваем один пароль и зная алгоритм получаем ВСЮ базу паролей пользователя. Т.е. грубо говоря сидим в кафешке с ноутом и нам понадобилось перелогинится на сайте любителей домашних ежей. Сайт не критичен, мы не боимся что нашу учётку на нём угонят поэтому не шибко смотрим по сторонам и тем более на верх. А наверху камера и скучающий охранник уже пробивает на каких сайтах без двойной авторизации сидит данный пользователь.
Поэтому как личная фича может и жизнеспособно, но как массовый стандарт -- точно нет.
Ну и ещё несколько весёлых вещей:
требования к паролю (спецсимволы, регистр). Можно конечно задать алгоритм построения предусматривающий и это, но всегда найдется тот самый упоротый ресурс, на котором ваш алгоритм не будет работать.
пароль взломали на сайте А из-за админов (например профукали базу) и вас просят его поменять. Теперь вам нужно помнить что на сайте А у вас другой пароль.
порой пароль задаёте не вы, а вам выдают случайный и нужно только запомнить
если требуется несколько учётных записей на один ресурс -- у всех будет один и тот же пароль? Тоже не всегда хорошо (допустим мне нужно завести 10 учёток, и при этом расшарить доступ к каждой отдельному человеку, которые не должны пересекаться по доступу)
Тема с мастер-паролем довольно распространена. А вы какое решение предлагаете? Двухфакторку? Ее достаточно будет для получения доступа ко всем паролям?
И вообще, на каждую запись достаточно вполне полей ввода Заголовок и Содержание. В содержании можно было хранить хоть 10 паролей от разных учеток от одного ресурса с комментариями от одного ресурса.
Мастер пароль в обычных менеджерах ставится на список этих самых паролей. Т.е. чтобы получить список паролей нам нужно знать и мастер пароль, и иметь зашифрованный список на руках. Тут ноль вопросов и безопасней только хранить в своей голове (либо аппаратные ключи, но это не для обычных смертных).
В предлагаемом решении нам нужно знать только пароль (алгоритм в криптографии всегда считается известен), по которому будем подбирать доступ к интересующим сайтам. А, ну и логин/почту, но это зачастую открытая инфа.
На всякий подчеркну ещё раз что всё это "не очень" именно как массовое решение, к которому будут проявлять интерес условные хакеры. Чисто для себя побаловаться -- норм.
Интересное решение, но:
Зачем когда есть менеджеры паролей, причем некоторые из них с аатозаполнением и гибким генератором паролей? (Бесплатный - KeePassXC, Платный - Roboform, про корп.сегмент даже говорить нет смысла, поскольку имеется несколько десятков продуктов со схожим и даже большим функционалом, на любой вкус, цвет и потребности);
Использовать на двух и более сайтов один и тот же пароль, хеш или иные производные - априори не безопасная идея;
Используйте менеджеры паролей. точка. статью в мусор.
Давно написал для себя консольную утилиту. Просто вводим домен или кодовую фразу и получаем пароль для него. Пароль нигде не хранится, а получается из хэша секретного ключа и кодовой фразы. Так же сделал и приложение для телефона. https://github.com/underwit/hardpassword
А толку? Потом просто будут хэш на простые пароли подбирать
Легкий способ преобразовать запоминаемый пароль в 65-символьный хэш для защиты ваших аккаунтов