Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Мсье знает толк в извращениях.
Никогда не сталкивался с проблемой запоминания разных сложных паролей, например генерируем себе головой пароль, но запоминаем не все его символы, нажатые клавиши на клавиатуре и моменты нажатия шифта, например:
r(Shift)t29(Shift)3(Shift)d(Shift)o9(Shift)1
имеем запомненный несложный пароль: rt293do91
и его полную форму вместе с шифтами: rT29#DO9!
Мне таким образом легко удаётся держать в памяти 20+ восьмисимвольных паролей, и не задумываясь вспоминать их.
У многих есть свои способы запоминания и генерации паролей, кому как удобнее.
Никогда не сталкивался с проблемой запоминания разных сложных паролей, например генерируем себе головой пароль, но запоминаем не все его символы, нажатые клавиши на клавиатуре и моменты нажатия шифта, например:
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 век!), которые умеют держать ваши пароли в зашифрованном виде, и, точно так же, ничего не дадут злоумышленнику, который не знает вашего мастер-пароля.
Смысл в создании более длинного пароля? Да и, по моему мнению, иметь все пароли в текстовом файлике при наличии lastpass, 1password, keepass, keepassx и прочего (21 век!), которые умеют держать ваши пароли в зашифрованном виде, и, точно так же, ничего не дадут злоумышленнику, который не знает вашего мастер-пароля.
Блин. Не знал что emacs такое умеет. Повелся на иконку Emacs'овскую и не прогадал!
В Unix есть 2 ГСЧ:
/dev/urandom — быстрый, но не криптостойкий
/dev/random — медленный, но криптостойкий
Для генерации паролей логично использовать второй!
/dev/urandom — быстрый, но не криптостойкий
/dev/random — медленный, но криптостойкий
Для генерации паролей логично использовать второй!
От ты почувствуешь разницу
Это вы *очень* мощно обобщили. На практике, ни в современных Linux, ни в современных BSD, это уже довольно давно далеко не всегда так.
немного не так, когда заканчивается пул энтропии, random ждет его заполнения, поэтому всегда генерирует абсолютно случайные значения, а urandom использует вторично. безопасность на самом деле не сильно отличается, даже чтобы хоть как-то использовать «менее надежный» urandom, потребуются терабайты данных из него и невероятно сложные вычисления — ГПСЧ сейчас очень надежны. чтобы достать несколько десятков байт из рандома, разницы нет совершенно, она проявляется на куда больших объемах, текущее состояние гпсч и пул энтропии больше чем генерируемые данные, корелляции не может быть впринципе img638.imageshack.us/img638/9259/20110801021640644x370sc.png
> В результате мы получаем надёжно зашифрованный текстовый файл
Надёжно? Какая скорость перебора паролей? Пусть будет 1 млн/с. Так как всего по вашей схеме возможно 16^10 паролей, полный перебор займёт 12 дней.
Надёжно? Какая скорость перебора паролей? Пусть будет 1 млн/с. Так как всего по вашей схеме возможно 16^10 паролей, полный перебор займёт 12 дней.
a-zA-Z0-9 — 76 различных символов. Итого 76^10. А где ты взял скорость перебора, миллион в секунду?
((76^10)/1000000)/60/60/24
74408436.71689746962962962962 дней.
74408437/365
203858.7315 лет
Надеюсь, ты терпелив.
74408436.71689746962962962962 дней.
74408437/365
203858.7315 лет
Надеюсь, ты терпелив.
Нет, 16 символов различных, потому что:
Скорость перебора —с потолка интуитивно. Но я думаю что это не далеко от истины, разве что в GPG есть специальный шаг получения ключа из пароля, который намеренно сделан вычислительно затратным.
$ md5sum file.txt | fold -10 | head -1
Скорость перебора —
Ты исходишь из того, что взломщик знает символы, которые используются в пароле. И знает количество этих самых символов в пароле.
Конечно. Это один из принципов современной криптографии: атакующий знает о ключе и алгоритме шифрования всё, кроме собственно ключа.
Ну и откуда ты бы узнал длину ключа и с каких сиволов он состоит если бы я не сказал? Если бы ты просто нашёл мою флешку с шифрованным файлом.
Для современной криптографии это не имеет никакого значения. На практике если кто-то захочет расшифровать ваши пароли (а это ручная работа, поэтому будут искать ваши следы в сети), то вашу схему узнают… из вашего же поста на хабре.
Я могу таким же образом как и ты аргументировать, что пароль «aaaAAA9999» так же хорош как и пароль, полученный твоим способом, потому что алфавит тот же.
Я могу таким же образом как и ты аргументировать, что пароль «aaaAAA9999» так же хорош как и пароль, полученный твоим способом, потому что алфавит тот же.
Опять же могу возразить, как меня можно найти в сети по файлу passwords.org.gpg?
А приведённый тобой пароль можно взломать либо будучи очень удачливым, либо опять же перебирать все варианты.
А приведённый тобой пароль можно взломать либо будучи очень удачливым, либо опять же перебирать все варианты.
Вот это лучше подходит — xkcd.com/538/
И ещё я хотел бы сказать, что можно использовать для паролей, например, pwgen. Плюс можно использовать 4 кбитный gpg-key.
Изобретатели велосипедов, объединяйтесь :) Оригинальный подход.
Сам пользуюсь KeePass с предыдущей волны взломов, когда утек один из моих паролей вместе с базой MtGox: на всех сервисах теперь уникальные рандомные пароли, база хранится под AES-256 с достаточно длинным ключом, доступна везде, ибо Dropbox и клиенты на всех системах. Плюс для всяких маловажных сайтов, для которых лень заводить отдельную запись в KP — самописный букмарклет, генерящий одноразовые пароли на базе доменного имени.
Сам пользуюсь KeePass с предыдущей волны взломов, когда утек один из моих паролей вместе с базой MtGox: на всех сервисах теперь уникальные рандомные пароли, база хранится под AES-256 с достаточно длинным ключом, доступна везде, ибо Dropbox и клиенты на всех системах. Плюс для всяких маловажных сайтов, для которых лень заводить отдельную запись в KP — самописный букмарклет, генерящий одноразовые пароли на базе доменного имени.
Аналогично, связка DropBox — в нем TrueCrypt (зашифрован по ключевому файлу на e-tokean) — в нем KeePass. :-)
Точно так же, использую DropBox+KeePass для шифрования и хранения паролей. Дополнительной плюшкой являются клиенты и того и другого для Android (DropBox+KeePassDroid), так что у меня все пароли и на PC и на моем DHD.
Не совсем только понял для чего Вы используете trueCrypt. Просто дополнительно шифруете на PC уже зашифрованный KeePass'ом файл? Есть смысл?
Не совсем только понял для чего Вы используете trueCrypt. Просто дополнительно шифруете на PC уже зашифрованный KeePass'ом файл? Есть смысл?
зачем в этой схеме ТруКрипт? Это еще один уровень, повышающий вероятность потерять все данные (не злоумышленники стянут, а вы сами не сможете использовать). Keepass шифрует весьма неплохо, и помещать в контейнер Трукрипта лично я не вижу смысла
Дело в том, что использовать в открытом виде DropBox не «секьюрно», а в моем случае в контейнере не только KeePass.
Проблема с «сам не смогу» — маловероятно, DropBox хранит версионность (если Вы о повреждении структуры контейнера), и запасной e-token с ключевым файлом «под подушкой» :-)
Проблема с «сам не смогу» — маловероятно, DropBox хранит версионность (если Вы о повреждении структуры контейнера), и запасной e-token с ключевым файлом «под подушкой» :-)
Отличие данного способа в том, что шифровать можно, что угодно. Хоть войну и мир.
я не спорю с Вами )
Но связка DropBox + TrueCrypt удобна тем-же самым.
1. Авто синхронизация контейнера средствами DropBox (тут конечно неудобство в ограниченном размере на Free учетке).
2. Контейнер монтируется как жесткий диск (хранить можно что угодно).
3. Ключевой файл хранится на защищенном e-token.
2. Множество поддерживаемых ОС (как DropBox так и TrueCrypt).
Но связка DropBox + TrueCrypt удобна тем-же самым.
1. Авто синхронизация контейнера средствами DropBox (тут конечно неудобство в ограниченном размере на Free учетке).
2. Контейнер монтируется как жесткий диск (хранить можно что угодно).
3. Ключевой файл хранится на защищенном e-token.
2. Множество поддерживаемых ОС (как DropBox так и TrueCrypt).
Ваша заметка называется «Безопасное хранение паролей» при чем тут «Война и мир»?
Совершенно не понятно, чем данная схема (а схема, по сути только в plaintext <-> gpg) удобнее специального менеджера паролей, который кроссплатформенный, сам синхронизирует базу, подставляет пароли в браузеры и тд.
Совершенно не понятно, чем данная схема (а схема, по сути только в plaintext <-> gpg) удобнее специального менеджера паролей, который кроссплатформенный, сам синхронизирует базу, подставляет пароли в браузеры и тд.
Пришел к выводу, что несмотря на любые технические средства, надо просто взять и запомнить штук 5 очень сложных паролей. Если пользоваться ими несколько дней вподряд они таки записываются в моторную память и остаются там на долго. И ипользовать их для действительно важных мест. Основная почта, менеджер паролей, зашифрованый раздел диска, банк/платежная система и т.д. Мы ищем удобство — но безопасность и удобство редко пересекаются.
Только не забывайте чистить хистори 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
и хистори не надо чистить.
Для того, чтобы прочитать башхистори нужно иметь шелл на сервер(в моём случае). Или в случае десктопа, доступ к этому самому десктопу. А информация по доступу лежит в зашифрованном файлике. Получается замкнутый круг.
И зачем использовать в качестве мастер-пароля отрывок из книги? Если вы находитесь в месте где нет доступа в Интернет как вы расшифруете ваш файл с паролями?
Гемморойоловная боль. Используйте lastpass и будет вам счастье, по паролю на каждый сервис, автоввод, встроенный генератор новых паролей, и прочие плюшки. Вам нужно знать пароль от почты (так, про запас:) и пароль от lastpass, меняя оба периодически.
Предпочитаю использовать асимметричное шифрование и хранить private key только там, где он нужен;
пароль к ключу — в голове.
В качестве генератора паролей:
пароль к ключу — в голове.
В качестве генератора паролей:
openssl rand 15 -base64.
Все было бы просто, если бы пароль приходилось использовать только на своем компьютере. Мне вот надо, чтобы еще можно было на Android ввести пароль. И в совсем редких случаях — вообще на чужих компьютерах.
geekyschmidt.com/2010/12/09/gpg-on-your-android-phone вот, например, что выдал гугл на запрос gpg android, значит расшифровать и прочитать plaintext из шифрофайла под андроидом не такая уж трудная задача.
Пользуюсь GNOME Keyring и бед не знаю.
Я тоже пользовался активно, но прогресс, к сожалению, быстрее GNOME Keyring.
Вот уже для файерфокса нет плагина к Keyring, на андроидфоне нету клиента Keyring, а Evolution и Empathy сорит аккаунтами с открытыми паролями (Gwibber и то по токенам заходит!) в связке login (которая обычно без пароля).
Раньше мне нравилось что всё окружение интегрировано в Keyring теперь вынужден искать аналоги…
Вот уже для файерфокса нет плагина к Keyring, на андроидфоне нету клиента Keyring, а Evolution и Empathy сорит аккаунтами с открытыми паролями (Gwibber и то по токенам заходит!) в связке login (которая обычно без пароля).
Раньше мне нравилось что всё окружение интегрировано в Keyring теперь вынужден искать аналоги…
Спешу разочаровать (или обрадовать). Сам пользуюсь Epiphany. Ещё хранить в GK пароли умеет Midori.
На андройдофоне нету и самого GK, не удивительно, что там нет и плагина к нему. На андройдофоне пользуюсь запароленным X.509 для входа на SSH, вполне устраивает такая защита. Что там ещё внутри и как хранится — стараюсь не думать, и не выходить дальше гуглопочты.
На андройдофоне нету и самого GK, не удивительно, что там нет и плагина к нему. На андройдофоне пользуюсь запароленным X.509 для входа на SSH, вполне устраивает такая защита. Что там ещё внутри и как хранится — стараюсь не думать, и не выходить дальше гуглопочты.
Использую passpack.com — вполне устраивает.
недостатки вашего способа по сравнению с менеджерами типа Keepass:
1) пароль можно подсмотреть через плечо;
2) неудобно искать пароль к нужному сервису в одном файле. Если файлов несколько — то можно узнать список используемых вами сервисов без криптографий простым взглядом на файловую систему.
В качестве генератора паролей использую apg.
1) пароль можно подсмотреть через плечо;
2) неудобно искать пароль к нужному сервису в одном файле. Если файлов несколько — то можно узнать список используемых вами сервисов без криптографий простым взглядом на файловую систему.
В качестве генератора паролей использую apg.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Безопасное хранение паролей