Хочу сделать хранильник паролей в онлайне. Сразу оговорюсь что SaaS-хранильникам я не доверяю по 2-м причинам:
1) Слишком лакомый кусок для хакера такие сервисы, по сравнению с моим уютным хомяком, о котором 99,99999% даже и подумать не подумают и целенаправлено никто трогать не будет, соответственно шанс что БД с моими пожитками утечет на сторону или в паблик стремится к нулю.
2) Пароли от своих серваков я помню и набираю с закрытыми глазами, поэтому если мой сервер ушел в даун, я по крайней мере могу понять что с этим делать, даже если нахожусь в кафешке и с собой у меня только джейлбрейкнутый айпод тач, в отличие если сайт с таким хранильником уйдет в даун…
Поэтому решил I need it — I write it.
Но у меня есть ряд вопросов на тему «как лучше».
1) Криптование на сервере. Само собой хранить их открытым текстом в БД/файле это бред. Надо их как-то криптовать на сервере, причем желательно чтобы ключ от этого добра был где нибуть в другом месте. У кого какие идеи по криптованию данных на сервере? Задача: если случайно БД с этим добром каким-то образом попадает в чужие руки, чтобы восстановление инфы заняло больше времени чем смена паролей на всех оказавшихся там ресурсах.
2) HTTPS самодостаточен или еще чем-то лучше подстраховаться на пути «транзита»?
3) Фильтрация по браузерам. Есть такая идея чтобы пускало только с определенных браузеров. Вот как в ssh авторизация по ключам работает, аналогично что-то прописать в браузере. Какой-то ключ для конкретно этого браузера. А браузеру без/с другим ключем отдавать похожую, но фейковую страницу. Это реализуемо? Если да, то где почитать по каким темам?
4) Если есть что-то уже подобное на php — буду признателен за ссылки.
Возьмите javascript библиотеку шифрования, например crypto-js, и шифруйте/расшифровывайте прямо в браузере. Соответственно сами данные будут передаваться от вас и к вам уже шифрованными, т.е. даже https особо не нужен и на сервере в базе все лежит шифрованное, так что не страшно если украдут.
Как сказал shsweb, стоит шифровать через js локально. На сервере все хранится в шифрованном виде (собственно оно в таком виде уже туда отправляется).
Возьмите 1password и экспортируйте хранилище в web документ, потом посмотрите на него, Вам должно понравиться как оформлен интерфейс.
По своему опыту скажу, что я бы не стал доверять даже себе в этом вопросе. Слишком много узких мест будет в вашем приложении. Лучше доверить это спецам. И как вариант поставить на тот-же айпод тач 1password или другое сходное решение с возможностью синхронизации.
> Слишком много узких мест будет в вашем приложении. Лучше доверить это спецам.
В корне не согласен с первым утверждением. Во первых я не собираюсь сам разрабатывать криптоалгоритмы.
Это значит как минимум что узкие места будут на «транспортном уровне».
С другой стороны, вам любой адекватный специалист по информационной безопасности скажет что чем более нетривиальное решение, тем сложнее с ним работать. Иными словами: предположим вероятный противник знает что я использую TrueCrypt — он и будет искать способ зацепить мой криптованый раздел. И он его найдет.
В данном случае я хочу чтобы вероятный противник не понимал что именно ему нужно искать с одной стороны, а с другой стороны, как в случае с авторизацией по ключам в ssh, чтобы я мог в случае если устройство скомпрометировано — просто удалить ключ и это устройство больше НИКОГДА не получит доступ данным.
Вот идеологическая подоплека. А так конечно можно купить какой нибуть 1password и не париться, но скомпрометировав устройство на котором установлен 1password вероятный противник будет понимать чего искать.
Еще можно (чтобы опознавать конкретный браузер) использовать клиентский сертификат. И на nginx в зависимости от наличия/отсутствия клиентского сертификата отдавать либо одно, либо другое.
Я не понимаю чем лучше дропбокс в качестве хранильника по сравнению с моей уютной VDS-кой. Ну вот не понимаю и все тут. sshfs я настраиваю «за двееееее минууууууты» и сомневаюсь что другие настраивают это дольше.
Выше я уже объяснял что я хочу сделать это как можно менее заметным. Я согласен что дропбокс и дропбокс, малоли чего я там храню, врятли кто в этой куче будет копаться, а вот 1Password или KeePass уже себя выдают.
Это я все к чему… всякое в жизни бывает, иногда можно случайно залететь и оказаться под следствием. А там же все быстро происходит и этот софт уничтожить будет проблемой. В случае «своего» решения, пока себе эксперты сообразят где и как оно сделано я успею 10 раз «отключить» браузеры скомпрометированых устройств и вместо ответов (допустим оно у меня будет ломиться на адрес site.tld/memo) вебсервер отдаст другой контент, например список дел на завтра/неделю/месяц. Ну или как-то так ) Дальше думаю понятно что можно просто молчать. С этой стороны узкое место личной кибербезопасности более-менее.
1. Асимметричное шифрование. Публичным ключом шифруете, закрытым ключом расшифровываете. закрытый можно у себя где-то хранить
2. По-хорошему, HTTPS нужно использовать с валидным сертификатом. Тогда маловероятно что кто-то сможет провести атаку «человек посередине» незаметно от вас. Но на сертификат нужно потратиться
3. Подобную идею я уже поднимал в статье. Вкратце: каждому браузеру даёте свои куки и так опознаёте их. Это сработает даже если у них будут одинаковые User-Agent. Кукисы генерите на основании типа браузера. Если вдруг злоумышленник украдёт куки от Хрома и поставит в свой огнелис — вы спалите его.
C некоторым опозданием, но утилита уже была написана и здесь пробегала ссылка на нее: TeamPass, Passwords Manager dedicated for managing passwords in a collaborative way on any server Apache, MySQL and PHP — www.teampass.net
