Вообще не факт, что пароль для разблокировки хранилища (мастер-пароль или мастер-фраза) будут меньшего размера - здесь применимы все те же приемы что и для обычного пароля.
У вас у всех одна и та же логическая ошибка - вы упорно и, склрее всего, сознательно, приписываете общие уязвимости, присущие любому методу аутентификации, исключительно паролям
Да откуда вы это взяли? где я хоть раз это написал? У любого способа авторизации есть уязвимости, просто у паролей их больше - ниже уже писал об этом, что у случае пасскея/сертификатов (практически, но не теоретически) не работают например такие приемы как подбор и радужные списки. Это не повод не использовать пароли или не использовать пасскеи.
Вот 5 минут назад авторизовывался с ноутбука в chrome canary - он просит мой юбикей, мне было лень за ним идти и я вошел по паролю с двухфакторкой через телефон. В другом случае, у меня юбик будет в порту и мне будет лень идти за телефоном - войду по нему.
Три неверных ввода - кулдаун 5-10 минут, 10 неверных вводов - кулдаун сутки или блокировка. Велкам, брутфорс.
Сможете отдать свой телефон хакерам для проверки попытки взлома? а спецслужбам? я вот нет, несмотря на то что и пароли, и двухфакторки, и пасскеи - везде включено все что можно.
Ну и у меня, например, основное банковское приложение закрыто на полноценный 12-символьный пароль, а не на пин-код.
Ну правильно же, где я хоть слово против этого сказал?
Цель - получить доступ. Вы после использования банковского приложения нажимаете кнопку "выйти"? Если нет, а именно это я писал выше, то в памяти телефона остались куки с вашей последней авторизации и мне нет смысла узнавать пароль от самого банкинга, достаточно подобрать пароль от приложения - у приложения альфы например это 4 цифры, у сбера 5 (у других не знаю), есть куча софта для брутфорса таких паролей, начиная от самого примитивного (https://github.com/stevebalk/android_pin_brute_force) и заканчивая корпоративными решениями (https://cellebrite.com/en/products/guardian/guardian-forensics/).
Плюс, доступ к телефону = доступ к номеру, а значит "забыл пароль, код на сброс в sms" и подобные вещи реализуемы.
Конечно, можно сказать "а у меня на другой номер все" - ну значит тогда у вас с большей вероятностью или несколько sim в одном (и тогда нет никакой разницы) или не один телефон с собой, что поможет только в очень узком сценарии типа "у меня вытащили из кармана телефон, но не тот а-ха-ха"
Ещё раз повторю, на всякий случай: в предельном случае пасскей не безопаснее пароля, в остальных - пасскей точно менее безопасен, чем пароль.
Аргументы? Как минимум не существует такой вещи как "самые распространенные пасскеи", которые можно перебрать, радужных таблиц для них тоже нет, таблиц хэшей и тому подобное
Но если вы на минутку отвлечетесь от своего юношеского максимализма и допустите существование способов взлома, не связанных с прямым воздействием на носителя доступа,
А где я это отрицал? или писал что пароли хуже? Изначально это ответ на то, что мол "пароль не зависит от произвола" - оспаривалась эта наивная позиция.
А пароль - он в голове. И не зависит от произвола государств и корпораций
Интересна битва такого юношеского максимализма и терморектального криптоанализатора, кто победит.
Еще удивляют "политики безопасности", когда в корпоративных системах заставляют раз в месяц менять пароль, причем запоминают предыдущие и не дают их использовать. Зачем? От кого эта защита? От самих пользователей?
Вот уж действительно
недорос еще до компьютеров, иди смотри телевизор
Предлагаю тогда и куки везде бессмертными сделать и кнопки logout везде выпилить, чего уж мелочиться.
использую некий стандартный пароль и к нему добавляю цифры месяца и года
А вот это уже нормально, только цифры числа месяца и года имеют низкую энтропию, лучше чтото подлиннее
В контексте обсуждения про доступ к устройству - у вас нет приложений на телефоне, а все сервисы вы посещаете через инкогнито в браузере? если нет, то неважно что пароль у вас в голове
Ну в нормальных местах да, не так. Как минимум на планерке тех, с кем работать предстоит, руку стоит сказать что-то вроде "вот этот вот новичок теперь с нами лямку тянет; новичок - это чуваки, чуваки - это новичок; курить там, есть там, туалет там".
Чаще всего все знакомства укладываются в рабочую неделю, редко в две.
То что нигде не учили и не помогали мне честно говоря сложно поверить, мол - ну одно такое место где каждый человек человеку крыса я могу допустить, но чтобы 6 и, судя по возрасту, продолжительное время - в это уже сложно (ну если только это не жосткая госуха)
Не надо так, лучше создать отдельного пользователя
Первый Nginx (простой плейбук)
Такие штуки как установка и конфигурация сервисов, лучше размещать в отдельные роли, а в плейбуке уже собственно подключать нужные роли
become: yes
Не надо так, лучше применять к конкретной таске если она требует повышения привилегий
apt:
state: latest
Снова ИМХО, но я бы взял package чтобы не прибиваться гвоздями к apt, а не ИМХО - стейт лучше указывать present с указанием конкретной версии, иначе, если запускать в разное время на разные группы хостов можно получить разное состояние хостов
Динамические переменные:
Здесь стоило упомянуть про то как ansible их получает - gathering_facts и модуль setup
Создал конфигурационный файл в корне проекта
Крайне рекомендую добавить:
gathering = explicit - значительно укоряет плейбуки, в которых не используются факты с хостов
roles_path = ./roles:$ANSIBLE_HOME/roles:/usr/share/ansible/roles:/etc/ansible/roles - иногда бывает удобно расположить роли рядом с плейбуками в проекте, например для их разработки и/или отладки
vault_password_file = .vault_pass - ansible-vault - в любом проекте рано или поздно появятся секреты и очевидно у каждого проекта они должны быть свои (а сам .vault_pass естественно в gitignore)
[ssh_connection] retries = 2 - поможет при обрывах коннекта, а то особенно больно когда хостов много и приходится гонять плейбук несколько раз, чтобы точно все везде прокатилось ssh_args = -o ForwardAgent=yes - на случай если на удаленном хосте нужен ssh, например склонить репу (потому что клони через https с авторизацией, а уж тем более копирование ключей - зло)
И убрать become = True
Ну и поделюсь своим плейбуком, вдруг будет что интересно полезно
Ну вот "просто протокол" vless не блокируется. Точка.
Может я не так понял, но кажется тут, что называется "с какой стороны посмотреть". У ркн же цель заблочить ресурс, там к сожалению не совсем дурачки сидят - раз ресурсов для блокировки много, лучше научится блокировать сам протокол, с помощью которого блокировки обходят, а для его блокировки его надо научиться детектировать - и вот именно определение и, соответственно, маскировка - интересная задача "щита и меча".
А вот то что механизмы детектирования используются именно так - вот проблема, которую не решить, но это судьба многих технологий: часто они или приходят из военки (как интернет сам по себе) или поглощаются военкой (космическая отрасль [вроде, но не точно]) :с
Достижение бесспорно огромное. Тут просто нет определенности что значит "значительный" - я это вижу как 10+% пользователей steam, чтобы можно было говорить о значительности. И вот достижение этой отметки в ближайшие 5 лет мне кажется на грани невозможного, несмотря на все усилия как valve, так и microsoft в этом направлении.
Это все конечно верно и никак не противоречит сказанному мной - "значительный" кусок, в ближайшее 5 лет microsoft точно не потеряет.
У меня у самого есть и steam deck, и домашний компьютер постепенно переходит на arch с win 11, и я очень хочу чтобы разработчики игр больше учитывали эту часть рынка (в частности - античиты самая большая головная боль для меня сейчас), но этот копиум про "вот-вот-вот, ща-ща-ща, да-да-да, масдай - ВСЕ" существует уже наверное лет 30, а доли рынка так и не поменялись
Вообще не факт, что пароль для разблокировки хранилища (мастер-пароль или мастер-фраза) будут меньшего размера - здесь применимы все те же приемы что и для обычного пароля.
Так же как и пароль - никак
Да откуда вы это взяли? где я хоть раз это написал? У любого способа авторизации есть уязвимости, просто у паролей их больше - ниже уже писал об этом, что у случае пасскея/сертификатов (практически, но не теоретически) не работают например такие приемы как подбор и радужные списки. Это не повод не использовать пароли или не использовать пасскеи.
Вот 5 минут назад авторизовывался с ноутбука в chrome canary - он просит мой юбикей, мне было лень за ним идти и я вошел по паролю с двухфакторкой через телефон. В другом случае, у меня юбик будет в порту и мне будет лень идти за телефоном - войду по нему.
Сможете отдать свой телефон хакерам для проверки попытки взлома? а спецслужбам? я вот нет, несмотря на то что и пароли, и двухфакторки, и пасскеи - везде включено все что можно.
Ну правильно же, где я хоть слово против этого сказал?
А вы не путаете пароль приложения и пароль сервиса? Приложение у вас прям просит логин/номер телефона/почту каждый раз после сворачивания?
Цель - получить доступ. Вы после использования банковского приложения нажимаете кнопку "выйти"? Если нет, а именно это я писал выше, то в памяти телефона остались куки с вашей последней авторизации и мне нет смысла узнавать пароль от самого банкинга, достаточно подобрать пароль от приложения - у приложения альфы например это 4 цифры, у сбера 5 (у других не знаю), есть куча софта для брутфорса таких паролей, начиная от самого примитивного (https://github.com/stevebalk/android_pin_brute_force) и заканчивая корпоративными решениями (https://cellebrite.com/en/products/guardian/guardian-forensics/).
Плюс, доступ к телефону = доступ к номеру, а значит "забыл пароль, код на сброс в sms" и подобные вещи реализуемы.
Конечно, можно сказать "а у меня на другой номер все" - ну значит тогда у вас с большей вероятностью или несколько sim в одном (и тогда нет никакой разницы) или не один телефон с собой, что поможет только в очень узком сценарии типа "у меня вытащили из кармана телефон, но не тот а-ха-ха"
Аргументы? Как минимум не существует такой вещи как "самые распространенные пасскеи", которые можно перебрать, радужных таблиц для них тоже нет, таблиц хэшей и тому подобное
А где я это отрицал? или писал что пароли хуже? Изначально это ответ на то, что мол "пароль не зависит от произвола" - оспаривалась эта наивная позиция.
А зачем мне пароль как таковой если есть куки авторизации? Смысл то доступ к сервису получить, а не просто пароль узнать
Интересна битва такого юношеского максимализма и терморектального криптоанализатора, кто победит.
Вот уж действительно
Предлагаю тогда и куки везде бессмертными сделать и кнопки logout везде выпилить, чего уж мелочиться.
А вот это уже нормально, только
цифрычисла месяца и года имеют низкую энтропию, лучше чтото подлиннееВ контексте обсуждения про доступ к устройству - у вас нет приложений на телефоне, а все сервисы вы посещаете через инкогнито в браузере? если нет, то неважно что пароль у вас в голове
Metal Gear Solid 4 все еще заперт на playstation 3
эх если бы
Очень зря, черный выглядит чертовски стильно
Для именно дебага есть xdebug, а для логирования - вполне
Ну в нормальных местах да, не так. Как минимум на планерке тех, с кем работать предстоит, руку стоит сказать что-то вроде "вот этот вот новичок теперь с нами лямку тянет; новичок - это чуваки, чуваки - это новичок; курить там, есть там, туалет там".
Чаще всего все знакомства укладываются в рабочую неделю, редко в две.
То что нигде не учили и не помогали мне честно говоря сложно поверить, мол - ну одно такое место где каждый человек человеку крыса я могу допустить, но чтобы 6 и, судя по возрасту, продолжительное время - в это уже сложно (ну если только это не жосткая госуха)
Мб что-то типа pulumi?
Вкусовщина, но ИМХО, инвентарь в yaml удобнее
Не надо так, лучше создать отдельного пользователя
Такие штуки как установка и конфигурация сервисов, лучше размещать в отдельные роли, а в плейбуке уже собственно подключать нужные роли
Не надо так, лучше применять к конкретной таске если она требует повышения привилегий
Снова ИМХО, но я бы взял package чтобы не прибиваться гвоздями к apt, а не ИМХО - стейт лучше указывать present с указанием конкретной версии, иначе, если запускать в разное время на разные группы хостов можно получить разное состояние хостов
Здесь стоило упомянуть про то как ansible их получает - gathering_facts и модуль setup
Крайне рекомендую добавить:
gathering = explicit- значительно укоряет плейбуки, в которых не используются факты с хостовroles_path = ./roles:$ANSIBLE_HOME/roles:/usr/share/ansible/roles:/etc/ansible/roles- иногда бывает удобно расположить роли рядом с плейбуками в проекте, например для их разработки и/или отладкиvault_password_file = .vault_pass- ansible-vault - в любом проекте рано или поздно появятся секреты и очевидно у каждого проекта они должны быть свои (а сам .vault_pass естественно в gitignore)[ssh_connection]- поможет при обрывах коннекта, а то особенно больно когда хостов много и приходится гонять плейбук несколько раз, чтобы точно все везде прокатилосьretries = 2
ssh_args = -o ForwardAgent=yes- на случай если на удаленном хосте нужен ssh, например склонить репу (потому что клони через https с авторизацией, а уж тем более копирование ключей - зло)И убрать
become = TrueНу и поделюсь своим плейбуком, вдруг будет что интересно полезно
Не совсем, есть разница между "установи nginx" и "nginx должен быть" - первое императивный подход, второй - декларативный
Может я не так понял, но кажется тут, что называется "с какой стороны посмотреть". У ркн же цель заблочить ресурс, там к сожалению не совсем дурачки сидят - раз ресурсов для блокировки много, лучше научится блокировать сам протокол, с помощью которого блокировки обходят, а для его блокировки его надо научиться детектировать - и вот именно определение и, соответственно, маскировка - интересная задача "щита и меча".
А вот то что механизмы детектирования используются именно так - вот проблема, которую не решить, но это судьба многих технологий: часто они или приходят из военки (как интернет сам по себе) или поглощаются военкой (космическая отрасль [вроде, но не точно]) :с
Достижение бесспорно огромное. Тут просто нет определенности что значит "значительный" - я это вижу как 10+% пользователей steam, чтобы можно было говорить о значительности. И вот достижение этой отметки в ближайшие 5 лет мне кажется на грани невозможного, несмотря на все усилия как valve, так и microsoft в этом направлении.
Это все конечно верно и никак не противоречит сказанному мной - "значительный" кусок, в ближайшее 5 лет microsoft точно не потеряет.
У меня у самого есть и steam deck, и домашний компьютер постепенно переходит на arch с win 11, и я очень хочу чтобы разработчики игр больше учитывали эту часть рынка (в частности - античиты самая большая головная боль для меня сейчас), но этот копиум про "вот-вот-вот, ща-ща-ща, да-да-да, масдай - ВСЕ" существует уже наверное лет 30, а доли рынка так и не поменялись
Тоже хочу в это верить, но объективно, это крайне маловероятно