Re: Новый менеджер паролей
> По моему этот парольный менеджер не такая серьезная программа чтобы
> потом плакать от каких-то проблем,
> по любому нужно просмотреть нескольким людям и разносторонне оценить
> возможные дыры,
> в таком деле они могут быть только ламерскими либо если взломан алгоритм.
> Про ламерские мне уже тут наподсказывали, спасибо.
Понимаешь, есть такой протокол - XMPP. Более известный по слову jabber. Тем,
кто его придумывал, тоже кто-то когда-то (может, преподаватель в колледже, а
может, коллега на работе) сказал, что TCP - протокол с надежной доставкой.
Поэтому они не предусмотрели в протоколе квитирования получения сообщений.
Кинули сообщение в сокет - и считают его доставленным. Эффект объяснять?
Вокруг этого потом уже пытались прикрутить квитирование доставки, но поскольку
в протоколе оно не обязательно, то с тех самых пор в этом протоколе навсегда
(ну, по крайней мере до обратно-несовместимого изменения) осталась проблема
ненадежной доставки. Ты никогда не можешь быть уверен, что твое сообщение
доставят получателю.
Еще там, Витус, помню, матерился, протоколы шифрования и подписи сообщений
чата (не message, а именно chat) таковы, что если включить и то, и другое, то
вместо тела сообщения приходит то ли подписанная информация о том, что
сообщение зашифровано, то ли наоборот. А собственно информация не приходит.
Зато не перехватишь, да.
> А тему в рассылке я затеял чтобы узнать можно ли будет сократить путь
> для включения проги в дистрибутив,
> надеялся что кто-то ответит: "да собрать пакет это 5-10 минут, кидай
> свою прогу, не забудь вложить лицензию GPL и запакетируем ее и положим в
> experimental ветку", а то может я закончу чнение "Руководство
> начинающего разработчика Debian" только через год.
Ну а тебе ответили "ты сначала прогу-то покажи - разработчик Debian, однако,
несет некую ответственность перед сообществом за то, что он пакетирует".
Причем, обрати внимание, мейнтейнер пакета при этом, подразумевается, берет на
себя взаимодействие с автором программы на тему всех проблем с нею. Или берет
починку этих проблем на себя. И вот потенциальный мейнтейнер твоего пакета
видит человека, который... ну, хочет, допустим, вменяемого, но может пока с
трудом. Ему надо этого геморроя - то ли объяснять тебе, как правильно писать
твою программу, то ли чинить ее за тебя, то ли считаться мейнтейнером
потенциально глючного и дырявого пакета?
И вообще, обычно в Debian пакетируют уже готовую программу, у которой уже есть
разумное количество пользователей помимо автора. Начнем с этого.
> Попробую еще раз объяснить что я хочу. И вправду я пока до конца не знаю
> что делать.
> Нужно сделать так чтобы при вводе мастер пароля показывались только
> имена ключей из пары key=value
> или только имя и значение указанного ключа, при условии что пароль
> введен правильно,
> чтобы доступ к value нельзя было получить одним только паролем и
> допустить утечку сразу всех паролей.
>
> Тут приходит на ум использование второго пароля. И вместе с этой мыслью
> вопрос: а нельзя ли избежать второго пароля?
> Потому что второй пароль опять же откроет все значения ключей, если
> только для шифрации ключей не используются разные пароли. Но
> использовать разные пароли для ключей - тоже какой-то маразм - может
> проще держать в уме сами пароли чем пароли к зашифрованным паролям :) .
>
> Вот я и ищу такой способ хранения при котором нельзя будет потерять
> сразу все ключи и при этом не запоминать десяток паролей и ключей, но и
> более сложный чем использование одного мастер-пароля.
>
> Если опять непонятно выразился, пишите.
Теперь лучше. Теперь я тебе расскажу, что в компьютерной безопасности помимо
угрозы первого рода (нелегитимный субъект получает доступ к информации) есть
еще и угроза второго рода (легитимный субъект не получает доступа к
информации). В принципе, ты уже сам интуитивно понимаешь, что каждый пароль
на свое значение - это угроза второго рода, но хорошо бы было, чтобы ты
взглянул на задачу чуть более системно.
В безопасности всегда приходится балансировать между этими двумя угрозами. В
твоем случае явно нужна возможность по вводу одного мастер-пароля получить все
значения key, которые есть в базе, и при вводе пароля и key получить value. В
принципе, ничто не мешает нарисовать такую систему на скриптах, не забывая
только, что данные надо гонять через пайпы, а не через командную строку. Имея
в качестве базы данных текстовый файл вида key=value по одной записи на
строке, тупо зашифрованный openssl или gpg. Защититься от возможности
прочитать все значения при компрометации одного мастер-пароля мы не сможем, а
программа может быть просто достаточно умной, чтобы не показывать все значения
сразу - много интеллекта на это не нужно. Типа если key не указан, то
расшифрованный файл отдаем в пайп чему-то типа
perl -pe 's/=.*//'
вот тебе и список ключей, а если указан, то чему-то типа
perl -e 'while (<STDIN>) {print if /^\s*\Q$ARGV[0]\E\s*=/}' "$1"
Если слегка подумать головой, то вся программа умещается в один перловый файл,
чуть ли не строчек на 20, не больше, не требующий вообще никаких перловых
модулей, даже стандартных. Снаружи требует, в зависимости от выбранного
варианта, openssl или gpg.
К ней, правда, потом нужно написать man, обязательно по-английски, и русский
тоже желателен. Для этого нужно научиться писать маны. Потом желательно
показать себя отзывчивым автором, внятно реагирующим на сообщения от
пользователей его программы (а значит, получить этих самых пользователей). И
вот тогда уже, если к тому времени для тебя Debian developer manual (на
английском, да) почему-то все еще будет проблемой, будет пора обращаться с
просьбой о пакетировании.
--
русская народная глупость
Кнышев
Reply to: