Как стать автором
Обновить

Комментарии 103

То есть открытым кроссплатформенным оффлайновым парольным менеджерам с шифрованием файла базы мастер-паролем доверять нельзя, а неизвестному сайту с закрытыми исходниками, который зачем-то выполняет расшифровку не джаваскриптами на фронтенде, а на потенциально уязвимом бэкенде, — можно?
Идея кажется была в том, что каждый может такое сам себе написать за час-два.
Это получается самописный менеджер паролей с собственным шифрованием. Разворачивать самостоятельно изобретённую криптографию не для теста — большой технический грех.

Лично я не вижу проблемы, которую такое решает.
Я так понял предлагается делать что-то вроде ssh2(мойпароль+соль).
Никаких своих изобретений тут не требуется.
И идея автора в том, что проще написать реализацию вот этого-вот самому и за час, чем тратить гораздо большее время на изучение кода открытых менеджеров паролей и самостоятельной их сборки из этих кодов.
Непонятно, правда, зачем для этого понадобилась целая статья.
Прошу заметить, что статья — это громко сказано. В защиту заметки могу только вольно процитировать Фейнмана "… мы не знаем, где хорошая идея нас поджидает...". Вдруг кому поможет зацепить идею.
не ssh2, а sha2

Может это шутка такая?

Если есть возможность, то можете развернуть идею об уязвимости?
  • Если речь идёт про использование чужого сайта, то я не понимаю, почему я ему должен доверять: он может сохранять мои самые чувствительные данные — пароли. Даже без регистрации данные можно сопоставить.
  • Если речь идёт о создании собственного, то вместо оффайнового менеджера паролей появляется необходимость разворачивать клиент-серверную архитектуру, следить за версиями ПО (веб-сервер, виртуализация, SSL, и т. д.), беспокоиться о том, что натворит хостер.
  • Если такой сайт для расшифровки паролей разворачивать на локалхосте, то это ничем не отличается от обычного оффлайнового менеджера паролей. Тогда уж лучше писать его с нуля.
1. да, может. именно по этому в статье есть место про написание собственного на собственном сервере, как это реализовано у меня.
2. нет такой острой необходимости из-за простоты. у меня в сумме это заняло 2 часа, 2 файла (php-логика, html-шаблон) и менее 1 тыс. знаков (а я не близок к программированию на php). Работает в любой системе с c php-интерпретатором, от 5.3 до 7.2.
3. Бинго! Про это и идет речь в заметке.
Вау, хэширование и «посолка» пароля, никогда такого не было и вот опять :)
Да, было дело. Мне кажется каждый такой «создавал».

У меня было так(хоть опенсорс): my_passwords и то с JS, который в оффлайн можно(и да, знаю что там GET и это так себе). И то потом понял что это все жесть и не надо, так как:
  1. Если кто-то ломает мастер-пароль, то всем хана
  2. Компрометация алгоритма — печалька
  3. Смена мастер-пароля через боль
  4. И т. д.
Компрометация алгоритма — печалька


А почему? Мой алгоритм: ssh2(мастерпароль + соль).
В чем проблема, если его скомпрометировали?
Можете подсказать объем работы по раскрытию мастер-пароля при условии, что хэш-пароли увели допустим не с одного, а с трех ресурсов?
Про раскрытие алгоритма — раньше ответили.
Смена мастер-пароля аналогична смене хэш-пароля с фиксацией действий в открытой (относительно) базе (понятно, что без фиксации нового мастер-пароля).
Keepass(ios/android/mac/win) + мастер пароль на файл базы + файл базы в Dropbox (те же платформы), полностью решает все вопросы доступа для меня.
НЛО прилетело и опубликовало эту надпись здесь
Да точно :) забыл про «X».
Есть ещё более новый форк — KeePassXC, там добавили некоторые нехватавшие фичи, реализуемые в оригинале плагинами, вроде встроенного генератора TOTP и скачивания кастомных значков.
Интересно, я увижу здесь коммент про ещё более новый форк KeePassXCV?
Не спорю. Я конечно не Джоли и голых фоток в дропбоксе нет… но паранойю не победить.
Ну уведут у вас шифрованную базу, и что?
Подберут пароль перебором например.

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

Подберут пароль перебором например.

Ну да, если мастер-пароль «123». Иначе упарятся.
Проблема ещё и в том, что на разных сайтах разные требования к паролям

Где-то нельзя спецсимволы, где-то нужно иметь большие, маленькие буквы, спецсимволы да ещё и буквы на конкретном языке

Так что пароль не совсем универсальный будет
Из трёх моих онлайн-банкингов один ограничивает длину пароля 10ю симоволами (НЕ БОЛЕЕ! И ЭТО БАНКИНГ!), второй — _только_ цифры можно.
Третий правда, требует большую букву+маленькую+цифру+спецсимовол, но не очень понятно зачем это, если любой телодвижение в нём (даже логин, и отключить нельзя) нужно подтверждать кодом из SMS.
В файле с комментариями — измененное правило. Например «читать 10 символов со второго».
Криптография способна решить гораздо больше проблем, чем многие думают. Оффлайн-хранилище с мастер-паролем и key-файлом куда надёжнее подобных алгоритмов.
Хранлище, которое всегда с собой? Хорошо работает в Люберцах, правда не всегда у тебя. Ну так, к слову…
Чем плохо хранилище, которое всегда с собой?
У меня одно время, когда я учился на монолыже кататься, телефоны менялись раз в неделю. 4 штуки поменял. Никто не отменял сплавы, корпоративы и банальную невнимательность. Опять же, я не настаиваю на таком методе, если у Вас все хорошо с хранением Хранилищ. Повторюсь, что писал сервис для себя и с учетом своих особенностей жизни и ее восприятия.
А вы в курсе, что файлы можно копировать?))
Да, в курсе. а еще синхронизировать, актуализировать, не терять, не забывать где лежит… Этим онлайн-сервис в выгодную сторону отличается от локального хранилища. В целом понятно, что я преувеличиваю проблему.
В заметке и ответах я делился собственным опытом. Это не значит, что мой опыт единственно верный и нет других вариантов. Для меня плюсы моего подхода перевешивают его минусы, о которых я тоже в курсе.
Обработка на сервере и блокнот — слабые места. Давайте попробуем от них избавиться. Всё для чего вам нужна вычислительная помощь — хеш. Вам достаточно помнить секретную фразу и простой алгоритм, по которому генерируется пароль для хеширования.

Скажем, ваше секретная фраза: «A3sd!aOfcJ-», ресурс: habrahabr.ru, логин: acyp. И, например, вы придумали такой единый алгоритм для пароля: 1 часть секретной фразы + логин в обратном порядке + 2 часть секретной фразы + ресурс записанный капсом через 1 символ, вместо точек пробелы. Что угодно придумать можно.

Получается: A3sd!pycaaOfcJ-hAbRaHaBr rU

Перед применением прогоняете через md5 с заменой, нескольких знаков на дополнительные, например, как у вас двух символов на +F

Таким образом вы зависите только от функции хеширования, для которой вам даже не нужен интернет, а все секреты хранятся только в вашей голове.

Правда есть такая проблема — смена домена ресурса.
Собственно именно так я и делал, пока не пришлось менять пароль к одному из ресурсов (хакнули базу, на всякий пожарный поменял).
Ну так пароли в принципе стоит иногда менять, можно было и везде сменить)
В моем случае надо менять не пароль, а его хэш, полученный по определенным правилам. И только на одном ресурсе.
Ну так пароли в принципе стоит иногда менять

На самом деле нет, если пароль надежный и ты на сто процентов уверен, что он не был скомпрометирован.
Кстати, еще проблема есть: я не умею md5 «в уме» решать, а значит придется писать приложение на тот ресурс, который «под руками». И в случае утраты последнего находить новый ресурс (желательно аналогичный, что бы сократить время на написание нового приложения).
md5 и не надо решать в уме, если вам срочно нужна авторизация с устройства где нет приложения для вычисления, то можно вычислить онлайн. Если не доверяете сторонним сервисам, то выделить под это собственную страничку где вычисление md5 будет на клиенте. Смысл в том, чтобы если не во всех, то в подавляющем большинстве случаев иметь при себе, в голове, всё необходимое для вычисления пароля и не передавать для этого ничего на какой либо сервер.

Кстати, какой у вас запасной вариант, на случай, если нет блокнота с записями и/или ваш сервис вычисления пароля недоступен?
1. Блокнота у меня до сих пор нет. Это решение для самых ленивых.
2. Сервис продублирован.
Ну вы писали «И вести такой список просто в блокноте», а как авторизоваться, если списка нет под рукой?

Мне не нравятся локальные базы за то же самое, в критической ситуации, когда доступа к хранилищу нет, остаешься без доступа к учёткам, хочется повышать автономность, а не привязываться к файлам и конкретным сервисам.
Собсно я уже ранее писал, что можно завести Единое Правило, можно вести блокнот, можно совместить оба подхода. Все зависит от индивидуальных особенностей конкретного человека и количества ресурсов. В моем случае мне хватает Правила, ибо пароли я поменял только на двух ресурсах и уже привык на них модификатор вводить с версионником.
собственную страничку где вычисление md5 будет на клиенте

В целом идея как раз в этом и состоит. В моем случае все происходит на сервере из-за низкой квалификации как веб-программиста. Но меня это не смущает, т.к. на сам метод влияния не оказывает.
где-то в комментарих есть ссылка на сервис с гитхаба (с исходниками), где все происходит действительно на клиенте и красиво оформлено.
Да, мне еще любопытно, в общих чертах, что у вас происходит в PHP? Вы говорите о двух часах на реализацию, значит там не просто хеширование, а еще какие то преобразования. Тогда, если сервисы и исходники будут утеряны, а алгоритм преобразований не удастся восстановить по памяти, то будут утеряны и сами пароли.

Что касается квалификации как веб-программиста, то она не требуется, для простого хеширования. Понадобятся лишь пара запросов в гугл и немного времени.
Так я и написал, что примерно пара часов. Преобразования в чем-то похожие на cram-md5.
apt get install pass || yum install pass || brew install pass && man pass
Enjoy. Сделано для себя :)
Проблемы начинаются, когда сайт недоступен. Но вы можете скопировать код генерации — там джаваскрипт. На сервер ничего не передаётся, но параноики могут отключать интернет на время ввода пароля и генерации.
Ресурс — это хабрахабр, ревизия — чиселка для смены паролей.
На входе логин-пароль ввести один раз любые, дальше они станут вашими логином-паролем. Этот пароль ничего не защищает, только разграничивает ресурсы разных людей.
Ну и да, аудит безопасности был бы интересен :)
надо было делать консольную утилиту и GUI вариант для винды в вебе на чужом сервере не нужно
не понял из статьи, чем плохи менеджеры паролей и рандомные пароли на 20+ символов
Возможно удивлю, но я не пытался рассказать о недостатках существующих парольных менеджеров. Скорее, заметкой я хотел показать некий пласт возможностей для параноиков.
chriszarate.github.io/supergenpass
SuperGenPass использует хэш-алгоритм для преобразования мастер-пароля в уникальные сложные пароли для веб-сайтов, которые вы посещаете. Работает как букмарклет (раньше легко можно было настроить под свой пароль и требования к длине). Тоже по мастер паролю+адресу генерирует пароль.
Да, абсолютно похожее по духу, но более функциональное и профессиональное решение. Можно, применяя предложенную мной методологию, создавать хэш-пароли на основе мастера.
Можно пользоваться готовым решением или поднять свое на своих серверах.Значит я таки не одинок в стремлении не хранить, но генерировать пароли на основе мастера.
НЛО прилетело и опубликовало эту надпись здесь
В легкости реализации и сложности раскрытия весь смысл идеи и заключается.

Для подобной цели пользовался otp-md5. На линуксах обычно есть из коробки или типа того (соответсвенно, если не доверяете утилите — не доверяете и всей системе), на андроид ставится прога с минимальными permissions.


Главное — алгоритм стандартный.

Использую базу KeePass не только для хранения паролей, но и для каталогизации ресурсов, где у меня есть какие-то учетки. Это сотни записей, удержать все в уме просто невозможно.
В настройках базы указано несколько миллионов итераций хеширования, что делает открытие самой базы довольно долгим (несколько секунд), что абсолютно не критично для использования, но сведет на нет любые попытки брутфорса.
Не понимаю, для чего люди пытаются изобрести велосипед или вообще все удержать в голове.
сведет на нет любые попытки брутфорса
Ждать несколько секунд — хорошо, но что насчёт ASIC/GPU-устойчивости алгоритма AES-KDF? Было бы логичнее перейти на Argon2, который есть в формате KDBX4. С другой стороны, такое поддерживается не всеми открывалками баз KeePass.
Пожалуй, действительно стоит перейти на вторую версию программы, спасибо. Там помимо этого, оказывается, еще полезностей добавили, вроде автонабора.
сведет на нет любые попытки брутфорса

Брутфорс базы кипаса?
Брутфорс пароля к веб-ресурсу?


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


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


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


Только вот восстанавливаемость пароля у метода, предложенного в посте, выше, чем у кипаса — удалите свою базу, и все. А в случае формулы "ресурс + логин + фраза + хеш-функция" любой пароль может быть вами восстановлен, даже если вы очнулись без своего кипаса в ванне со льдом, без почки и без телефона.


В пользу "кипасов" работает только юзабилити. И да, ее для обывателей более чем достаточно. Все встроенное шифрование — сюр для защиты совести.

Брутфорс базы кипаса?
Брутфорс пароля к веб-ресурсу?

Базы, конечно же. Разве кто то брутит web-ресурсы? Сегодня это несколько неактуально.

Во-вторых, если у вас сперли базу, значит, у кого-то есть доступ до вашего носителя данных.

Утечка базы не является проблемой, при использовании сильного мастер-пароля.

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

На каждом ресурсе сгенерированный рандомом уникальный пароль.

удалите свою базу, и все.

База хранится в нескольких местах локально + на облачном сервисе.
Утечка базы не является проблемой, при использовании сильного мастер-пароля.

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


Перечитайте комментарий еще раз) Вот очнулись вы в ванне со льдом и без почки. Пароль от облака с базой с паролями у вас тоже в базе с паролями в облаке?


Тут мы приходим к исключениям. Исключения порождают дыры в безопасности, а облака порождают историю версий базы, что порождает кучу интересных векторов атак.


Я говорю о том, чего у всяких "кипасов" нет — независимой восстанавливаемости.
И да, восстановление пароля от облака по SMS/E-mail тоже сводит на ноль всякую пользу от "кипасов", особенно учитывая низкую защиту первого мобильного фактора.

потому что это значит, что у вас слили не только базу, но и весь жесткий диск

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

Вот очнулись вы в ванне со льдом и без почки. Пароль от облака с базой с паролями у вас тоже в базе с паролями в облаке?

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

В чем тогда смысл шифровать базу?


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


То, о чем вы говорите, имеет смысл лишь в корпоративных сетях, где сетевой доступ между системными администраторами допустим, а пассшеринг — нет.


В домашней экосистеме — сюр для защиты совести.

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

Я вполне допускаю, что могу потерять ноутбук/телефон с базой, меня могут ограбить или забрать компьютер силой для изучения, доступ к облаку могут получить левые люди/спецслужбы.
Но вы вполне можете использовать, например, текстовый файл, или excel таблицу, для хранения паролей, некоторые так и делают. А можете помнить все в уме, если вам так удобно, почему бы и нет? Я же вас ни к чему не призываю и не навязываю своего мнения, просто описал, как оно у меня.

Хорошо, золотая рыбка, раз уж такое через 4 часа, то 10 лет комы даже мастер-пароль не переживет, и правда. Напоминаю, ваш посыл был:


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

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


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


В сухом остатке имеем: зашифрованную базу, которую можно украсть, и алгоритм+ключ, который даже украсть нельзя. При всех равных рисках, связанных с терморектальным брутфорсом всякие "кипасы" выигрывают только в юзабилити, где термин "юзабилити" рядом с ИБ даже не пробегал.

Доводы и аргументы именно к этой фразе я написал выше, объяснив практически «на пальцах» бессмысленность всяких «кипасов»

Ну, я ваше субъективное мнение услышал. Не понимаю только, зачем вы мне его так активно-агрессивно навязываете. Если конкретно вам удобнее держать все в голове, да ради Бога, кому-то удобно делать это с помощью мастера паролей, кому-то записывать на листочек. У кого-то и вовсе один пароль на все.

Вы комментарий к топику в стиле "а я использую -ххх- и мне норм" оставили ради пука в воду, и отвечать на него не нужно, выискивая полезный смысл?


Вот, пытаюсь понять, может, какое-то личное исследование/сравнение было скрыто за этим. Не может же просто так быть комментарий про "а я использую вот это" на хабре. Тем более в противовес решению, предложенному автором темы.

Прошу прощения.


Миф про 3 минуты памяти у золотой рыбки был опровергнут. В начале этого года ученые из Израиля представили доказательства того, что рыбка может вспомнить события 4-5 месячной давности.
Я говорил о том, что вариант «базу слили» даже не рассматривается, потому что это значит, что у вас слили не только базу, но и весь жесткий диск, а может, даже подложили чего «в нагрузку» обратно.

А как вам вариант «база в открытом доступе»? И этот вариант вполне работает.
База раскидана по устройствам, флешкам (которые и через чужие руки ходят), лежит в облаке с публичным доступом.

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


Метод, предложенный автором поста, позволяет. А всякие "кипасы" — нет.

Боюсь, после 10 лет комы можно не вспомнить и сервисы, где ты был зарегистрирован (тем более, если их сотни), не только, что алгоритм, по которому к этому сервису был составлен пароль.
Метод, предложенный автором поста, позволяет. А всякие «кипасы» — нет.
Всё с точностью до наоборот: через 10 лет вы не вспомните все эти хитроумные правила составления паролей, а один пароль, введённый не одну тысячу раз — вполне.
Я и сейчас то не помню, был зарегистрирован на сервисе или так, мимо проходил. Приходится, при необходимости, открывать кипасс и смотреть.
Зачем их вспоминать, если есть не секретный журнал с ресурсами и модификаторами? Который так же можно написать на примитивном php.

Так как все тут пишут…
есть длинный, очень длинный пароль, есть keepassx на 70 миллионов. Все под debian.
А все прочие пароли — через генератор keepassx.

Пока коллеги по форуму выше меряются своими кипасами и не умеют Шнайера, спешу выразить поддержку.


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


И пусть народ с пароль-генераторами считает себя лучше всех, но после потери хранилища, кражи ноутбука в багаже при перелете или еще какой напасти — формула "ресурс + логин + запоминаемая фраза + хеш-функция" выглядит куда надежнее, потому что последние два компонента восстановимы строго автором, и подбору не подлежат, а результат достаточно стойкий и не имеет необходимости быть где-либо сохраненным, чтобы не волноваться за него.

На самом деле формула получилась немножко другая, типа «хеш(запоминаемая фраза + ресурс + логин + случайная хранимая фраза)» и поэтому все равно требуется вести журнал и быть к нему привязанным (из-за наличия случайной хранимой фразы в формуле). Ну а в сумме привязка получается к 3 вещам: журнал, сервис, память.

Вариант без хранения какой то доп инфы не универсален, автор, вполне обосновано, приводит пример с необходимостью смены пароля на каком либо ресурсе на новый, что проблемно обеспечить без хранения какой то информации.

Боже ж мой, зачем такие сложности? Удобства никакого, а дыр хватает. Проще придумывать длинные фразы, связанные с ресурсом типа "форумтехногиков#датасоздания".

Можете про «дыры» чуть более развернуто?
Про длинные фразы: Допустим пришла необходимость поменять пароль? Или на трех ресурсах подряд базы паролей были слиты, при том, что в плейн-тексте хранились. А еще на трех ресурсах дата создания аккаунта публично доступна. В последней ситуации негодяи получают в руки систему формирования пароля и возможность экстраполировать на иные ресурсы. Такая ситуация у меня не возможна.

