Хранитель паролей KeePassX
На просторах интернет обнаружил свободную программу с открытыми исходными текстами KeePassX[link1]. Это хранитель паролей для систем на базе Linux. Возможно окажется полезной в повседневной работе. Возможно кто-либо из участников форума может дать какие-либо комментарии по поводу этой программы, если уже приходилось с ней сталкиваться.
Программа имеет русский и интуитивно понятный интерфейс, а так же довольно приятна в работе.
Ссылки
[link1] http://www.keepassx.org/
[link2] http://keepass.info/
[link3] http://www.pgpru.com/comment59834
[link4] http://www.pgpru.com/comment64413
[link5] http://www.pgpru.com/comment64648
[link6] http://www.pgpru.com/comment68176
[link7] http://www.pgpru.com/comment68223
[link8] http://www.pgpru.com/comment38574
[link9] http://www.pgpru.com/comment38599
[link10] http://www.pgpru.com/comment48294
[link11] http://www.pgpru.com/comment21230
[link12] http://www.pgpru.com/comment32257
[link13] http://www.pgpru.com/comment52979
[link14] http://www.pgpru.com/comment69008
[link15] http://www.pgpru.com/comment60120
[link16] http://www.pgpru.com/comment67944
[link17] http://www.pgpru.com/comment34765
[link18] http://www.pgpru.com/comment34713
[link19] http://www.pgpru.com/comment79837
[link20] http://www.pgpru.com/comment93921
[link21] https://unix.stackexchange.com/questions/47178/can-files-be-created-with-permissions-set-on-the-command-line
[link22] https://stackoverflow.com/questions/1321168/bash-scripting-how-to-set-the-group-that-new-files-will-be-created-with
Писали как аналог PasswordSafe для KDE. С точки зрения пользователя, программа нормальная. Но использую её большей частью просто как записную книжку, так что в безопасность особенно не вдавался.
Да нет же, это версия Keepass[link2] для Linux. База паролей, созданная мной с помощью Keepass 1.хх под Windows, была корректно ею "смонтирована".
Использую эту программу. К KDE она отношения не имеет, использует библиотеки Qt4.
Виндовый KeePass открывает базу паролей KeePassX.
прошу прощения за некропостинг, озаботился проблемой межплатформенного хранения паролей. По всем параметрам понравилась эта програма. Смущает то, что за все годы она как-то медленно развиваеться и реже чем прототип обновляется. Есть ли какая-либо положительная или отрицательная статистика по данному продукту?
В последнее время они активно готовят релиз 2, на днях вышла уже 4 альфа. Видимо это связано с тем, что старший брат KeePass начиная с версии 2 стал кроссплатформенным.
А как вообще правильно хранить пароли? Если профиль узявим, всё равно украдут их все. Можно менять права на доступ к файлу перед получением пароля из него, а затем снова восстанавливать их обратно, но это всё равно не даёт 100%ой защиты. Нужен какой-то интерфейс доступа к паролям, работающий по сетевым запросам, да ещё такой, чтобы авторизация на выдачу была из-под другого пользователя (из других иксов, другой текстовой консоли).
Как работают хранители паролей? Чем обеспечивается безопасность при взломе профиля? Что мешает злонамеренному коду перехватить пароль на открытие базы хранителя паролей?
Работают так, что система пользователя считается безопасной. Если у Вас там рассадник троянов, то поможет разве что отдельный ноутбук без подключения к сети.
Видимо поэтому я и не использую KeePassX, поскольку вводя пароль к базе я одномоментно открываю хранилище на все пароли, хотя программа сама по себе мне нравится. У меня каждый пароль хранится в своем персональном текстовом файле, каждый файл по отдельности шифрую с использованием gpg. Это конечно все равно не исключает атаки на главный пароль, с помощью которого я провожу шифрование и который у меня только в голове, но из двух зол стараюсь выбирать меньшее.
Что же это за троян такой который как только вы вскрыли базу утащил отдельными запросами все пароли из нее? Вы под админом сидите? Это эксклюзив писанный под вас? На мой взгляд самый большой риск таких программ если кто-то (либо сами создатели) сделали закладку. Главное что сама база к которой обращается программа по моим запросам лежит на шифрованном диске. Ну и еще меня немного смущают порты на мобильные устройства. Их сорсов я нигде не нашел да и кто их делал мне не понятно.
Кстати на шифрованный диск положил так как основной пароль могут всетаки украсть самым простым трояном. Ну а остальные только по мере запросов к ним, я ничего не путаю?
Большинство уязвимостей, например браузеров, связаны с чтением произвольного пользователського файла. Реже бывает возможность записи, а запуск произвольного кода — это уже совсем катастрофично, рассчитывать на какую-то защиту от самой программы в этом случае почти бесполезно.
В то же время, часто приходиться пользоваться множеством веб-ресурсов, требующих пароль, логин и какие-то учётные данные. Лучше, чтобы они все были уникальными, в то время как их сохранность не слишком критична — такие пароли все не запомнить, зато можно выбрать компромисс между безопасностью и удобством хранения.
Тогда складываем все пароли в текстовый файл и не паримся, получается?
Не обязательно. К примеру, трой строит список всех файлов в директории, а потом сливает их атакующему. Дальше атакующий сам подумает, что из этого надо бы перелить к себе на диск.
Нет, зачем же под админом? Да и нет у меня на ПК такого пользователя. root есть, админа нет. Самый простой пример — трой встраивается в какой-нибудь неуинонный процесс, не привлекающий внимания. Без тщательного аудита системы вы не заметите ничего подозрительного. Этот процесс постоянно висит и в цикле отслеживает момент, когда база с паролями будет доступна на чтение. Как только наступает нужный момент, всё читается и позже сливается в сеть. Методы доставки трояна — через уязвимости в закрытом коде или экспуатация уязвимости браузера: адфыр, ылнзу, ашкуащчю.
Файл БД — не криптоконтейнер, открываемый на произвольный доступ. Расшифрование производится в памяти, так что троян должен либо иметь возможность чтения памяти из произвольного процесса, либо логгировать ввод пароля к БД.
От простых троянов и для хранения базы на внешних и сетевых дисках не помешает, не так-ли?
Стоит хранить базу построже чем бросить просто в домашнюю директорию.
Более сложный троян как вы описали да еще и на системе где под рутом сидят будет означать, что конкретно ваш фаил с паролями комуто очень сдался. Тогда да скорее всего они его получат тем или иным способом.
если вы что-то делаете в интернете, что может выделить вас из более чем милиарда и сделать интересным залезть на ваш компьютер что бы сперепть фаил ключей который валяеться просто в домашней папке. И при всем при этом если вы делали привлекающие внимания операции в открытую под своим IP да и черес уязвимый браузер с включенным флешем, джавой, одновременно болтая по скайпу, да еще и ник с почтой оставили такиеже как скажем в фейсбуке. Ну чтож... храните тогда пароли лучше в текстовом виде в файле на рабочем столе. Даже проще сделайте везде пароль Qwerty.
Заранее простите за сарказм, но мне кажеться, что первой линией защиты от спирания фаила ключей просто быть неуловимым Джо который yf[hty никому не нужен.
P.S. Как человек я могу жестоко ошибаться, а вы наоборот все верно сказали.
Если речь идёт о то что помешает трояну, запущенному с правами текущего пользователя, прочитать память другого процесса, запущенного от имени этого же пользователя? Или всё не так просто?
Не сидят.
Хожу на pgpru.com.
Да, запускал Tor.
Могу объяснить чуть подробней. Пользователь, под которым запускается, например, браузер с флэшом, можно считать заведомо скомпрометированым, поскольку до исполнения произвольного кода тут рукой подать. То же самое касается браузера с джавой или скайпом. То есть, по-хорошему, такие программы должны запускаться под отдельным пользователем и отдельными иксами, что не очень-то удобно. Допустим, зловред типа флэша запускается под основным пользователем, под которым находится, в том числе, и база данных паролей. Что можно легко предпринять для защиты от кражи паролей, если делать быстро и на коленке? Залогиниться в консоли под рутом и убрать права на чтение БД этим пользователем. Защита прекрасная, но только как потом оттуда пароли тягать? Если делать тупо и глупо, то вот так: логинимся под рутом, меняем права, потом под основным пользователем извлекаем пароль или обновляем существующий, после чего снова возвращаем права на исходные. Да, это криво, неудобно, да и защита очень сомнительная. Вот я и хотел спросить у местных гуру, насколько всё запущено и насколько легко эта схема взламывается (подозреваю, что при данных предположениях — элементарно).
Уязвимость браузера ≠ уязвимость Flash. Последний — вообще полноценный хозяин в системе. Это независимый процесс, который сам лазит в сеть и делает, что ему вздумается[link3].
Двое иксов, каждые со своим отдельным пользователем, в одних (А) — браузер, в других (Б) — база паролей. Под иксами Б копируем нужные реквизиты в общедоступный файл в /tmp, возвращаемся в иксы А и копируем реквизиты из файла в окно браузера.
по мне так это все тоже самое, только еще и с извращениями. Если у вас в системе сидит злой флэш/троян и только и ждет как базу стащить то, что ему мешает стащить все ваши пароли по одному по мере использования? Это тогда просто вопрос времени, а не защита.
Гражданин, Вы же всё равно вводите пароли через браузер, он их так или иначе получает. Ну, передавайте через астрал, Касперский вроде ещё не сообщал об
отсраастральных троянах.так я про это и говорил. Должен же быть предел шизофрении, а то так уже можно и свое второе я подозревать. А то вздруг вы днем на пгп ру сидите, а ночью ваше второе я шлет письма мелким подчерком.
Лично меня, как я и сообщал уже в теме устроит отсутствие закладок в самой програме и стойкость шифра. А все остальное я отношу к организационным проблемам. Мойте руки перед едой, товарищи. Ну и не читайте советских газет.
это не параноя, а раздвоение личности. а не доверять себе – нормальный подход.
Передадим IP-пакеты с помощью голубейСделаем IPC своими руками. :)Да, замечание совершенно справедливое. Пусть будет «костыль в надежде, что атакующий не сможет грамотно провести атаку», а по-хорошему — да, нет доверия к процессам конкретного пользователя — не может быть доверия и к безопасности паролей, которые из-под него используются.
Допустим, есть профиль, из-под которого мы планируем безопасно ходить на некоторые чувствительные сайты (тот же интернет-банкинг, например), тогда:
Если после этого надо зайти на другой сайт, повторяем всю процедуру (шаги 2-5) заново. При такой схеме есть какие-то гарантии, что пароль, например, на сайт-2 не может быть украден, во время работы браузера с сайтом-1. Есть гарантии, что добавленная уязвимость в профиль всегда нивелируется восстановлением копии из бэкапа (временные файлы с /tmp и /var, если трубется, тоже можно подчищать). Но если не громоздить такую схему, а просто держать файл с паролями под рутом, к которому давать доступ руками, когда надо, то почти вся заявленная безопасность улетучивается.
Кто может, покритикуйте предложенное решение.
Традиционная ахинея из подпорок с распорками из-за безграмотности, так же именуемая в народе: «колхоз». Типична для человека незнакомого с разницей между дискретной и мандатной системой контроля доступа. Потому айда восполнять пробелы, а так же что в этом плане предложило АНБ со своим SELinux и для чего используют «песочницы»(sandbox).
Распишите по шагам, как это сделать через SELinux, причём так, чтоб было короче, проще, удобней и надёжней, чем выше предложено. А то тут были жалобы что официальные дистрострители не могут SELinux приркутить, делают как попало, и сами не понимают, как он работает.
[offtop]
Знаете что? В гробу я видел ваш SELinux, песочницы, MAC, jail'ы, чруты, псевдовиртуалки и прочую нечисть. Есть механизмы контроля ОС (нет локального рута — нет утечки), и есть механизмы разделения информации между разными ОС через виртуалки (нет удалённого рута или дыры в самой виртуальной машине — значит, всё ОК). Всё остальное — это слишком сложные костыли, да ещё и толком не работающие, их изучение и использование себя не окупает, будет лишь иллюзия контроля и иллюзия безопасности. Я уже не говорю о том, что вопрос «откуда взять правила SELinux для такой-то моей конкретной задачи» практически нерешаем.
[/offtop]
Прямо очередная истеричная баба с семью пятницами на неделе. Теперь понятно, почему берётся рассуждать об информационной безопасности не ведая элементарных азов. Надо будет дом построить — сколотит сарай без фундамента с односкатной крышей. Заявив, что в гробу видал долбатню со всеми этими премудростями. А нанять архитектора и строителя — религия не позволяет, это ведь денег платить придётся. Пусть ему лучше в инете, на борде анонимной, обрисуют весь необходимый ликбез на пальцах. Ну так, чтобы пять лет в строительном уложилось в два-три поста.
Эмоций, срача, оскорблений, толстого троллинга и переходов на личности хватает, недостатка нет. А по существу ответ будет, как это сделать? Или мы имеем классический пример толстого троллинга от анонима, который пытается затроллить всех SELinux'ом при том, что он сам его в глаза ни разу не видел и никогда не настраивал?
Выше были приведены цитаты с мнениями тех, кто пытался с SELinux'ом разобраться. На эту тему в соответствующих топиках было много обсуждений. Получается, тут все кругом дебилы, никто не смог осилить, и только один вы — д'Артаньян? Тогда покажите это на деле.
PGPru — это тематический форум, а не анонимная борда типа двача. Соответственно, ваши срачевбросы[link19], написанные в стиле «щас высрусь», могут быть снесены одним кликом, если не последует конструктив.
Один из способов перекидывания паролей/контента от одного юзера другому — это fifo:
Уточнение: после создания FIFO-объекта следует изменить его права доступа, убрав общий доступ на чтение. В противном случае вместо userB перехватить данные сможет кто-нибудь другой.
Уточнение уточнения: ещё лучше права доступа задать сразу при создании.
Таки да. :)
Да, так будет ещё лучше, но есть нюанс — менять права доступа придётся под рутом, обычные юзеры этого делать не могут (chown, chgrp), т.е. тут и так уже между двумя юзерами приходится переключаться, а тут ещё и в рута придётся, чтоб сделать
Да, но userB об этом постфактум узнает, т.к. прочитать из fifo можно только один раз, доступ посторонних не останется незамеченным. ☺
А как? Есть[link21] способ с изменением на лету umask и с install, но это эквивалент chmod, а мне-то, получается, нужен эквивалент chgrp. Нашёл[link22] какой-то хак, но под обычным юзером он не работает:
Зачем? Минимальное требование только одно: юзеры A и B должны входить в одну группу, и права доступа должны быть ограничены чтением[/записью] в группе (-rw-rw----). То есть, как отметил sentaus, выполняйте
Спасибо, понял. Тонкость была в том, что для отработки sg под юзером последний должен числиться членом группы, которую назначает создаваемому файлу.
UPD: Если теперь всё замесить в скрипт, то под userA (передача односторонняя, от userA к userB) можно использовать script_name.sh типа такого:
Наверно можно ещё с ACL попробовать, но тут уже придётся создавать файл с правами rw только для себя, а потом с помощью setfacl дать права rw ещё и другому пользователю. Здесь не будет требования, чтобы они были в одной группе, но должна быть включена поддержка acl.
Не всегда требуется передавать именно файл — иногда надо просто какую-то ссылку или короткий текст, который вводится с консоли. В новом скрипте этот вариант также учтён: