Pull to refresh

Comments 59

Мсье знает толк в извращениях.
Никогда не сталкивался с проблемой запоминания разных сложных паролей, например генерируем себе головой пароль, но запоминаем не все его символы, нажатые клавиши на клавиатуре и моменты нажатия шифта, например:
r(Shift)t29(Shift)3(Shift)d(Shift)o9(Shift)1
имеем запомненный несложный пароль: rt293do91
и его полную форму вместе с шифтами: rT29#DO9!
Мне таким образом легко удаётся держать в памяти 20+ восьмисимвольных паролей, и не задумываясь вспоминать их.
У многих есть свои способы запоминания и генерации паролей, кому как удобнее.
А у меня 20-25 символьные пароли, в разном регистре и с служебными символами. Просто некоторые ресурсы не позволяют пароли больше 20 символовю
Как только у меня появится то что надо было бы хранить под 25 значным паролем я сразу заведу для этого-чего-то отдельный брелок с длинным-длинынм ключом)
Всегда думал, что в 10 символов можно сделать максимально сложный для подбора пароль (брутфорс для пароля сложнее 12345 не берем, для подбора по хэшу). LastPass на 9 (очень редко), 10 символах показывает полностью заполненную графу сложности.
Смысл в создании более длинного пароля? Да и, по моему мнению, иметь все пароли в текстовом файлике при наличии lastpass, 1password, keepass, keepassx и прочего (21 век!), которые умеют держать ваши пароли в зашифрованном виде, и, точно так же, ничего не дадут злоумышленнику, который не знает вашего мастер-пароля.
Блин. Не знал что emacs такое умеет. Повелся на иконку Emacs'овскую и не прогадал!
В Unix есть 2 ГСЧ:
/dev/urandom — быстрый, но не криптостойкий
/dev/random — медленный, но криптостойкий

Для генерации паролей логично использовать второй!
Это вы *очень* мощно обобщили. На практике, ни в современных Linux, ни в современных BSD, это уже довольно давно далеко не всегда так.
немного не так, когда заканчивается пул энтропии, random ждет его заполнения, поэтому всегда генерирует абсолютно случайные значения, а urandom использует вторично. безопасность на самом деле не сильно отличается, даже чтобы хоть как-то использовать «менее надежный» urandom, потребуются терабайты данных из него и невероятно сложные вычисления — ГПСЧ сейчас очень надежны. чтобы достать несколько десятков байт из рандома, разницы нет совершенно, она проявляется на куда больших объемах, текущее состояние гпсч и пул энтропии больше чем генерируемые данные, корелляции не может быть впринципе img638.imageshack.us/img638/9259/20110801021640644x370sc.png
> В результате мы получаем надёжно зашифрованный текстовый файл
Надёжно? Какая скорость перебора паролей? Пусть будет 1 млн/с. Так как всего по вашей схеме возможно 16^10 паролей, полный перебор займёт 12 дней.
a-zA-Z0-9 — 76 различных символов. Итого 76^10. А где ты взял скорость перебора, миллион в секунду?
((76^10)/1000000)/60/60/24
74408436.71689746962962962962 дней.

74408437/365
203858.7315 лет

Надеюсь, ты терпелив.
Нет, 16 символов различных, потому что:
$ md5sum file.txt | fold -10 | head -1


Скорость перебора — с потолка интуитивно. Но я думаю что это не далеко от истины, разве что в GPG есть специальный шаг получения ключа из пароля, который намеренно сделан вычислительно затратным.
Ты исходишь из того, что взломщик знает символы, которые используются в пароле. И знает количество этих самых символов в пароле.
Конечно. Это один из принципов современной криптографии: атакующий знает о ключе и алгоритме шифрования всё, кроме собственно ключа.
Ну и откуда ты бы узнал длину ключа и с каких сиволов он состоит если бы я не сказал? Если бы ты просто нашёл мою флешку с шифрованным файлом.
Для современной криптографии это не имеет никакого значения. На практике если кто-то захочет расшифровать ваши пароли (а это ручная работа, поэтому будут искать ваши следы в сети), то вашу схему узнают… из вашего же поста на хабре.

Я могу таким же образом как и ты аргументировать, что пароль «aaaAAA9999» так же хорош как и пароль, полученный твоим способом, потому что алфавит тот же.
Опять же могу возразить, как меня можно найти в сети по файлу passwords.org.gpg?

А приведённый тобой пароль можно взломать либо будучи очень удачливым, либо опять же перебирать все варианты.
И ещё я хотел бы сказать, что можно использовать для паролей, например, pwgen. Плюс можно использовать 4 кбитный gpg-key.
Изобретатели велосипедов, объединяйтесь :) Оригинальный подход.

Сам пользуюсь KeePass с предыдущей волны взломов, когда утек один из моих паролей вместе с базой MtGox: на всех сервисах теперь уникальные рандомные пароли, база хранится под AES-256 с достаточно длинным ключом, доступна везде, ибо Dropbox и клиенты на всех системах. Плюс для всяких маловажных сайтов, для которых лень заводить отдельную запись в KP — самописный букмарклет, генерящий одноразовые пароли на базе доменного имени.
Аналогично, связка DropBox — в нем TrueCrypt (зашифрован по ключевому файлу на e-tokean) — в нем KeePass. :-)
Точно так же, использую DropBox+KeePass для шифрования и хранения паролей. Дополнительной плюшкой являются клиенты и того и другого для Android (DropBox+KeePassDroid), так что у меня все пароли и на PC и на моем DHD.
Не совсем только понял для чего Вы используете trueCrypt. Просто дополнительно шифруете на PC уже зашифрованный KeePass'ом файл? Есть смысл?
зачем в этой схеме ТруКрипт? Это еще один уровень, повышающий вероятность потерять все данные (не злоумышленники стянут, а вы сами не сможете использовать). Keepass шифрует весьма неплохо, и помещать в контейнер Трукрипта лично я не вижу смысла
Дело в том, что использовать в открытом виде DropBox не «секьюрно», а в моем случае в контейнере не только KeePass.
Проблема с «сам не смогу» — маловероятно, DropBox хранит версионность (если Вы о повреждении структуры контейнера), и запасной e-token с ключевым файлом «под подушкой» :-)
а почему использовать в открытом виде DropBox не «секьюрно»?
Если у вас в контейнере не только Кипасс, то это не значит, что Кипас невозможно вынести из контейнера.
2-3 недели тому назад в любую учетку DropBox можно было войти без пароля (на протяжении 2х дней). У меня нет доверия :-)
ну а при чём тут Кипасс? Многократно же написали, что базы зашифрованы! Из них ничего нельзя извлечь.
Отличие данного способа в том, что шифровать можно, что угодно. Хоть войну и мир.
я не спорю с Вами )
Но связка DropBox + TrueCrypt удобна тем-же самым.
1. Авто синхронизация контейнера средствами DropBox (тут конечно неудобство в ограниченном размере на Free учетке).
2. Контейнер монтируется как жесткий диск (хранить можно что угодно).
3. Ключевой файл хранится на защищенном e-token.
2. Множество поддерживаемых ОС (как DropBox так и TrueCrypt).
Для дропбокса нужен канал в интернет. Плюс я не очень ему доверяю. Описанный же способ позволяет хранить, что угодно, где угодно. Мне показалось это удобным способом, я никого не принуждаю же.
Ваша заметка называется «Безопасное хранение паролей» при чем тут «Война и мир»?