Попробуйте использовать комбинации разных алгоритмов хеширования.
И в качестве соли — ник.
Тогда все, что вам нужно помнить, эту самую комбинацию.


Довольно примитивный пример:
md5( md5("habrahabr.ru") + md5("acyp") )


Чуть сложнее:
md5( base64( md5( md5("habrahabr.ru") + md5("acyp") ) ) )

Мне кажется Вы усложняете. Проще вести учет модификаторов, чем правил, мне так кажется. Или я Вас просто не понял.
С модификаторами вам нужно вести учет.
С этим алгоритмом достаточно будет помнить только цепочку преобразований.

У вас будет одна цепочка для всех сайтов.
md5( base64( md5( md5(«habrahabr.ru») + md5(«acyp») ) ) )
md5( base64( md5( md5(«geektimes.ru») + md5(«acyp») ) ) )

Все, что нужно помнить:
md5( base64( md5( md5(домен) + md5(логин) ) ) )
А как подобрать цепочку под конкретный ресурс? Если цепочка одна на все ресурсы, то ничем от предложенной методологии не отличается. Или придется хранить вид цепочки для конкретного ресурса.
Может простейшую блок-схему нарисуете (в текстовом виде, например) как вы себе представляете механизм работы? (что-то типа краткой инструкции по использованию)
В статье вы не упомянули алгоритм хеширования.
Мой метод ничем, не отличается, кроме того, что ничего не нужно нигде хранить.
Метод предложенный в статье подразумевает хранение модификаторов.

Все, что нужно, придумать алгоритм хеширования, запомнить его и с его помощью генерировать пароли(хеши) для сайтов.

Вы придумываете себе алгоритм, к примеру…

md5( md5 ( domain ) + md5 ( login ) )

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

НЛО прилетело и опубликовало эту надпись здесь
Чуть больше конкретики возможно добавить в слабо информативный коммент? В идеале — без перехода на ярлыки и личности.
И вести такой список просто в блокноте.
Я правильно понял, что некий список в блокноте всё же ведётся? Тогда какого икса там не ведётся обычный список паролей?
Если паранойя — заводим бумажный носитель и сохраняем туда, постоянно носим при себе. Боитесь физического доступа постороннего человека к своему бумажному носителю? Да кому Вы так нужны-то? Ваши аккаунты взломают другими методами. А физическое воздействие быстрее и дешевле применить непосредственно к хозяину носителя.
Потому что даже зная адреса ресурсов, логины и модификаторы — пользы 0.
Идея правильная, жаль, что внимание у большинства заострено на других аспектах проблемы — как реализовать, как зашифровать, как сохранить с помощью суперпуперкрэйзиметодов. У автора всё прозрачно и понятно. 1.Используйте длинный пароль. 2. Соблюдайте правила генерации сложных паролей. 3. Храните реквизиты доступа так, чтобы вы всегда могли до них легко дотянуться, но при этом не кладите все яйца в одну корзину. 4. Чтобы не запутаться, разделите функционал управления реквизитами доступа максимально: что можно запомнить и не забыть — запоминайте, что можно записать и сохранить на бумаге — то запишите и храните на бумаге, что можно запомнить в облаке — то в облаке, а связку между всем этим не поленитесь создать простую и удобную и доступную отовсюду.
Вот и вся «сложность». Спасибо автору! Заставляет думать, прежде чем делать
Никогда не пользовался менеджерами паролей.
Все что нужно — придумать и запомнить правило формирования пароля.
Например: Abc + домен + ;%: + 789
Таким образом для каждого сайта свой пароль и ты всегда его помнишь.
Повторюсь: если сольют три ресурса подряд с открытым методом хранения пароля (а такие еще есть, можете поверить, примеров приводить не буду), то Ваша система станет очевидной.
Любая система при ряде условий становится очевидной.
Ничего не мешает усложнить правило, чтобы та самая очевидность не было столь явной.
ff7906dd376589a8c2cf1e3877a7e0+F
8eab281b04fefb92865b045be1a294+F
2297a9b1872acce05734a0c5b9bdec+F
Это реальные хэш-пароли на базе мастер-пароля и модификатора (использовано только Правило, без дополнений). Это то, что увидят какеры, даже если ресурсы хранят мои пароли там плейн-текстом. Правило простое — имя ресурса.
Что из этого смогут надоить негодяи?
Я крайне ясно выразился, написав: «Любая система при ряде условий становится очевидной.» и это факт.
Не вижу смысла рассуждать над вашим примером и выяснять достаточно ли приведенных условий либо нет.
Приведенный мной пример системы паролей, меня устраивает и позволяет не быть параноиком, поскольку вероятность слива есть всегда.
Приведенный вами пример системы — полная фигня, поскольку ничем не лучше чем использовать 1 пароль для всех сайтов, ведь узнав 1 ваш пароль, который вы передаете на левый сервер, от одного сайта, становится очевидным правило по которому его составлять для всех остальных. Стало быть все добавки к паролю бесполезны. Чтобы этого избежать требуется хеш функция до отправки пароля.
— Иногда нужно помнить не только пароли, но и факт его наличия;
— А еще некоторые ресурсы, непонятно зачем, требуют периодической смены пароля;
— Бывает, что нужно запоминать чужие пароли. Например, доступ к FTP заказчика;
— Допустим сам захотел сменить пароль на каком-то ресурсе;
Как поступите?

