BugTraq.Ru: безоблачнопарольное

безоблачнопарольное
22.03.22 23:05 // оригинал
Выпиливание 1Password из российского App Store стало очередным звоночком и прекрасным поводом оглядеться в поисках замены менеджера паролей. Через несколько дней приложение вернулось, но осадочек остался, усугубившись объявлением CEO компании о прекращении регистрации новых российских пользователей и приёма платежей у старых. Естественно, с переводом их облачных аккаунтов в read-only режим по окончании оплаченной подписки. Впрочем, это уже было немного предсказуемо.

Строго говоря, последний шаг лично меня затрагивает минимально, поскольку для всех своих платформ я в своё время брал standalone-лицензии — во-первых, я терпеть не могу подписки, во-вторых, доверять свои пароли ну очень удобному чужому сервису, несмотря на все его заверения о надёжности и безопасности — большое спасибо. Собственно, возможность автономной работы была основным критерием при выборе между 1Password и LastPass.

Но 1Password уже давно пошёл по пути постепенного выдавливания пользователей на работу с облачной подпиской, о чём представители компании открыто говорили на форумах — разумеется, оправдываясь заботой о безопасности и удобстве пользователей, а не желанием их постоянно доить, как вы могли такое подумать. Добраться до возможности купить standalone-лицензию и раньше было нетривиальным квестом, а в последнее время её совсем убрали, пообещав выпилить поддержку безоблачной работы из следующего крупного обновления. Первым шагом на этом пути стало требование работы через облачный аккаунт при использовании расширения для iOS-версии Safari, хорошо хоть пока можно обходиться без него. Особо упёртым нелюбителям облаков обещана возможность работать со старой версией, развитие которой будет остановлено (хотя с учётом того, что новую версию для маков пилят на Electron, есть шанс, что консерваторам ещё повезло).

Так что последние миротворческие метания руководства компании стали просто вишенкой на торте, которая в сочетании с и без того туманными перспективами использования 1Password практически перевела его в разряд «пора валить».

Требования к кандидатам на замену понятны: поддержка основных используемых платформ (win/mac/linux/ios), плагины для основных браузеров, отсутствие облачных аккаунтов, синхронизация. Последние два пункта выглядят взаимоисключающе, но вполне устраивает синхронизация зашифрованного хранилища через стороннее облако или вообще через локалку. Опенсорсность необязательна, но приветствуется. Совсем хорошо, если есть возможность делиться подмножеством паролем.

Очевидный и в первую очередь приходящий в голову вариант с KeePass, как и прежде, остаётся для сильных духом, особенно если держать в голове перевод на эту платформу и всех домашних. Причём его выбор — только первый шаг, дальше нужно разобраться в зоопарке реализаций под разные платформы, в котором универсального решения до сих пор нет. Если дальше копать в эту сторону, для десктопа/браузеров самым приличным вариантом выглядит KeeWeb, для macOS/iOS — Strongbox, только для iOS — KeePassium. Формат хранилища совместим, синхронизация через облака есть, выглядит работоспособно. Оба iOS-приложения фримиумные, Strongbox через 90 дней пробного использования нужно разблокировать через встроенные покупки, что для семейного использования выглядит так себе, ну и стоит это либо $14.99 в год, либо $59.99 lifetime. Полный KeePassium Pro предлагается за $49.99. И тут пока последнее слово остаётся за внутренней жабой, поскольку при пока устраивающей работе 1Password влезать в платный переезд без уверенности, что результат понравится — ну такое, как говорят братья наши меньшие.

Поэтому гораздо более симпатичным показался вариант с Bitwarden. На первый взгляд выглядит тем же 1Password'ом, только в профиль. Версии для всех интересующих платформ, для работы нужен облачный аккаунт, бесплатной версии достаточно для работы, хотя вкусности типа создания организаций для совместного использования части паролей требуют платной лицензии. Импорт из 1Password присутствует.

Естественно, первая реакция на облако — нафиг, нафиг, но самое интересное начинается с возможности разворачивания своего сервера. Ставится в докер под linux/win/mac, в клиентах указывается адрес развёрнутого сервера, и начиная с этого момента в этой гостинице я директор (с). Не всем, конечно, подойдёт необходимость разворачивать и держать доступным свой сервер, но как счастливый владелец Synology DS916+ я такое очень люблю.

Дальше, конечно, не без нюансов. Докер докером, но docker-compose.yml последней вышедшей версии 1.47.1 включает аж 11 (прописью: одиннадцать) сервисов, живущих в отдельных контейнерах, в том числе всякая пузатая мелочь типа mssql и nginx. И когда всё это счастье взлетает, памяти на него уходит гигабайт-другой, что для домашнего NAS как-то перебор. Плюс эта установка всё равно требует лицензию, и для включения всех возможностей — естественно, всё ту же платную.

Разумеется, нашлись умельцы, сочинившие генератор самопальных лицензий и патч родного сервера, чтобы он эти лицензии проглатывал — даже забавно, как всё это уживается рядом на одном гитхабе, зато могу с чистой совестью поставить ссылку, оперсорс такой опенсорс. Хотя основная проблема всё-таки не в лицензии, а в ресурсах, ну странно же поднимать такую помойку для в общем-то тривиальной базы.

И радикальным решением становится vaultwarden, в девичестве Bitwarden_RS, представлющий собой независимую реализацию сервера с тем же API, что у сервера Bitwarden (не полностью, но большая часть самых полезных функций доступна, причём без-воз-мезд-но, т.е. даром). Причём в отличие от написанного на C# и заточенного под MS SQL Bitwarden, vaultwarden написан на Rust, живёт в одном-единственном контейнере, по умолчанию хранит парольную базу в SQLite (если очень хочется, можно прикрутить и к MySQL, и к PostreSQL), для работы требует жалкие десятки мегабайт.

Установка под DSM с поднятым докером предельно проста. Если включён доступ по SSH, то делается одной командой:

docker run -d --name=bitwarden -p 8080:80 -v /volume1/docker/bitwarden:/data --restart always vaultwarden/server:latest

Если SSH пугает, того же эффекта можно добиться, вогнав эту же строку через web-интерфейс в Task Scheduler.

Здесь предполагается, что докер был установлен на первый диск (как обычно и бывает), а в его стандартном каталоге /volume1/docker создан подкаталог bitwarden, в котором и будет храниться SQLite-база с паролями. Естественно, очень желательно настроить бэкап этого каталога. 8080 — порт для доступа к контейнеру снаружи, можно выбрать любой свободный по своему вкусу.

В расплодившихся по сети примерах ещё можно встретить -p 3012:3012, но тогда уж нужно указывать этот параметр в сочетании с -e WEBSOCKET_ENABLED=true, иначе смысла в нём никакого. 3012 порт используется для постоянного WebSocket-соединения, чтобы веб/десктоп-клиенты могли получать извещения об изменениях в парольной базе. Мобильным клиентам это не поможет, для них нужны push-извещения, которые vaultwarden не поддерживает.

В принципе, после этого уже можно указать адрес/порт своего сервера в bitwarden-клиенте и начать работать. Ну или открыть его в любом браузере. Но и тут есть нюанс. Далеко не все браузеры допускают работу с Web Crypto API по незащищённому соединению (например, Vivaldi такое проглатывает, Chrome наотрез отказывается), что действительно было бы очень так себе идеей при работе снаружи. Поэтому всё это хозяйство нужно завернуть в HTTPS. Простейший способ этого добиться в DSM — использовать штатные средства и включить обратный прокси (Control Panel -> Login Portal -> Advanced -> Reverse Proxy -> Create), где в качестве Source указать HTTPS/*/8443 (или любой другой порт по вкусу), в качестве Destination — HTTP/localhost/8080 (тот порт, который был указан при запуске контейнера).

Кстати, обратный прокси потребуется и для настройки вебсокетов, на 3012 порт нужно пробрасывать /notifications/hub, без этого его открывать бессмысленно. Такая кривоватая заглушка пока сделана из-за очень ограниченной поддержки вебсокетов в Rust'овском фреймворке Rocket.

Дальше нужно решить вопрос с сертификатами, иначе при обращении по HTTPS любой современный браузер очень сильно обидится. Если хочется спокойно ходить к своему серверу снаружи, проще всего получить честный сертификат от Let's Encrypt (Control Panel -> Security -> Certificate -> Add), привязав его к обслуживанию заданного порта (8443 в моём примере). Естественно, в типовой домашней сети с роутером этот порт ещё потребуется пробросить снаружи. Если не нравится каждый раз указывать порт, можно завести с помощью DDNS отдельный хост (Control Panel -> External Access -> DDNS -> Add), и в этом случае в обратном прокси привязать к 8080 порту 443 порт этого хоста, стандартный для HTTPS. Мне это не подходит, как раз на 443 у меня живёт домашний OpenVPN.

Кстати о VPN: как раз исключительно через них (одна поднята на роутере, резервная на самом NAS) я и захожу в домашнюю сеть, после чего работаю с локальными адресами. В такой конфигурации честный сертификат не имеет смысла, приходится обходиться самоподписанным (опять же делается в DSM в несколько кликов). В Chrome его, конечно, пришлось добавлять явно, но это было сделано давно, ещё для веб-интерфейса DSM.

Переползаю постепенно, результатом пока доволен. Разумеется, в нынешних турбулентных условиях нет никакой гарантии, что разработчики Bitwarden или vaultwarden не взбрыкнут так же, как 1Password, опенсорс от этого вовсе не страхует. Но они хотя бы пока в этом не замечены.

теги: софт | обсудить | все отзывы (0) | обсудить в LJ [14952]

назад « » вперед

аналогичные материалы

ihrkampfное // 02.10.24 16:30
синхронное // 13.06.24 18:07
автоматизаторское // 16.05.24 18:12
макоудаленное // 29.01.24 23:10
разнонедельное // 07.12.23 15:09
тейлскейлное // 18.04.23 20:43
ютубноподкастное // 15.10.22 22:07
дваждыодиннадцатое // 22.06.22 03:30
стартофинишное // 24.10.21 03:59
meshное // 06.08.21 20:06

последние записи

ihrkampfное // 02.10.24 16:30
отпускное // 08.07.24 23:02
синхронное // 13.06.24 18:07
автоматизаторское // 16.05.24 18:12
песчаное // 13.03.24 18:05
макоудаленное // 29.01.24 23:10
разнонедельное // 07.12.23 15:09
qtменюшное // 29.09.23 23:47
неестественноинтеллектуальное // 29.09.23 16:50
основательное // 18.09.23 00:15