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 just landed and posted this 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 just landed and posted this here
Гемморойоловная боль. Используйте lastpass и будет вам счастье, по паролю на каждый сервис, автоввод, встроенный генератор новых паролей, и прочие плюшки. Вам нужно знать пароль от почты (так, про запас:) и пароль от lastpass, меняя оба периодически.
Предпочитаю использовать асимметричное шифрование и хранить private key только там, где он нужен;
пароль к ключу — в голове.
В качестве генератора паролей: openssl rand 15 -base64.
Все было бы просто, если бы пароль приходилось использовать только на своем компьютере. Мне вот надо, чтобы еще можно было на Android ввести пароль. И в совсем редких случаях — вообще на чужих компьютерах.
geekyschmidt.com/2010/12/09/gpg-on-your-android-phone вот, например, что выдал гугл на запрос gpg android, значит расшифровать и прочитать plaintext из шифрофайла под андроидом не такая уж трудная задача.
Я тоже пользовался активно, но прогресс, к сожалению, быстрее 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 пароль через плечо можно подсмотреть только на БД Кипасс, что без базы не представляет угрозы.
Sign up to leave a comment.

Articles