Re: Новый менеджер паролей
меня удивляет почему еще никто не написал эти 20 строк,
чтобы закрыть дырку между диалоговыми менеджерами паролей и gpg.
Уверен что многие были бы рады такой утилитке.
Да таких утилит -- мильён, ихмо. А я свой вариант писал не от того,
что думал, что нет такой программы, а потому что интересно, да и лучше
разбираться в вопросе буду (надеюсь ;)
Я увидел только pwm и то он не удовлетворяет пока моим критериям
Я не знаю перла поэтому взялся за си, но поскольку у си примитивная
библиотека работы со строками
приходится делать большой обвес вокруг шифрующих/дешифрующих функций.
Ну, на перле свет клином не сошелся. Любой скриптовый язык подошел бы
лучше, чем C.
php мне не нравится, до питона тоже не добрался
У меня всего несколько требований к менеджеру паролей, но им не
соответствует ни один мне знакомый менеджер.
А именно:
- текстовый файл в ascii (чтобы почтой переслать себе на работу нужные
пароли, вручную почистить его)
А на флешке с собой носить не судьба?
я забываю флешку часто :) проще на телефоне, но нету удобных прог, да и
жалко пароли с телефоном терять
- отсутствие диалогового режима (например чтобы читать пароли из скриптов на
php)
ой, а это-то зачем?
например чтобы при разработке веб-приложений не писать код для работы с
юзверями.
подключился к серверу и из командной строки добавил нужного.
да и мало ли зачем, это просто пример. Вся сила юникс в возможности
комбинации программ,
а диалоговый режим разрушает эту силу, поэтому все что не может работать
через командную
строку или stdin не круто.
PS: шифрованый ключ и значение отделяются пробелом типа того:
siq5lQf3sc6hmI0eJp1MYg1lupY
AAAAB3NzaC1yc2EAAAABIwAAAQEAnYNEwvrv6CSFM8kMGjuZBM
чтобы можно было в ключе и его значении использовать произвольные символы,
Кроме пробела, да?
пробел тоже можно, он будет вшифрован в абрукадабру которая не имеет
пробела ибо представляет собой base64 или аналогичный код (я взял тупо
тетрады, т.е. двоичное 255 будет представлено в моем случае ff, потому
что очень просто реализуется).
Думаю что нужно как-то решить проблему второго рода (легитимный субъект не
получает доступа)
и пойти по пути второго пароля, но например чтобы облегчить запоминание
требовать е-майл.
Т.е. е-майл + пароль высветит только половину зашифрованных данных если
используются рабочий и домашний
адреса.
Как-то слишком запутанно и сложно для понимания. Это скорее снизит
надежность, чем ее увеличит.
я размышляю в рассылку потому что жду что может кто предложит разумный
вариант,
а не раскритикует сырые мысли.
Может быть использовать мак-адрес для шифрования, а впоследствии режим
восстановления и указывать мак-адрес так
же в командной строке, зато если потерял файл то злоумышленнику нужен еще и
мак-адрес.
Ну это вообще, по-моему ни в какие ворота. Ну принесли вы базу на
работу. Какой мак адрес вводить? Проще тогда на бумажке все пароли
записать.
чтобы обеспечить работоспособность паролей на другой машине в этом
случае придется и мак адрес приложить при пересылке, а затем произвести
перепривязку пароля путем указания специальной опции аварийного
восстановления :)
... мда, надо чтото более простое, некоторые могут не знать что такое
мак-адрес.
Мне понравилось недавнее нововведение у гугла - двухэтапное
подтверждение, но не то что высылается смс на телефон, а то что
приложения для доступа получают вместо паролей какието хеши, которые
могут быть анулированы.
Вот такая еще идея посетила:
вводим ./passman -l -p password
т.е. командой -l получаем список ключей и подглядев нужный нам делаем
очередной запрос:
./passman -k key -p password
прога расшифровывает контрольный вопрос и задает его:
Моё любимое блюдо:
и уже после ввода отображает содержимое ключа.
или так: ./passman -k key -p password -w answer
Т.е. желающие пользоваться будут вынуждены приучиться создавать
нормальные контрольные вопросы и к более долгому добыванию своего пароля.
Кому лень - юзают gpg.
Мне нравится эта идея :) пока
Reply to: