Comments 41
Надеюсь, вся информация внутри не лежит в обычном нешифрованном sqlite на смартфоне?
Автозаполнение форм в планах есть? Как у bitwarden.
Хотелось бы, конечно, понять, в каком виде хранятся пароли?
Вообще, самая важная фишка любого менеджера паролей - безопасность. Но о ней в статье нет ни слова. Как хранятся пароли, как обеспечивается их сохранность - не понятно. Может быть, стоит дополнить статью?
Добрый день! В качестве алгоритма шифрования использую AES с промежуточными слоями для большой защиты данных. Вы правы, стоит дополнить статью пояснением за сохранение данных, в ближайшее время допишу раздел!
Извините, а что такое промежуточные слои? Не встречал этот термин (спрашиваю без подкола, правда просто не встречал).
Дополнительные шифрование после обработки AES алгоритма. Я позже напишу подробную статью о том, как SmallKey шифрует данные. Спасибо за комментарий!
Вот чего-то подобного я и опасался. В целом, "дополнительно шифровать данные" (например, шифровать два раза) обычно не рекомендуется, этим проще навредить чем помочь. Надеюсь, Вы знаете, что делаете.
Спасибо за комментарий! Если вы знаете, то укажите или опишите лучший способ шифрования для мобильных устройств, это поможет проекту и будет интересно всем.
К сожалению, не знаю, что нынче самое актуальное, но общие принцип таковы:,
1. Современные криптографические алгоритмы подвергаются очень тщательному анализу, используя вектора атаки, которые порой даже в голову не придут. И если алгоритм считается безопасным, то, вопреки всем усилиям, уязвимостей в нём на данный момент не найдено. Соответственно, если Вы используете считающийся безопасным алгоритм, со считающимися безопасными настройками, причём используете существующую реализацию, а не придумываете свою собственно (это важно), то Вам не нужна никакая дополнительная защита.
2. В то же время криптографические алгоритмы, как Вы знаете, весьма тщательно тасуют биты, чтобы результат был, в идеале, неотличим от белого шума. И вот этот самый процесс, помимо прочего, и верифицируют – можно ли из этих перемешанных битов извлечь какую-то информацию. Из этого следует:
- если Вы применяете свои "доп. алгоритмы" до шифрования, то, учитывая, что алгоритм шифрования должен работать на любых входных данных, по идее, проблем быть не должно, но, во-первых, смотри пункт 1, а во-вторых, алгоритмы несовершенны, и лучше не нужно пытаться "улучшить" то, что работает. Потому что может оказаться, что вариант из пункта 1, проверенный тысячами, если не миллионами человекочасов исследователей, работает, но пункт 1 плюс Ваша вундервафля проявляет какие-то свойства, которые позволяют её взломать.
- если Вы применяете свои "доп. алгоритмы" после шифрования, то можно только напортить результат, улучшить его точно не получится. Преобразование может внести какие-то закономерности, не предусмотренные создателями изначального алгоритма. По идее, опять же, не должно, потому что в идеальном мире результат работы "стандартного" алгоритма – "белый шум", но, как мы уже говорили, мир не идеален.
3. Не знаю, применимо ли это к Вашему случаю, но "security through obscurity" не работает. Если замысел в том, чтобы сделать "нестандартную" реализацию, чтобы "стандартные инструменты взлома" на ней не работали, то это бессмысленно, т.к. стандартные инструменты и так на ней не работают (см. пункт 1). При этом если безопасность Вашего алгоритма полагается на то, что атакующий не знает, как он (алгоритм) работает, то это плохой алгоритм. Безопасность всех современных криптографических алгоритмов доказывается из предположения, что у атакующего есть не только полное знание алгоритма шифрования, но даже готовые примеры "текст-шифротекст" и возможность шифровать произвольные сообщения и смотреть результат. Возможно, даже ещё что-то, уже не помню за давностью лет.
Я очень рекомендую посмотреть Стэндфордский курс, к тому же, он реально очень увлекательный и легко слушается: https://www.coursera.org/learn/crypto
Единственный его недостаток – что вторая часть, похоже, не выйдет никогда (её ждут уже больше 10 лет): https://www.coursera.org/learn/crypto2
TL;DR: если использовать надёжное шифрование, свои "улучшения" могут только навредить, т.к. улучшить они ничего не могут, а при этом ухудшить – теоретически, с небольшой вероятностью – могут. Поэтому в курсах криптографии обычно советуют так не делать. А какой алгоритм лучше использовать – это нужно разбираться, что сейчас считается безопасным.
P.S. Вариант "стандартный AES, зашифрованный второй раз стандартным AES" (или любые другие комбинации стандартных алгоритмов) не рекомендуется по тем же самым причинам – такие комбинации никто не проверял, и в пункте 2 может что-нибудь пойти не так. Не должно. Но может. Плюс, опять же, см. пункт 1 – одного надёжного алгоритма должно быть достаточно.
Спасибо за комментарий, я изучу ваш материал.
>> и без привязки его к облаку
Кому как. Иметь возможность быть не привязанному к одному девайсу удобная штука. (Банально утеря девайса).
а приложение на компьютер будет?
Выложить проект в Open Source.
На FDroid потом нет в планах публиковаться?
Добрый день! Да, я очень хочу выложить приложение на FDroid! На данный момент собираю всю обратную связь для доработки приложения.
Вы не могли б выложить АПК где-то... Я не хочу ставить русторе и аппсторе... В том же телеграмм канале
Телеграмм канал, в группу сделать, чтоб замечания писать или предложения, если я правильно понял, на гитхабе нет проекта
Телеграмм канал https://t.me/smallkeyofficial
Почему разработчики разные
Литвинова, Попов
Ставить не буду, ибо пользуюсь passwordstore.org, но позвольте внести свои пожелания:
Обои это разумеется важно, но лучше таки в ознакомительной статье описать о главные фичи приложения хотя бы вкратце, например
где хранятся пароли (увидел в комментариях)?
шифруются ли они (тоже из комментариев узнал)?
есть ли синхронизация (это не то же самое, что импорт/экспорт)?
поддерживается ли OTP а-ля Google Authenticator?
Кроме того карты, заметки email и номера телефонов мне кажутся излишним функционалом. Если вы только не шифруете содержимое email и голосовые звонки.
А чем не угодил, например, keepass2android? Добавьте в него немного тематизации на основе обоев или "перехват цвета, как ее называет Google, приносит сочетания ярких чистых цветов в каждый элемент ОС" и дело в шляпе.
по крайней мере, он проходил уже security audit и имеет обширную пользовательскую базу...
1) Не устраивает UI\UX приложения.
2) В заметках нет возможности сделать текст жирным, курсивом, выделенным и прочее.
3) Темная тема бьёт ярким зелёным цветом в глаза. Хотелось бы сохранять номера телефонов и иметь возможность быстрого вызова из приложения.
4) Кредитная карта не имеет поля "Платёжные системы" как и не имеет наглядного представления самой карты.
Это самые значимые пункты, которые оттолкнули меня от использования этого приложения.
но это всё графические рюшечки.. в чем профит написания приложения такого класса именно с нуля?
мой предыдущий комментарий был робким намёком, почему не объединить силы с уже существующими проектами? дух опенсорса же, все дела...
Скажу честно, я про такой вариант не думал. Наверное, главная причина в степени свободы в рамках личного проекта. Пускай я словлю критику или дискарму, но не ошибается тот, кто ничего не делает. За эти пол года я получил много опыта и знаний, плюс создал что-то своё и полностью сам.
как уже написали все отметившиеся выше, первостепенный вопрос в программах класса "менеджер паролей" - это безопасность и сохранность данных (отчасти поэтому keepass2android выглядит, как гадкий утёнок) и именно на этот аспект нужно сильнее всего налегать, а не на модные цветовые акценты и прочее.
ну, а если цель проекта прокачать какие-то свои навыки (в чем нет совершенно ничего зазорного), это тоже надо явно отметить. не "хей, смарите, какой клёвый менеджер пороле получаиццо!", а "вот мой путь от А до Б, было интересно"
ни в коем случае не пытаюсь обесценить полученный опыт, но в этом плане гораздо безопаснее написать стопятисотый аудиоплеер с нескучными обоями. по крайней мере, об него никто не поранится, когда там обнаружится дырка в безопасности.
такие дела. успехов.
Спасибо за отзыв) Это мой первый опыт разработки от идеи до полной реализации и публикации, и я уже заметил основные ошибки. Что касается безопасности, то я уже собираю мысли в кучу для написания максимально детальной статьи про шифрование внутри SmallKey. Если основной претензией к проекту является шифрование, то я постараюсь в ближайшее время внести максимальную ясность. Еще раз спасибо вам за конструктивный отзыв!
Если основной претензией к проекту является шифрование
совершенно верно!
Если не являешься экспертом в шифровании, не стоит придумывать какие-то свои шифры или комбинировать уже имеющиеся по своему усмотрению. Это, внезапно, может привести к совершенно любым последствиям от ослабления криптостойкости до багов в собственной реализации и последующей утечке данных - обо всём этом уже писали выше...
Менеджер паролей SmallKey