Комментарии 80
Примеры:
bytes-mail-chimp-hat
pizza-sloth-car-banana
Главное только, чтобы слова не были явно связаны между собой
Плюсы:
— Легко запомнить («шимпанзе в шляпе» легче запоминается, чем «H4v$#.!4a!3»)
— Не требует «заглавных букв, цифр, символов»
— Вводится быстрее, и шанс ошибиться меньше, чем при вводе пароля из случайных символов, где нужно постоянно нажимать shift, и есть шанс ошибиться в регистре
— Очень высокий уровень энтропии
— В отличии от паролей из «случайных букв, цифр, и символов», не вызывает желание забить на все и использовать простой пароль вроде: qwerty123
Странно что не рассказали о самом лучшем и надежном методе генерирования паролей — использование нескольких случайных слов:
Идем, скажем, на список случайных слов от EFF. В длинном списке их 7776 штуки или 12.9248… бит на слово. Чтобы набрать 128 бит энтропии нужно 10 слов. А десять случайных слов запомнить — тоже проблема.
Хорошо запоминается только грамматически правильная случайная парольная фраза. Но несмотря на целую кучу генераторов текста — я ни сумел найти ни одного, который умеет генерировать фразы с гарантированной энтропией. Всякие современные методы генерации при помощи сеток для этого, очевидно, мало подходят — там невозможно понять, насколько именно получающийся текст случайный.
а если использовать слова с грамматическими ошибками?
что-нибудь меняется при использовании пароля "шемпанзе в шляпи"?
Это становится заметно труднее запомнить. Ту часть которая "а какую именно ошибку тут сделать надо?".
Сам спользую для пароля пару «ненастоящих» русских слов, напечатанных в английской раскладке. Ненастоящих в смысле самопридуманных и слегка искаженных. Плюс первые три буквы доменного имени ресурса и любимую цифру. С экранной клавиатуры смартфона, правда, метод становится неудобным…
Есть такой опыт. :) Пароль нужно запомнить с неверным произношением "на иностранный манѣръ". Вышеуказанный пример будет звучать как "шЕмпанзе в шляпИ" (ударения показаны заглавными буквами).
p.s. По ходу написания комментария родилась мысль, что никто не запрещает указать ошибки в верхнем регистре в самом пароле.
Прямо в xkcd-ной картинке показана проблема с сознательным нарушением грамотности. Там тоже обычное слов искажали. Затруднение же не в битах энтропии, а в том, как это все потом вспомнить. Особенно для тех паролей, которыми редко пользуешься.
О том и речь. Запомнить проще, когда искажаешь ударения и фраза звучит неестественно. Заглавные буквы в моём примере — это ударения.
Теперь берем три случайных прилагательных из 512 самых частых (т.е. 9*3=27 бит) и получаем "шимпанзе в древней густой счастливой шляпе".
Гораздо читабельней, однозначно восстанавливается без перебора ошибок, если фразу помнишь и не нужно придумывать правила искажения.
Делал лабораторные по взлому, пароли а-ля «admin-123» при наличии SAM взламывались в пару минут, а вот в боевых условиях, когда потребовалось узнать забытый пароль родственницы, состоящий только из русских букв и нескольких цифр, программа трудилась часов 12. Безрезультатно.
ИМХО, безопасный пароль — это веселое словосочетание и пара цифр. + замена раз в 2 месяца.
P.S. кстати не известно «сорок тысяч» или «40 000»)))
Есть даже готовое решение с красивой графикой, которое оценивает пароль по самым современным метрикам
Не позволяя пользователю выбрать пароль из подмножества слабых, мы заставляем его задать пароль из гораздо большего множества возможных вариантов. Где тут логика?
Если бы вероятность попадания пароля в HaveIBeenPwned и zxcvbn была большая, то проблем у пользователей было бы гораздо больше
Я полагаю, оппонент намекает, что люди добровольно сливают свои пароли этим сервисам. Я, например, не поленился выкачать базу havebeenpowned, т.к. ссу отправлять им свой пароль, и даже хэш от него (они ведь простой sha1, а не scrypt/argon просят)
Чего именно вы опасаетесь? Вот мой реальный пароль от одного из аккаунтов на одном из сайтов (нет, не хабра) — 58CNTCzzL9Ls5hWZ — что вы с ним сделаете, не зная логина и собственно сайта? И это с учётом того что оставляя его здесь я рискую гораздо больше чем на каком-то сервисе который про меня знает только мой динамический IP, ОС и браузер.
А если отправить им SHA1, то на его реверс уйдут в лучшем годы работы всех устройств планеты (в нём 87 бит энтропии) — никто в здравом уме не будет этого делать не зная деталей, как минимум ценности аккаунта. Если бы это был пароль от кошелька биткоина на котором миллион биткоинов — думаю, в этом случае было бы проще меня найти и допросить альтернативными способами.
2) Конечно, если у вас действительно настолько рандомный пароль (и такая хорошая память), то можно безбоязненно посылать SHA1. Те несколько паролей, что я помню и применяю в зависимости от вшивости сайта, имеют меньшую энтропию, и подобрать их по SHA труда не составит. Самый старый (и самый простой) из моих паролей давно утёк.
Да, у меня действительно настолько рандомный пароль — я пользуюсь генератором, каждый сайт получает свой пароль и почти рандомный логин/email (только домен неизменен), так что успехов тем кто его будет пробовать.
На действительно важные сайты (банки, paypal etc) у меня к тому же 2FA, а с запоминанием всего этого проблем нет благодаря KeePass.
Просто ждём, пока накидают 10 миллионов ненайденных в базе SHA, и запускаем переборщик. Даже если ему придётся работать месяц, и он отыщет десятую часть, всё равно это будет 1 миллион новых паролей. Чем не профит?
Важно было не SHA/не SHA, а сколько бит. 20бит явно не достаточно для идентификации пароля.
В итоге перешел полностью на keepassxc. Файл синхронизирую через ядиск, защиен паролем + файл ключ на устройствах (win, linux, andr).
И для всех генерирую пароли вида:
i_óälÝgíldjâ-¸+¼np@:º.Один большой минус — на некоторых сайтах стоит дурацкая регулярка с запретом ASCII и\или спецсимволов.
P.S. Жду когда добавят в автогенератор эмодзи)
удачи вам ввести такой пароль на устройстве без copy/paste :)
На новых есть глюки, если верить 4pda.
Я про всевозможные железки, требующие ввод пароля какой-либо учётки при первоначальной инициализации, будь то Playstation, iphone или разнообразные сервера. не везде разработчики предусматривают безпарольную аутентификацию на такой случай.
А вот железка, где две аппаратных кнопки… — ввести что-то длинней 3-5 символов, уже подвиг, а бывает серийник символов на 50. И он не навсегда.
А как вы введёте в новый айфон при активации строку, которую человек выше приводил в качестве примера? i_óälÝgíldjâ-¸+¼np@:º
Ладно, в любом случае всё сводится к тому, что увеличивая алфавит парольной строки мы увеличиваем основание, а увеличивая её длину — степень сложности подбора. Другими словами эффективнее добавить лишнюю букву, чем заменять в строке "а" на "а с апокрифом" или 4 на 1/4.
Ставить разные стойкие пароли даже для десятка популярных сайтов уже проблема, если их запоминать, а завязывать всё на условный гугл и входить через него — тоже так себе затея.
Mozilla Firefox тоже так умеет. Удобно для одноразовых сайтов которые нужны, но требуют регистрации на совершение действия. Одноразовая почта + какой-то рандомно сгенерированный пароль который мне даже не интересен и voila
С точки зрения хранения пароля, нет: по скорости примерно равны, а уязвимости SHA1 на такой короткий ввод весьма ограниченного паттерна не распространяются.
SHA-256 = алгоритм хеширования, версия 2. У него больше длина 256-бит (32 байта) и немного другой алгоритм хэширования. Для конечного пользователя разница в длине хэша и в меньшем количестве коллизий в SHA-256. Если коротко то так. Подробнее в Wiki: SHA-1, SHA-256
Все символы подходящие, энтропия в норме, если забыли/потеряли пароль — можно попробовать вспомнить сид
P.S. кажется во Вселенском компьютере индексация начинается с 0 :)
Преимущество хранения хэшей вместо самих паролей заключается в том, что паролей в БД нет. И это правильно, потому что вам нужно только доказать, что вы знаете свой пароль, но сам он не имеет значения.
В плане аутентификации по паролю есть два подхода: PAP и CHAP. Так вот вы их смешали: при PAP пользовательский пароль передаётся как есть, а в БД хранится хэш для сверки. А вот при CHAP как раз пользователь передаёт лишь признак знания пароля, но на стороне сервиса он должен хранится в обратимом виде.
Взлом пароля — это когда злоумышленник пытается обратить вспять хэш-функцию и восстановить пароль из хэша.
Не совсем так: обращение вспять хэш-функции — частный случай взлома пароля.
Отнюдь, гораздо вероятнее произошла коллизия. Если мы все пароли приводим к хешу определенной длинны, то стойкость пароля ограничена размером хеша.
На самом деле золотой пули нет, так рандомные генераторы совсем не рандомные по факту и их не так много (вспоминаю пионерский лагерь, где моя система случайно каждый день проигрывала одинаково случайные песни из большой базы). Злоумышленники уже нагенерили хешей из всех генераторов в таблички и в общем случае, все равно какую длину выбрал пользователь. Это мы еще не берем специально распространяемые «генераторы самых сильных паролей» и генераторов с «онлайн проверкой пароля на уникальность».
«Хранители паролей» это складывание яиц в одну корзину, к тому же часто не свою…
Все «мнемотехники» это сразу нестойко, притом сильно нестойко.
Биометрию сложно сменить в случае утечки.
Я бы копал в сторону центров выдачи ЭЦП с возможностью отозвать + пропускать через биометрию. Какой нибудь IRIS-сканер с пин-кодом и смарт-картой содержащей ЭЦП. То есть мы имеем три составляющие, одна жестко привязывает к человеку, другая обеспечивает возможность сменить пароль в случае утечки, третья (пин-код) служит признаком добровольности и обеспечивает отзыв ЭЦП в случае серии подбора или ввода тревожного кода.
Причём риск в данном случае ещё выше, т.к. с такой структурой сразу понятно к кому идти и утечка базового сертификата гораздо страшнее, чем взлом любого сайта или менеджера паролей, которые, если нормальные, не видят данные своих клиентов, т.к. они зашифрованы.
Я уже не говорю что в такой структуре можно выпустить «дубликат» кредов через «дружественный» центр.
у тинькова у меня логин и пароль случайные строки по 25 символов.
раньше это мог ок.ру, но там теперь и номер телефона работает.
Вот тут, как раз и защищает вас та часть, которую придумываете сами.
Моя демка для генерации собственной карточки sansys.github.io/cryptocard
Все преимущество — что электроники нет. В современных условиях лучше купить самый дешевый (можно даже БУ) китайский смарт, поставить на него CryptoPass, вбить мастер-пароль и генерировать пароли для сайтов в нем.
Смарт, разумеется, после инициализации никогда ни к какой сети больше не подключается.
Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?
Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты?
есть ли драйвер для смартфона чтобы прикинуться клавиатурой
Я тоже искал. Сам по себе Linux эмулировать HID умеет. Но в том же андроиде это умение с самых ранних версий выключено. Правда, когда Android Pie был на стадии слухов — были статьи, что HID эмуляция таки будет. Но ее, похоже, так и не включили.
Причем выключено, как я подозреваю, именно по соображениям безопасности — чтобы нельзя было смарт к компу подключить и быстро набрать зловредный payload через командную строку.
А так проекты с пропатченными ядрами были, но успешно заглохли. Видимо, легче на микроконтроллерах что-нибудь собрать, чем ядро коммерчески доступных смартов патчить.
Далее, как бакапить такие пароли? А то китайский смарт умер, дальше что?
В описываемой схеме бакапить надо только мастер-пароль. Который ты сам и вводишь. Т.е. бакап пароля производится до того как он в смарт попадет. Само же устройстово ничего уникального не генерит и не запоминает — в этом отличие от традиционных менеджеров паролей и это же позволяет держать устройство в вечном оффлайне.
криптостойкости сгенерированных сторонним приложением паролей (кто гарантирует вам генерацию уникальных паролей, а не выборку из 100000 паролей которые выглядят вполне случайно).
PBKDF2 вроде бы это и гарантирует.
Как обеспечить невозможность восстановления пароля путем социнженерии, взлома почты и смены симкарты
Никак. Это за пределами обсуждения. Если сервис позволяет по почте и телефону пароль сбросить и восстановить — то этот риск от способа хранения и генерации пароля не зависит.
Вот собственно о чем я и говорю, криптостойкие пароли защищают только от скачивание хакерами базы хешей паролей. От простого подбора паролей достаточно защищает обычный 8 символьный пароль, самое главное чтобы он был не словарный и не был одинаковым на разных сайтах.
Ввода криптостойкого пароля сложен, автоматизированные средства его ввода сразу понижают безопасность.
Есть убунтофоны всякие, да собственно зачем этому устройству быть вообще телефоном то?
Потому что легко найти уже ненужный и дешевый. Т.е. с большой вероятностью покупать не надо — уже где-нибудь на полках валяется. А так, конечно, можно и на более простой железке делать.
Возможно я не понял вашу схему, что происходит при вводе мастер-пароля?
Запоминается приложением. Если очень параноить — то не запоминается, а каждый раз вводится заново.
Если мы бакапим только его, то где хранятся сами пароли?
Нигде. Они каждый раз генерируются из мастер пароля и прямо тут же введенного имени учетной записи. (Собственно, все это написано в описании CryptoPass, которым я предлагал заменить qwertycards, которые делают похожее, но ручным алгоритмом):
password = base64(pbkdf2(secret, username@url))PBKDF2 это стандарт, метод генерации паролей. Как проверить его корректную реализацию?
Ссылка CryptoPass была на f-droid. Что означает что исходники доступны. Возможно, что PBKDF2 прямо в этих исходниках нет, но тогда реализация системная и ищется в исходниках андроида или используемой библиотеки.
Какова оптимальная длина пароля?