Комментарии 39
Хорошая работа. Но как с монетозацией?
Как будто вы свой курсач/диплом скопировали и вставили.
Манера подачи очень шаблонная и используемые средства довольно сомнительные, учитывая выбор языка. Как будто за использование JNI и статью на заборе дают дополнительные баллы в зачёт
Придерживался официального стиля с вкраплениями вольностей, так как посчитал, что это самый лучший вариант для мануала. JNI выбран как один из инструментов работы с облаком, так как компания предоставляет библиотеку на java, в которой происходит обмен данными. Поэтому выбрал такой вариант, чтобы не описывать взаимодействие по REST, и чтобы одну и туже библиотеку подключить на разных платформах.
Десктопные кроссплатформенные парольные менеджеры которые хранят БД в файле:
* https://www.keepassx.org
* https://keepass.info
* https://keepassxc.org
Для мобилки тиких приложений больше.
Все работают поверх одного формата kdbx
Файл с паролями автоматически шифруется мастер паролем или локальным ключем.
keepass: существует
автор: изобретает велосипед
Хабр не образовательный, так и запишем
Есть еще замечательный https://keeweb.info/, у которого есть в том числе web версия.
Я делаю так:
#!/bin/bash
if [ 1 -gt $# ]; then
echo 'Usage: note_enc "text to encrypt" > your_file '
exit
fi
echo $1 | gpg --symmetric --cipher-algo AES256
Синхронизация между устройствами через git
Специально для Вас уже давно сделали pass, ровно через gpg ключи и засовыванием этого в git репу.
Спасибо большое за проделанную работу, попробую повторить!
Получилось
Крайне
Полезное
Ни**я
(с) Доктор Дью
Автор,
1. научитесь структурировать информацию, оборачивать ваши мысли в абзацы, параграфы и главы, предоставлять план действий, мыслить проектно.
2. посмотрите кино Игра в имитацию, где вам доступно объяснят:
знание, о том, что содержимое представляет из себя XML - снижает криптостойкость.
Вы хоть обмажтесь аесами и гостами,
3. хранить полный файл в памяти - это залог успеха!
знание, о том, что содержимое представляет из себя XML - снижает криптостойкость
Без конкретных данных это просто демагогия. Допустим, иметь общее понимание полезно, но если это практического влияния иметь не будет, то от знания толка никакого нет
хранить полный файл в памяти - это залог успеха!
Если это файл, который программа сама генерирует и/или есть ограничения на размер буфера для чтения, то никакой проблемы тут нет - распакованный XML с паролями - это не архив фоток
Проблема есть с тем, что память процесса может прочитать кто угодно и тогда у злоумышленника будут вообще все пароли, причем в открытом виде
Во-первых, это зависит от OS. Не везде можно свободно читать память другого процесса (ну, может быть для модуля ядра - везде).
Во-вторых, так или иначе пароли в любом случае должны в какой-то момент попасть в память, а если и не сами пароли, то мастер-ключ для расшифровки. А защита от этого уже будет сильно разниться для разных ОС и разных процессоров. На ARM есть TrustZone, на x86 -TPM/SGX.
Вы сами говорите, что автор плоховато подаёт информацию, если сюда ещё воткнуть вопросы кросс платформенной защиты памяти - можно на пару таких же томов настрочить. Но если это вас возмущает, можете сами тоже написать, как правильно надо, а не вот это баловство. Заодно и покажете, насколько ужасно обмазывать XML аесом
Меня это не возмущает) И вообще изначальный комментарий оставил совсем не я. Я лишь предположил проблемы созданного решения.
Но в целом, информация действительно подана не очень удобно. Возможно, было бы лучше написать целый цикл статей, причем в первой - анализ рынка и особенности той или иной выбраннной технологии
Далее, хранение паролей - это про криптографию и безопасность. Но судя по всему, автор либо специально сильно упростил этот момент (статья в этом плане скорее о том, как делать не надо), либо просто не очень разбирается в теме (что уже плохо). Из того, что плохо: 1) данные в памяти не зашифрованы, 2) хранятся все сразу и под одним ключом, 3) отображаются тоже все сразу, а не по очереди, 4) данные для шифрования/расшифрования хранятся в самом приложении,как его части, хотя абсолютно во всех адекватных реализациях мастер пароль вообще ни где не хранится, а соль всегда будет разная, для каждой записи
Даже если оставить криптографию, то менеджер паролей, по хорошему, должен не просто быть нативным приложением для выбранной операционной системы, но и нативно в нее интегрироваться, как собственно, менеджер паролей. То есть, это подразумевает плагины для браузеров, поддержку автозаполнения на том же андроид, например и т.д.
И в заключение: статья в техническом плане в принципе достаточно слабая. По факту, тут нет ни разбора принципа выбора технологий (если статья позиционируется как для новичков), ни хардкорных алгоритмов и подходов к надёжной защите паролей (если статья на более опытную аудиторию). Ну и в принципе, статья больше не про гранение паролей, а о том, как скрестить ужа с удавом, как дебажить и т.д. и если уж захотелось интеграции с о лаком, то лучше бы стоило реализовать систему плагинов и как пример такого плагина - написать поддержку одного конкретного облака, причем не по принципу "я нашел всего одну библиотеку интеграции, но она на другом языке программирования, поэтому попытаемся все скрестить", а "раз пошло такое дело, давайте разберемся, как оно там работает и перепишем только нужный нам функционал уже на нашем языке"
Давайте я Вам помогу. Проблема в том что
Экран на который выведен пароль может читать кто угодно
Если пароль озвучивать голосом - его может послушать кто угодно
Если пароль печатать на принтере без вывода на экран - его может посмотреть кто угодно
Как вариант решения не дешифровывать пароли. Пусть всегда остаются зашифрованными.
посмотрите кино Игра в имитацию, где вам доступно объяснят: знание, о том, что содержимое представляет из себя XML - снижает криптостойкость.
По другим 2 пунктам претензий нет, но этот применим только если пользоваться криптографией 1940-х годов. Мы, к счастью, преодолели этот этап.
Простите, несколько вопросов по используемой криптографии.
1) Я так понял вы один раз генерируете соль и IV, линкуете и они переиспользуются при каждом шифровании? Если это правда, то так делать нельзя. Например, вот почему: https://derekwill.com/2021/01/01/aes-cbc-mode-chosen-plaintext-attack/
2) А почему AES CBC, собственно? Ведь в нем же нет аутентификации. https://alicegg.tech/2019/06/23/aes-cbc
По первому, всё верно, так как если у клиента на другой платформе будет другие вектор инициализации или соль, то он не сможет расшифровать файл. По второму, выбрал это шифрование, так как посчитал его одним из надёжных и популярных.
У клиента на другой платформе при каждом изменении файла и шифровании будет использоваться одно и то же IV, и этого достаточно, чтобы ослабить стойкость шифрования: подробности можете посмотреть в первой ссылке моего изначального комментария, но как бы то, что злоумышленник может увидеть в каком блоке было изменение - это уже нехорошо.
По поводу AES CBC - главный недостаток, это то, что нет аутентификации, то есть злоумышленник может пытаться подменить шифротекст, поменяв какие-то биты, и смотреть, что получится. А если говорить про CBC, то может попытаться сделать padding oracle attack - а вы, наверняка, не тестировали, что будет, если в вашей реализации при расшифровке на вход передать неправильный padding.
Если выбирать из семейства AES, то почти всегда единственным безопасным алгоритмом будет AES GCM (если нет очень веских причин выбрать другой алгоритм) - но вы почему-то его вообще не рассматриваете. Если не из семейства AES, то с xchacha20-poly1305 сложнее накосячить. Но вообще правильное использование низкоуровневых криптографических библиотек - дело достаточное хитрое, и, чтобы не ошибиться ненароком, есть более высокоуровневые библиотеки типа NaCl/libsodium, используя которые можно избежать многих подводных камней.
Может имеет смысл шифровать не весь файл, а только логин и пароль для каждого сервиса. Тогда полностью расшифрованный файл не будет в памяти лежать. А расшифровывать реквизиты только перед входом в аккаунт для конкретного сервиса.
Велосипед, причём довольно кривой. С первого взгляда вижу сразу проблемы:
1) Привязка к яндекс.диску. Если уж параноить то пароли нужно держать на собственном сервере, а не в публичных облаках.
2) Для записи есть только поля логин/пароль. Часто этого мало. Одноразовые пароли. Временные пароли. Дополнительные данные аутентификации. И т. д.
3) Нет объединения изменений. Скажем если между чтением файла и записью, файл был изменён на другом устройстве. То по хорошему перед записью нужно проверить менялся ли файл и если менялся, то нужно объединить изменения.
Тоже сейчас копаюсь и пишу свой менеджер паролей. Статью пробежал лишь мельком, так что если про мои замечания было что-то написано, прошу не сильно ругать.
Для хранения паролей будет использоваться файл формата xml, который будет шифроваться методом AES-256 и храниться в облаке.
По итогу придется вытаскивать все пароли в оперативку и держать там. Не то, чтобы прям совсем критично, но из оперативки их тоже можно прочитать, насколько помню.
Для работы с API-диска требуется логин и пароль, но вместо того, чтобы каждый раз вводить их, был перехвачен токен авторизации и использовался для работы с облаком.
Это первое - срок действия токена авторизации может закончиться и придется заново получать токен.
Чтобы напрямую работать с массивом данными и не подгружать их каждый раз из файлов, эти массивы сразу импортируются в исполняемый файл. Для этого полученные файлы преобразовываются в объектные файлы, с помощью инструменты «objcopy» (инструмент поставляется вместе с MinGW), а потом линкуются в exe-файл.
Это то, с чем я долго боролся и получилось побороть только с костылем. На винде так делать очень плохо. Если кто-то получит доступ к exe файлу, а это может сделать любой вирус, нацеленный специально на атаку вашего менеджера паролей, то ключ шифрования будет получить достаточно легко. И хранить ключи просто в файлах тоже плохо: к ним также есть доступ. Вы используете PBKDF2, так выберите надежный пароль и уже с его помощью генерируйте ключи. Правда, на мой взгляд, подход "один пароль, чтобы править всем" тоже слегка странный. Также, как правильно отметили выше, использовать один и тот же IV для AES не особо правильно и безопасно.
На мой взгляд, наилучшим решением было бы написание своего сервера под хранение паролей со сквозным шифрованием. Причем каждый пароль шифровать своим ключом. В идеале, собрать систему "выстрели пользователю в колено", чтобы нельзя было идентифицировать, кому принадлежит пароль в базе, а получать конкретный пароль только после ввода названия сервиса и логина (хранить название сервиса и логин напрямую плохо, кстати). Да, это доставит неудобства пользователю, но в таком решении безопасность пароля максимальна, потому что:
1) Без идентификации пользователя, сервиса и логина, даже если пароль утечет и его каким-то чудом правильно дешифруют, это будет просто пароль, который неизвестно куда применять
2) Уникальные ключи шифрования дают возможность не переживать за то, что дешифрование одного пароля даст возможность узнать остальные пароли в базе
3) Даже если злоумышленник получит доступ к устройству пользователя, в котором был произведен вход в систему, без знаний о сервисах и логинах для которых есть записи в базе.
В заголовке не хватает то ли запятой, то ли дефиса, то ли знания английского...
У автора в школе наверное 5 (то есть 12) по сочинению была. Вместо 100 слов написать 1000, это талант. У меня с этим проблемы были ))
Для курсовой, наверное, это неплохо, но для хабра не ок. Автор берегите своё и чужое время, не пишите ненужных буковок. Даже учебные мануалы не пишутся с расчётом на идиотов (если, конечно, это не гос организация).
Шел 2024 год... автор бы лучше больше внимания gui и документации в коде уделил, чем изобретать никому не нужный велосипед с 0 и так подробно излагать механику того, что сейчас в пару строк кода умещается. Когда подобный фуллстек вебапп/мобайлапп (да пес с ним, десктопный) можно разработать что на джава, что на крестах гораздо проще и быстрее. Сохранение в файл конечно интересная идея для безопасности и сохранения бабок/ресурсов (не надо ращворачивать или арендовывать сервак, но если для лички только, можно и локальный апп создать). Идеи хорошие, а вот реализация лично мне не очень зашла.
По-моему это самый длинный пост, который мне приходилось листать) Можно было бы весь код просто в гитхаб скинуть и сократить длину поста раз в 5 что уже можно было бы хотя бы попытаться прочитать.
Я прошу прощения конечно, но это случайно не дипломная работа какого-нибудь студента?
Как сделать пароль менеджер