Re: Новый менеджер паролей
> > Ну а тебе ответили "ты сначала прогу-то покажи - разработчик Debian, однако,
> > несет некую ответственность перед сообществом за то, что он пакетирует".
> >
> прога вот http://paste.debian.net/hidden/117ce902/
> по моим прикидкам готова на треть
> работаю над функцией добавление нового пароля
> ./passman -a -p pass -k key1 -v val1
Вообще-то тебе уже говорили, что так делать (в смысле, показывать пароль в
командной строке), мягко говоря, несекьюрно.
> > И вообще, обычно в Debian пакетируют уже готовую программу, у которой уже
> > есть разумное количество пользователей помимо автора. Начнем с этого.
> >
> видимо стоит завести страничку на sourceforge сначала, пожалуй так и сделаю
> >
> > Если слегка подумать головой, то вся программа умещается в один перловый
> > файл, чуть ли не строчек на 20, не больше, не требующий вообще никаких
> > перловых модулей, даже стандартных. Снаружи требует, в зависимости от
> > выбранного варианта, openssl или gpg.
> >
> меня удивляет почему еще никто не написал эти 20 строк,
> чтобы закрыть дырку между диалоговыми менеджерами паролей и gpg.
Как обычно, "кто может, тому не надо". Собственно, мне программа с таким
функционалом просто не нужна, поэтому я ее и пишу.
С другой стороны, когда мне нужна программа на 20 строк, я ее пишу, но не
публикую.
zsh% ls ~/etc/bin|wc -l
52
zsh% cat ~/etc/bin/*|wc -l
944
В смысле, у меня в ~/etc/bin, включенном в PATH, 52 программы. Суммарная их
длина - 944 строки. То есть, натурально, в среднем чуть меньше 20 строк на
программу. В норме это либо sh (иногда zsh-специфичные вещи встречаются - это
мой любимый шелл, в нем есть много вкусного по сравнению с sh, и я об этом
знаю), либо perl.
Если я начну их публиковать, поддерживать или упаси бог, писать к ним маны,
меня сообщество не поймет.
> Уверен что многие были бы рады такой утилитке.
> Я не знаю перла поэтому взялся за си, но поскольку у си примитивная
> библиотека работы со строками
> приходится делать большой обвес вокруг шифрующих/дешифрующих функций.
Лучше бы перл выучил, право слово. Ну или не знаю, python, tcl...
> У меня всего несколько требований к менеджеру паролей, но им не
> соответствует ни один мне знакомый менеджер.
> А именно:
> - текстовый файл в ascii (чтобы почтой переслать себе на работу нужные
> пароли, вручную почистить его)
> - запрос пароля из командной строки (когда не запущены Х)
> - отсутствие диалогового режима (например чтобы читать пароли из
> скриптов на php)
>
Вполне естественно, что ни один не соответствует. Потому что это не
называется "менеджер паролей". Это называется "мелкая утилитка под
специфическую задачу", которую любой нормальный сисадмин (даже сисадмин, а не
программист) собирает на коленке за полчаса вместе с тестированием из
подручных утилит.
> Думаю что нужно как-то решить проблему второго рода (легитимный субъект
> не получает доступа)
> и пойти по пути второго пароля, но например чтобы облегчить запоминание
> требовать е-майл.
> Т.е. е-майл + пароль высветит только половину зашифрованных данных если
> используются рабочий и домашний
> адреса. С одним мастер паролем вполне хватит и gpg, я борюсь как раз с
> одновременой потерей всех паролей.
> Может быть использовать мак-адрес для шифрования, а впоследствии режим
> восстановления и указывать мак-адрес так
> же в командной строке, зато если потерял файл то злоумышленнику нужен
> еще и мак-адрес.
Когда я учился в школе, у нас был такой анекдот.
Чукча приезжает в Москву, садится в автобус и покупает два билета.
- Чукча, зачем тебе второй билет?
- Однако, если первый потеряю, второй есть!
- А если оба потеряешь?
- Однако, у чукчи проездной есть!
Если почитать букварь по криптографии, то быстро выяснится, что такой подход
почти не усиливает защиту от нелегитимного доступа, зато сильно усложняет
легитимный. То есть, в переводе на русский, в какой-то момент ты не сможешь
расшифровать свои пароли.
А проблемы с доступом к паролям скриптов на PHP решаются иначе. А именно:
0) этим скриптам не показывают никаких паролей, кроме тех, что нужны им для
работы;
1) эти пароли хранят открытым текстом, но с правом чтения только для того
пользователя, от которого работают эти скрипты (и который сами эти скрипты,
разумеется, тоже может прочесть);
2) понимают, какова степень защищенности этих паролей, и каковы у этого
следствия.
Все ухищрения с шифрованием паролей для полного автопилота почти бессмысленны,
ибо что может сделать один автопилот, то может сделать и другой. ("Почти"
относится к ситуации, когда у тебя не скрипт на PHP, а что-то компилируемое,
unreadable для того пользователя, из-под которого работает, немалого размера,
и желательно написанное не на C, чтобы дебаггер не помогал. Тогда добыть из
такого файла пароль для расшифрования можно, но дорого, дешевле сломать
соседний сайт, он на PHP.)
--
Ну какая работа со строками может быть в языке, название которого является
не строкой, а символом?
Sergue E. Leontiev в <csc2ot$hra$1@ddt.demos.su>
Reply to: