Недорогой облачный VDS, на нем основной сервер WG к которому подключение, dnsmasq в роле DNS сервера (экспериментировал с pihole, тоже не плохо получается). Все девайсы работают через него. На мобильном оф приложение от WG в режиме постоянного vpn, по сути через него идут только dns запросы и данные по серой сети (обращение к NAS или другим железкам в общей системе). Так как сервер за бугром, достаточно включить WG с роутом 0.0.0.0/0 чтобы проксировать весь трафик и не думать о цензуре.
ИМХО, не дожил еще WG до промышленных масштабов. Но для малой организации или для «домашнего» vpn — лучший вариант. У меня все устройства (стационарный, ноут, NAS, телефон) объеденны в сеть и доступны по серым адресам всюду, это удобно! Для меня Connection-less прям киллер-фитча.
Блин, неужели никто реально не использует pass (https://www.passwordstore.org/).
Ранее юзал KeePassX, на линухе оказался глюченым. Так же в плане поиска нужного пароля неудобен
LastPass — хранение критически важных паролей в чужом облаке — для меня не вариант. К тому же он условно бесплатен. Если нужно приложение на телефон — нужна подписка. Нативный клиент плохой, если юзать не для веб — вообще не удобен.
Pass — это парольный менеджер изначально написанный на bash. Каждый файл пароля хранится в отдельно зашифрованном gpg сертификатом файле. Хранить можно не только пароль (первая строчка файла), но и любую дополнительную информацию в текстовом виде.
Работает на Linux, MacOS, Win. Android и iOS тоже есть.
Преимущества:
1. Синхронизация через git репозиторий (свой скрытый или внутри компании). (pass git pull, pass git push)
2. Возможность шифровать пароли для нескольких человек (общие папки). Каждый пароль шифруется для нескольких gpg сертификатов. Есть возможность перешифровать добавив или удалив его ИД.
3. Пароли расшифровываются не группой, а по одному
4. Есть gui клиенты для различных операционных систем
5. Есть плагины для тех же TOTP, git credetials, update (обновление паролей), pwned для проверки утечки и многие другие
6. Есть плагины для браузеров для автозаполнения логинов и паролей
7. Есть приложения для мобильных (все бесплатно)
Для линуксоидов, в комплекте есть скрипт для dmenu. То есть по комбинации клавиша в любом месте можно вызывать окно выбора пароля. Пароль может быть либо скопирован в буфер с последующей очисткой (кроме хитрых буферов), либо для вставки в по месту (я использую этот метод).
Из минусов — нет автозаполнений форм (карточные данные и тп, но я думаю мерж реквесты в репозиторий экстеншена приветсвуются). Но я без этого живу нормально (pass ls my_cards/sbrf/visa)
Еще автор pass так же является автором WireGuard но это уже другая история.
Тут речь о common practice, то что каждый второй делает защиту формы логина от брута, но почти никто не делает защиту авторизации по кукам от брута. Почти у всех популярных цмс/форумов так, да и хабр туда же.
Поправлюсь. Многофакторную авторизацию придумали для другого. Если канал скомпроментирован, то тут нужен просто другой канал, как я писал выше (proxy/vpn etc). Формой авторизации тут проблему не решить.
Можно сделать свой костыль: Деффи Хеллман и общение с фронтом уже зашифрованными сообщениями :))
Можно разрабатывать систему, навешивая условия из разряда: https скомпроментирован, сертификат подменен, злоумышленник в бинокль видит монитор, на клавиатуре контроллер логирования нажатий, а АНБ улавливаем мозговые волны. Но давайте все же в качестве первоначальных условий брать стандартную ситуацию.
Это если https так или иначе не скомпромитирован. Корпоративные сети, вирусы на компе у юзера. В целом лишняя безопасность лишней не бывает.
Именно для этого и придумали многофакторную авторизацию
А если просто долбить запросами с куками в виде хэшей этого пароля (в случае не солености), то блока за брут как правило не будет.
Тут уже квалификация кодера. А вообще какая разница чем долбить? Кукисами, пост запросами с паролями, пост запросами с хешеми паролей и тп? Если на форме авторизации нет защиты от перебора — это проблема реализации формы авторизации. Тоже самое касается авторизации по кукиса.
Согласен. Но укажите это явно, что мы собираем полные URL даже на https сайта для построения анонимной статистики в таких системах как SimilarWeb и тд. Зачем встраивать втихоря? В некоторых случаях это довольно критичный момент.
А какова вероятность, что в корпоративной среде будет сделано все это для намеренного хищения пользовательских данных?))) Провернуть такую штуку для фишинга — крайне сложно, поэтому https — это выход из ситуации.
Но если вы не доверяете каналу, вы всегда можете работать через proxy/vpn.
К тому же никто не мешает добавить факторов авторизации помимо логина и пароля, что сделает вход в систему более защищенным, раз уж на то пошло.
пароли в текстовом виде не должны даже покидать браузер пользователя
Бред. Данное утверждение актуально для http сайтов, но в случае https пароль от клиента на сервер всегда по безопасному каналу и извращаться с хешем на фронте просто не имеет смысла.
А солить пароль надо, чтобы в случае получения базы его нельзя было восстановить по радужным таблицам. И алгоритм хеширования нужно вменяемый выбирать, так как md5 и sha1 уже давно считаются не безопасными.
Обратите внимание на prev и hreferer. То есть js библиотека сохраняет предыдущую страницу не зависимо от ее заголовков (можно попробовать найти этот заголовок и проверить).
У Яндекса тоже есть и расширения и библиотеки для расширений подобного рода. Например тот же советник. Было неприятно, когда обнаружил его в Joxi. Пришлось расширение удалить.
www.g-loaded.eu/2010/11/01/change-expiration-date-gpg-key
UPDATE: хорошей практикой считается выставлять конечное время действия ключей и переодически продлевать их, например, раз в год.
Скрин соглашения в посте. Другого нет :) Проверьте.
Ранее юзал KeePassX, на линухе оказался глюченым. Так же в плане поиска нужного пароля неудобен
LastPass — хранение критически важных паролей в чужом облаке — для меня не вариант. К тому же он условно бесплатен. Если нужно приложение на телефон — нужна подписка. Нативный клиент плохой, если юзать не для веб — вообще не удобен.
Pass — это парольный менеджер изначально написанный на bash. Каждый файл пароля хранится в отдельно зашифрованном gpg сертификатом файле. Хранить можно не только пароль (первая строчка файла), но и любую дополнительную информацию в текстовом виде.
Работает на Linux, MacOS, Win. Android и iOS тоже есть.
Преимущества:
1. Синхронизация через git репозиторий (свой скрытый или внутри компании). (pass git pull, pass git push)
2. Возможность шифровать пароли для нескольких человек (общие папки). Каждый пароль шифруется для нескольких gpg сертификатов. Есть возможность перешифровать добавив или удалив его ИД.
3. Пароли расшифровываются не группой, а по одному
4. Есть gui клиенты для различных операционных систем
5. Есть плагины для тех же TOTP, git credetials, update (обновление паролей), pwned для проверки утечки и многие другие
6. Есть плагины для браузеров для автозаполнения логинов и паролей
7. Есть приложения для мобильных (все бесплатно)
Для линуксоидов, в комплекте есть скрипт для dmenu. То есть по комбинации клавиша в любом месте можно вызывать окно выбора пароля. Пароль может быть либо скопирован в буфер с последующей очисткой (кроме хитрых буферов), либо для вставки в по месту (я использую этот метод).
Из минусов — нет автозаполнений форм (карточные данные и тп, но я думаю мерж реквесты в репозиторий экстеншена приветсвуются). Но я без этого живу нормально (pass ls my_cards/sbrf/visa)
Еще автор pass так же является автором WireGuard но это уже другая история.
habr.com/ru/post/273027/#comment_8689007
UPDATE: можно попробовать выдернуть исходники расширения из хрома и попробовать удалить эту часть.
Тут соглашусь.
Можно сделать свой костыль: Деффи Хеллман и общение с фронтом уже зашифрованными сообщениями :))
Можно разрабатывать систему, навешивая условия из разряда: https скомпроментирован, сертификат подменен, злоумышленник в бинокль видит монитор, на клавиатуре контроллер логирования нажатий, а АНБ улавливаем мозговые волны. Но давайте все же в качестве первоначальных условий брать стандартную ситуацию.
Именно для этого и придумали многофакторную авторизацию
Тут уже квалификация кодера. А вообще какая разница чем долбить? Кукисами, пост запросами с паролями, пост запросами с хешеми паролей и тп? Если на форме авторизации нет защиты от перебора — это проблема реализации формы авторизации. Тоже самое касается авторизации по кукиса.
Но если вы не доверяете каналу, вы всегда можете работать через proxy/vpn.
К тому же никто не мешает добавить факторов авторизации помимо логина и пароля, что сделает вход в систему более защищенным, раз уж на то пошло.
habr.com/ru/post/336738
В конце концов есть EV.
Бред. Данное утверждение актуально для http сайтов, но в случае https пароль от клиента на сервер всегда по безопасному каналу и извращаться с хешем на фронте просто не имеет смысла.
А солить пароль надо, чтобы в случае получения базы его нельзя было восстановить по радужным таблицам. И алгоритм хеширования нужно вменяемый выбирать, так как md5 и sha1 уже давно считаются не безопасными.
cz04MTQmbWQ9MjEmcGlkPTdUSWJ3RGRmZG80YTNqdCZzZXNzPTk5NTI0MzAzNjkwNjE2ODIwMCZxPWh0dHBzJTNBJTJGJTJGdmsuY29tJTJGZmVlZCZwcmV2PWh0dHBzJTNBJTJGJTJGd3d3Lmdvb2dsZS5jb20lMkZzZWFyY2glM0Zzb3VyY2UlM0RocCUyNmVpJTNEcEpHVVhQREhPSy1tbXdYNzI3TFFEdyUyNnElM0R2ay5jb20lMjZidG5LJTNEJTI1RDAlMjU5RiUyNUQwJTI1QkUlMjVEMCUyNUI4JTI1RDElMjU4MSUyNUQwJTI1QkElMkIlMjVEMCUyNUIyJTJCR29vZ2xlJTI2b3ElM0R2ay5jb20lMjZnc19sJTNEcHN5LWFiLjMuLjBsMTAuMjI1OS4zNTM4Li4zODEzLi4uMC4wLi4wLjcxLjQ0MS43Li4uLi4uMC4uLi4xLi5nd3Mtd2l6Li4uLi4wLi4zNWkzOWowaTEzMWowaTEwaTFqMGk2Ny5qcVJGeUt3cUNrZyZsaW5rPTEmc3ViPWNocm9tZSZocmVmZXJlcj1odHRwcyUzQSUyRiUyRnd3dy5nb29nbGUuY29tJTJGJnRtdj0zMDE1Декодируем:
s=814
&md=21
&pid=7TIbwDdfdo4a3jt
&sess=995243036906168200
&q=https%3A%2F%2Fvk.com%2Ffeed
&prev=https%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dhp%26ei%3DpJGUXPDHOK-mmwX727LQDw%26q%3Dvk.com%26btnK%3D%25D0%259F%25D0%25BE%25D0%25B8%25D1%2581%25D0%25BA%2B%25D0%25B2%2BGoogle%26oq%3Dvk.com%26gs_l%3Dpsy-ab.3..0l10.2259.3538..3813...0.0..0.71.441.7......0....1..gws-wiz.....0..35i39j0i131j0i10i1j0i67.jqRFyKwqCkg
&link=1
&sub=chrome
&hreferer=https%3A%2F%2Fwww.google.com%2F&tmv=3015
Обратите внимание на prev и hreferer. То есть js библиотека сохраняет предыдущую страницу не зависимо от ее заголовков (можно попробовать найти этот заголовок и проверить).