LINUX.ORG.RU

Релиз pass 1.5 — консольный менеджер паролей

 , , ,


2

0

Управление паролями должно быть простым и следовать философии Unix. С помощью pass каждый пароль сохраняется в шифрованном файле gpg, имя которого - название сайта или ресурса который требует этот пароль. Эти зашифрованные файлы могут быть организованы в значимые иерархии папок, быть копированными между компьютерами и с ними можно работать используя стандартные утилиты командной строки.

Управлять файлами с паролями, используя pass очень легко. Все пароли сохранены в ~/.password-store. К тому же pass предоставляет отличные команды для добавления, правки, генерации и извлечения паролей. Это очень короткий и простой shell скрипт. Он способен временно переносить ваши пароли в буфер обмена и отслеживать изменения паролей используя git. Вы можете редактировать файл с паролями, используя обычные команды unix, наряду с командами pass. Не нужно изучать новые странные форматы файлов. Достаточно использовать bash completion нажав tab для того чтобы автоматически закончить писать команду. Также доступно автоматическое дополнение для zsh и fish. Общество уже разработало iOS приложение, плагин Firefox и скрипт dmenu.

Команды pass описаны на странице man.


Список изменений в версии 1.5:

  • Особенности:
    • Добавлен Team pass. Каждый файл .gpg-id может содержать несколько ID. Это позволяет использовать pass со множеством ключей gpg и с различными настройками.
    • Различные каталоги могут иметь свои файлы .gpg-id. Это сделано для изменения прав различных под-папок.
    • Все временные файлы переписываются произвольными данными перед удалением с помощью shread или wipe, в зависимости от платформы.
    • Буфер обмена может быть переписан успользуя переменную среды PASSWORD_STORE_X_SELECTION.
    • umask может быть переписан используя переменную среды PASSWORD_STORE_UMASK.
    • Добавлена возможность использования gpg v1 в добавку к уже имеющимся gpg v2.
  • Исправленные ошибки:
    • Улучшения работы с буфером обмена.
    • Исправления в работе с символьными ссылками.
    • Исправлен конфликт между паролями и каталогами с одинаковым именем.
    • Bash completion следует в правильный каталог.
    • Множественные оптимизации bash и sed.
    • mktemp теперь использует правильный порядок аргументов.
    • Больше не используется GPG compression.
    • Улучшение документации.
    • Множество исправлений в скриптах импортирования.
    • Не рекурсивный makefile.
    • Очистка автоматического дополнения bash, zsh, и fish.
    • Улучшения в pass init.
  • Новые скрипты импортирования:
    • Менеджер паролей KED.
    • Менеджер паролей Revelation.
    • Менеджер паролей Keepass2.
    • Менеджер паролей Gorilla.
    • Менеджер паролей Pwsafe.
  • Другие проекты:


Скачать

Git

>>> Официальный сайт

★★★

Проверено: fallout4all ()
Последнее исправление: fallout4all (всего исправлений: 12)

Релиз pass 1.5 — консольный менеджер паролей

Приложение iOS.

Чтож под iOS-то не кальсонный, а гуёвый?

sT331h0rs3 ★★★★★
()

В Debian STable нет.

anonymous
()

Занятная штука. Какую-нибудь бы автоматическую синхронизацию через облако(через OwnCloud конечно) и можно выкидывать lastpass.

Loki13 ★★★★★
()
Ответ на: комментарий от Loki13

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

Bfgeshka ★★★★★
()
Ответ на: комментарий от Dantix

Там гит для синхронизации используется

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

Loki13 ★★★★★
()

Как Вы не боитесь пароли в файлах держать?

Как Вы не боитесь пароли в файлах держать? Они бьются на мощном компе за пару минут.

Windows ★★★
()
Ответ на: Как Вы не боитесь пароли в файлах держать? от Windows

Как Вы не боитесь пароли в файлах держать? Они бьются на мощном компе за пару минут.

А где надо, в инете? Или пытаться запомнить каждый из нескольких десятков паролей типа ZF#B^0P-R+31'"EdSO^pAIf2?C'8!\W4, которые из головы вылетят быстрее, чем на экране появится поле ввода?

anonymous
()
Ответ на: комментарий от tazhate

Это гит, оно само.

А push и pull кто будет делать в удаленный репозиторий? По идее надо на появление нового файла в хранилище или изменение существующего автоматически pull-push делать или как нибудь более правильно, но я с гитом не на ты, поэтому не уверен.

Loki13 ★★★★★
()

имя которого - название сайта или ресурса

Это косяк. Не надо это светить.

vsemnazlo
()

храните пароли в одном месте, оттуда их удобнее тырить

anonymous
()

Всё бы хорошо, но автотайп в кипассе уж очень удобный, может кто знает как решить проблему с pass?

anonymous
()
Ответ на: комментарий от Windows

В обычном бумажном блокноте.

Надеюсь, это троллинг такой. Иначе рискую фейспалмом спровоцировать землетрясение...

anonymous
()
Ответ на: комментарий от anonymous

Надеюсь, это троллинг такой. Иначе рискую фейспалмом спровоцировать землетрясение...

Я серьёзно. Толк от пароля ZF#B^0P-R+31'«EdSO^pAIf2?C'8!\W4 приближается к нулю, если его можно декодировать из файла. Ещё хуже, если он перебрасывается через буфер обмена.

Windows ★★★
()
Ответ на: комментарий от Windows

Толк от пароля ZF#B^0P-R+31'«EdSO^pAIf2?C'8!\W4 приближается к нулю, если его можно декодировать из файла.

А запись в бумажном блокноте декодировать вообще не надо. По крайней мере, если его владелец не работает врачом. :)

И для вытаскивания пароля из файла паролехранилки этот файл надо сначала утащить и расшифровать. Чтобы утащить, надо знать про его существование, проникнуть на компьютер жертвы и найти файл, не спалившись при всём этом вещами типа подозрительно высокой дисковой активности. Чтобы расшифровать, надо подобрать [мастер-]пароль, более-менее нормальный вариант которого придумать и запомнить намного проще, чем десятки остальных паролей. И успеть подобрать до того, как жертва тем или иным способом обнаружит факт несанкционированного доступа и поменяет все [наиболее важные] пароли, сделав взлом бессмысленным.

Ещё хуже, если он перебрасывается через буфер обмена.

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

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

anonymous
()
Ответ на: комментарий от anonymous

Классика: http://xkcd.com/936/
Если нужна особая секьюрность, паролем может выступать предложение или даже небольшой стих. Пароли из /dev/random это знатное извращение.

Ustin
()
Ответ на: Как Вы не боитесь пароли в файлах держать? от Windows

Что вы имеете в виду под «парой минут»? Пароли хранятся в шифрованных файлах и каким же слабым должен быть мастер-пароль, чтобы его можно было вскрыть за минуты. Или я что-то не так понял?

Ankor
()
Ответ на: комментарий от Ustin

Пароли из /dev/random это знатное извращение.

Зато, в отличие от слов/предложений/стихов/..., сломать их можно только брутфорсом либо коллизией используемого для проверки хэша (второе, впрочем, в обсуждаемом случае бессмысленно), никакая словарная атака не пройдёт.

И да, 52 буквы латинского алфавита + 10 цифр + 6 знаков препинания (.,!?:;) + 25 спецсимволов ( '«@#$%^&*()-_=+/\[]{}<>|) при длине пароля 32 дают 93^32=~2^209 комбинаций. Успешного подбора.

anonymous
()
Ответ на: комментарий от anonymous

И да, 52 буквы латинского алфавита + 10 цифр + 6 знаков препинания (.,!?:;) + 25 спецсимволов ( '«@#$%^&*()-_=+/\[]{}<>|) при длине пароля 32 дают 93^32=~2^209 комбинаций.

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

anonymous
()
Ответ на: комментарий от anonymous

Ладно, разжую. Пусть в языке всего лишь 2^12 слов. Одно четверостишье содержит порядка 20 слов, откуда получаем 2^240 вариантов перебора – для случая когда взломщик знает принцип составления пароля и брутит именно по тому словарю, что мы используем. Если не знает, сложность космическая. Устойчивость ко взлому даже выше твоего варианта, запоминается легко и непринужденно. Так зачем же использовать пароли из /dev/random?

Ustin
()
Ответ на: комментарий от anonymous

93^32+(93^31+93^30+...)
Даже на 2% не возрастет, какие несколько порядков.

Ustin
()
Ответ на: комментарий от Ustin

Пусть в языке всего лишь 2^12 слов. Одно четверостишье содержит порядка 20 слов, откуда получаем 2^240 вариантов перебора

Вероятность встретить любое из этих слов в осмысленном тексте не подчиняется закону равномерного распределения, так что какие 2^240? У букв, если речь идёт, опять же, о нормальном тексте, со случайностью ещё хуже (хотя бы даже из-за значительно меньшего количества). Обычный текст по криптостойкости никогда не сравнится с таким же количеством случайной белиберды из /dev/random.

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

anonymous
()
Ответ на: комментарий от anonymous

Вероятность встретить любое из этих слов в осмысленном тексте не подчиняется закону равномерного распределения

Ну так и слов не 2^12, а что-то в районе 2^18 - 2^19. Основная идея вообще в том, что сложность запоминания рандомного слова человеком меньше, чем рандомного символа, а вариантов одного слова куда больше, чем одного символа.

К паролехранилкам как идее претензий не имею, но пароли вида (10-15-100500 рандомных слов подряд) генерируются легко, криптостойкость дают не хуже, диктуются по телефону/переписываются на соседнее устройство при необходимости и даже запоминаются. Они и должны использоваться в паролехранилках, а не мусор, с которым можно взаимодействовать только копипастом.

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

Ustin
()
Ответ на: комментарий от Ustin

К паролехранилкам как идее претензий не имею, но пароли вида (10-15-100500 рандомных слов подряд) генерируются легко, криптостойкость дают не хуже, диктуются по телефону/переписываются на соседнее устройство при необходимости и даже запоминаются. Они и должны использоваться в паролехранилках, а не мусор, с которым можно взаимодействовать только копипастом.

А какая разница, какой пароль пихать в программу — поэму или несколько десятков случайных символов? Программе-то всё равно, что хранить и копипастить в поля ввода.

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.