Совершенно не понятно, чем данная схема (а схема, по сути только в plaintext <-> gpg) удобнее специального менеджера паролей, который кроссплатформенный, сам синхронизирует базу, подставляет пароли в браузеры и тд.
Пришел к выводу, что несмотря на любые технические средства, надо просто взять и запомнить штук 5 очень сложных паролей. Если пользоваться ими несколько дней вподряд они таки записываются в моторную память и остаются там на долго. И ипользовать их для действительно важных мест. Основная почта, менеджер паролей, зашифрованый раздел диска, банк/платежная система и т.д. Мы ищем удобство — но безопасность и удобство редко пересекаются.
Для секурности пароли периодически нужно менять. ;)
согласен, и это делает мой метод еще более противным :) нужно забыть с трудом выученные пароли и запомнить новые.
можно ведь эти самые пять паролей «прокручивать», чего сразу забывать? :) не в смысле совсем не менять, а в смысле про одному менять, а остальные по кругу между сайтами
хорошая идея. мне такое в голову не приходило.
UFO landed and left these words here
Только не забывайте чистить хистори bash'a на той машине, где производите эти манипуляции, а то все телодвижения с точностью до байта останутся записанными для потомков.

$ echo "любой отрывок текста из любой книги" > file.txt
$ md5sum file.txt | fold -10 | head -1
95584f1920
$ rm file.txt



Вот так лучше:
$ echo "$RANDOM$RANDOM$RANDOM$RANDOM" | md5sum | fold -10 | head -1

и хистори не надо чистить.
Для того, чтобы прочитать башхистори нужно иметь шелл на сервер(в моём случае). Или в случае десктопа, доступ к этому самому десктопу. А информация по доступу лежит в зашифрованном файлике. Получается замкнутый круг.
Если уж получили доступ к вашему файлу с паролями, нужно иметь в виду то, что .bash_history первым делом утечет туда же. Будьте последовательны, в конце концов.
И зачем использовать в качестве мастер-пароля отрывок из книги? Если вы находитесь в месте где нет доступа в Интернет как вы расшифруете ваш файл с паролями?
UFO landed and left these words here
Гемморойоловная боль. Используйте lastpass и будет вам счастье, по паролю на каждый сервис, автоввод, встроенный генератор новых паролей, и прочие плюшки. Вам нужно знать пароль от почты (так, про запас:) и пароль от lastpass, меняя оба периодически.
Предпочитаю использовать асимметричное шифрование и хранить private key только там, где он нужен;
пароль к ключу — в голове.
В качестве генератора паролей: openssl rand 15 -base64.
Все было бы просто, если бы пароль приходилось использовать только на своем компьютере. Мне вот надо, чтобы еще можно было на Android ввести пароль. И в совсем редких случаях — вообще на чужих компьютерах.
Я тоже пользовался активно, но прогресс, к сожалению, быстрее GNOME Keyring.

Вот уже для файерфокса нет плагина к Keyring, на андроидфоне нету клиента Keyring, а Evolution и Empathy сорит аккаунтами с открытыми паролями (Gwibber и то по токенам заходит!) в связке login (которая обычно без пароля).

Раньше мне нравилось что всё окружение интегрировано в Keyring теперь вынужден искать аналоги…
Спешу разочаровать (или обрадовать). Сам пользуюсь Epiphany. Ещё хранить в GK пароли умеет Midori.

На андройдофоне нету и самого GK, не удивительно, что там нет и плагина к нему. На андройдофоне пользуюсь запароленным X.509 для входа на SSH, вполне устраивает такая защита. Что там ещё внутри и как хранится — стараюсь не думать, и не выходить дальше гуглопочты.
>>Share Passwords with Your Team
Хороший девиз для сервиса хранения паролей.
Это не девиз, а реклама новой возможности. На мой взгляд удобной.
недостатки вашего способа по сравнению с менеджерами типа Keepass:
1) пароль можно подсмотреть через плечо;
2) неудобно искать пароль к нужному сервису в одном файле. Если файлов несколько — то можно узнать список используемых вами сервисов без криптографий простым взглядом на файловую систему.

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

А для поиска как раз и используется org-mode. Там всё довольно удобно структурируется.
в случае использования keepass пароль через плечо можно подсмотреть только на БД Кипасс, что без базы не представляет угрозы.
Only those users with full accounts are able to leave comments. Log in, please.