Уже несколько лет пользуюсь компасом и доволен:


  1. Реально можно генерировать пароли на любой вкус. Где-то сложные, где-то простые. Где-то только цифры.
  2. Храню ответы на вопросы и прочую информацию. Потому что однажды, забыв ответ пришлось топать в офис Аэрофлота. А забыл, потому что никогда честно не отвечал.
  3. Храню чужие пароли, пришедшие по работе или подработке. Тут вы вообще не можете их выбирать.
  4. Пользуюсь на компьютере и телефоне (синхронизация по вебдав).
  5. Хотел хранить фото документов, но решил не раздувать базу.
  6. Активно пользуюсь функцией автонабора вместо буфера обмена. Это особенно удобно, когда надо набрать пароль по рдп или тимвьюверу. С общим буфером обмена вечно что-то не так.
    Всего накопилось порядка 250 паролей. И это все очень удобно и безопасно. По крайней мере тем кому я могу быть интересен едва ли по силам получить доступ. Помимо шифрования файла я за свой компьютер никого не пускаю, всегда блокирую. Телефон закрыт пинкодом со стиранием памяти после 10 попыток (и никакой биометрии).
    Но если всё-таки доступ к файлу кто-то получит — это будет катастрофа.
    Но не думаю что хранить в блокноте и считать хеши надёжнее, тем более в браузере и через инет.
    Я думаю не за 2-3 часа, но на 2-3 выходного можно сделать собственное хранилище паролей и хранить их там (на Дельфи, например, или фрипаскале, их же даже в школе дают)
Смотря что считать надежностью. Собственное хранилище лучше не делать, не получится столько же надежно и безопасно как уже существующие. Ну если только ради развлечения.
Что там может не получиться? Одно дело доказывать надежность шифров, другое — использовать существующие (тот же AES). Это примерно как собрать самолетик из конструктора.
Но если всё-таки доступ к файлу кто-то получит — это будет катастрофа.

На самом деле катастрофа будет, если доступ потеряете вы :)
Если получит кто-то другой, то даже критичные сервисы, типа банкинга, имеют на этот случай второй уровень защиты — смс к примеру. Остальные по принципу неуловимого Джо. Ну и догадавшись об этом вы в течении небольшого времени поменяете пароли на самых важных сервисах.
Действительно. Теперь буду переживать о двух вещах :)
Если получит кто-то другой, то даже критичные сервисы, типа банкинга, имеют на этот случай второй уровень защиты — смс к примеру.
… или локальный TOTP, shared secret для которого хранится в том же файле :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории