Да, с паролями и хэшами велосипед изобретать не надо — нехэшированный пароль отправляется сервису, сервис хэширует его (предварительно добавив соль, конечно же) и сверяет с имеющимся в базе хэшем. Ключевой момент — пароль не хэшируется на стороне клиента. Иначе, если клиент сделает один хэш с одной солью, а сервис другой хэш с другой солью — хэши, ожидаемо, не сойдутся. А если хэшироваться пароли будут одинаково — модификация клиента может позволить подставлять условно слитый хэш, не генерируя его из пароля.
В случае компрометации пароля, в т.ч. при выявлении подозрительной попытки входа, пользователь меняет пароль. Иногда и сервис может сделать это принудительно. Поэтому нехэшированный пароль можно смело слать, доверяя только https. Ибо одно из главных правил: один сервис — один пароль. Даже если пароль утечёт, он будет критичен для одного сервиса (если пользователь молодец)
А что делать, если внезапно обнаружится утечка логов, в которых оказались нехэшированные биометрические клиентские данные? Мы ведь в таком случае вынуждены слать строку без хэша. Или сервис сообщит, что стал жертвой атаки, в ходе которой запросы перехватывались и отправлялись злоумышленникам? Или клиент станет жертвой атаки MitM-атаки с подменой сертификата (Минсвязи Казахстана и Минцифры РФ передают приветы и напоминают о своих корневых сертах), и биометрия будет сохранена на стороне посредника? Что в таком случае делать?
Альтернатива — хэшированные на клиенте данные вида "биометрия+timestamp", дабы запрос нельзя было повторить. Но в таком случае придётся хранить сырые данные на стороне сервиса.
Ну это примерно похоже на авторизацию в приложениях банков, да и многих других приложениях. Аутентификация в самом приложении создаёт токен, сохраняемый на клиенте, но без биометрии (или ввода пин-кода) нельзя этим токеном воспользоваться. Впрочем, повторная аутентификация в таком приложении всё равно потребует ввода пароля и/или кода из смс и ещё 2fa-кода. Например, при смене устройства и невозможности переноса данных с прошлого.
Однако я процитирую статью: >Если устройство или биометрия соответствуют информации в базе данных, то пользователь получает разрешение на доступ. Если я правильно понимаю автора, речь о том, что биометрия хранится в базе данных. На стороне сервиса. И тогда получается, что сервис аутентификации будет сверять какие-то данные от устройства, считывающего биометрию, с той биометрией, что он хранит у себя в базе. Таким образом, получается, что для аутентификации нужна вовсе не строка, созданная с использование ключевой пары, а именно строка, созданная с помощью биометрии.
Если устройство хранит у себя ключ, доступ к которому есть только по биометрии — это один сценарий. Утеря устройства в таком случае приведёт к утере доступа, как уже писали в соседнем комменте.
А вот если устройство на своей стороне без каких-либо дополнительных данных преобразует биометрию в какую-то строку, которую потом передаёт сервису аутентификации, то безопасность такого решения получается даже хуже, чем авторизация по паролю. Даже если строка уникальна для каждого запроса, это не решит проблему — в таком случае в бд скорее всего придётся хранить строку, по которой можно сгенерировать такую строку для авторизации для любого запроса на любом другом сервисе, использующем тот же механизм. И подделать такой запрос, минуя само устройство, вычисляющее такую строку.
>наиболее надёжным видом беспарольной аутентификации считается вход с помощью биометрических технологий
Есть два нюанса. 1. Нельзя пошарить доступ к сервису. Нельзя завести учётку для всей семьи, не сканируя биометрию каждого члена семьи. Нельзя завести общую корпоративную readonly-учётку на весь отдел. При авторизации по паролю я могу дать доверенному лицу логин и пароль. А при авторизации по биометрии что делать? Палец отсылать почтой? А что будет с моими данными после моей смерти? При авторизации по паролю доверенные люди могут получить список моих критичных логинов и паролей. 2. Пароль в случае утечки можно сменить. Биометрию сменить не получится. Если какой-то сервис сольёт информацию, из которой можно будет слепить правдоподобный запрос на аутентификацию, пользователи окажутся беззащитными на множестве других сервисов, использующих такой же метод аутентификации.
А для магазина идеально будет, если читатель решит купить оба девайса, и в зависимости от задачи доставать то или иное с полки.
Ну и в целом, думаю, ни GPT, ни авторы блогов не возьмут на себя ответственность сказать пользователям что-то наподобие: "Бери браслет, часы тебе не нужны". GPT вообще максимально старается скинуть с себя ответственность, постоянно применяя фразы типа: "Все варианты хороши, выбирайте сами под свои потребности", — что в целом хорошо подходит корпоративным блогам.
>получает "вам товар нужен..." Было бы странно, если бы в блоге магазина были рекомендации "не покупайте этот товар, он вам не нужен" :) Тащемта, магазину блог, наверное, как раз для того, чтобы в каждой статье о товаре ответ был однозначным "покупайте, не пожалеете".
Человек, чьё хобби может быть связано с применением мотозапчастей. От конструирования инвалидной коляски с ДВС до применения каких-нибудь масел и расходников не по ожидаемому назначению.
Иронично, но прямо над фразой "Вы думаете, что у вас нет таких клиентов?" нарисован человечек за рулём с подписью "Вождение".
Не нашёл ни одной ссылки на приложение на ресурсах Сбера (может, плохо искал) TLS-сертификат сайта никак со сбером не связан. Разработчик — юрлицо с уставным капиталом в 10к рублей. И до кучи Сбер уже отрицал, что такое название будет использовано.
И как этому приложению верить? Откуда мне знать, что оно не передаст какой-нибудь токен, полученный после авторизации, для выполнения несанкционированных действий третьими лицами, прикинувшись официальным (и даже возможно будучи собранным из каких-нибудь слитых источников)?
ВТБ этот вопрос решало проще: публиковало ссылку на приложение на главной странице веб-интерфейса онлайн-банка. А тут вообще никаких официальных подтверждений. А потом, если что случится, сбер не скажет "ну вы сами виноваты"?
Во время конкурса, кстати, отдал голос первому балкону, потому что помню статью о его постройке, а второму «за компанию», чтобы скорее и про него прочитать. Так что авторитет и узнаваемость имеет значение, лояльность хоть немножко, да помогла :)
Справедливости ради, другие рабочие места, за которые я голосовал, были не менее интересными, хоть и без истории, но в топ не попали.
В общем, надеюсь, что не зря голосовал, и пост про балкон 2.0 уже на горизонте.
Сколько видел разных розыгрышей-голосований (и как зритель, и как участник, и как организатор) везде одна и та же проблема: накрутки и борьба с ними. Причем, какой бы ни была борьба, стопроцентно гарантировать, что вычислив все накрученные голоса, ни один честный голос не обвинили напрасно, не получится.
Но при этом логично, что сменив модель с открытого голосования на выбор жюри, теряется охват: меньше людей приведут своих знакомых или подписчиков своих каналов в конкурс и рекламный компонент будет не так эффективен. Так что жаловаться на накрутки в конкурсах с такой моделью как-то странно: подводные камни и так очевидны, вы сами выбрали этот путь. Хотя, как мне кажется, плойка — не такая ценность, чтобы ради неё покупать накрутки, тем более, что у многих участников она наверняка есть.
Отдельный момент, конечно, это сам элемент состязания: когда решают только голоса, получается, что аудитория участника имеет намного большее значение, чем его рабочее место.
>Да.
Тогда происходящее выглядит каким-то натуральным вредительством. Сломали систему выдачи сертификатов по CSR, и не объясняют происходящее. Это сложно объяснить человеческой ошибкой или глупостью, поскольку видны намеренные шаги по отключению такого функционала, и остается только вариант с недобросовестным поведением. Спасибо. Из статьи было не совсем очевидно, сломали ли они это или просто не запилили, вкрутив тупую заглушку.
>Вы имеете ввиду
Исключительно поддержку. С продажниками не особо контактировал и уже не очень помню, занимались ли они выпуском сертификатов на токенах. Но помню, что периодически приходилось это делать, в том числе, в рамках установки ПО на оборудование клиентов. Видимо, в разных компаниях очень разный подход к тому, что должны знать сотрудники.
А раньше схема с CSR работала исправно, и лишь в декабре обнаружилось, что подобный функционал перестал работать?
Грустно это все. С одной стороны, вероятно, затруднения у разработчиков и, возможно, отсутствие средств на разработку необходимого ПО (грубо говоря, непонятно, кто оплатит разработку пресловутого единого инструмента). С другой, оно действительно нужно небольшому количеству организаций, хотя они, вероятно, являются очень крупными налогоплательщиками. У меня вот юрлицо обслуживается бухгалтером на аутсорсе, и про мои просьбы дать копии сертификатов (один на физлицо, которым подписывалось заявление в налоговую/минюст, второй на юрлицо) почему-то в обслуживающей компании забывают. Не скажу, чтобы мне они очень были нужны, но «осадочек остался». Будь у меня больше оборот, я не стал бы делегировать подобные задачи на аутсорс и предпочел бы единолично владеть закрытыми ключами. Представить, как ведет документооборот крупный бизнес с такими сертификатами, вообще сложно.
>Что такое ЭП и как она работает не понимают даже работники УЦ.
А вот тут я не соглашусь. Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ (в т.ч. работали студенты) и отличия ГОСТ 34.10.2001 (тогда еще) от RSA многие знали. Хотя, полагаю, наше высшее руководство не сильно в этом разбиралось.
Когда-то давно работал у партнеров сервиса, разрабатывающего аналогичное СБИСу ПО. Формально, у нас была инструкция, по которой мы генерировали ключевую пару, записывая ее сразу на токен без права ее копировать. Не уверен, что была возможность извлечь потом сертификат и сохранить у себя, однако исключать подобное я не могу. С тех пор прошло почти девять лет, а воз и нынче там: УЦ генерируют ключи и передают клиентам.
Мне тоже до сих пор непонятна логика, по которой недопустимо генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ. Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют (причем, судя по статье, зачастую безальтернативно), буду рад.
Есть кейсы, когда неудобный подход все-таки побеждает.
Если штрафы поднимут, количество нарушений сократится, и в целом станет чуть безопаснее. Если полицейским (ДПС и аналогам) разрешить ходить в штатском при исполнении и останавливать при этом нарушителей, станет еще безопаснее, и люди будут готовы и по десять минут ждать на светофоре, лишь бы не получить непосильный штраф.
Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности.
Не стоит недооценивать систему штрафов, она отлично навязывает привычки независимо от того, несут ли они полезную для человека функцию. Добиться приемлемого результата в определенной области таким образом можно. Но тогда возникнут проблемы другого характера, например, текучка кадров, особенно, невысокой квалификации или разного рода «итальянские забастовки». Локальная цель выполнена, безопасность возросла. Глобальная цель отдалилась – бизнес начинает тормозить. К сожалению, до сих пор много руководителей, особенно, низшего звена, которые не осознают подобные риски.
PS: А ещё есть отдельная группа менеджеров, которые навязывают небезопасные и неудобные решения, но это уже совсем грустный вариант.
Предположу, что рассматривать безопасность/удобство следует в контексте третьего фактора – затратность.
Как принято считать, что не бывает одновременно быстро, дешево и качественно, так же и в вышеописанных случаях не может быть одновременно безопасно, удобно и экономично.
На исследование удобных таймингов светофора нужно, как минимум, время, а как максимум, еще и деньги на привлечение сторонних аналитиков, проводящих тесты разных настроек в разное время суток.
На модернизацию инструмента безопасности нужно время. Если инструмент делают на аутсорсе, тоже понадобятся деньги.
На внедрение менеджера паролей тоже потребуется время – пользователей нужно обучать и приучать.
Таким образом, да, бесспорно, можно сделать безопасно и удобно, но это непременно потребует дополнительных затрат. И зачастую ресурсов на покрытие этих затрат у заказчика нет. Дорожникам некогда следить за светофорами на маленьких улочках, им еще новые в эксплуатацию вводить (а обосновать наем новых сотрудников, которые дадут результат, незаметный для человека, не обладающего статистикой, будет довольно трудно). Заборы поставить проще, хотя эффективность их давно под сомнением. С паролями и уязвимостями в коде аналогично: не всякий бизнес может себе позволить вложиться в подобные решения, когда у специалистов и так полно профильных задач. Потому и потери средств мы можем предотвратить, пожертвовав либо временем и/или деньгами, или удобством. Да, в конечном счете при повышении удобства вырастет и безопасность, но все-таки цена вопроса имеет для многих немалое значение.
Разных code-conventions много, но такие, где были бы еще и аргументы по каждому требованию — это редкость. А предложенное в статье выделяется из общей массы лишь тем, что местами противоречит PSR. Возникает очень много «почему» практически по каждому пункту.
Полагаю, нужно чуть глубже копнуть в суть стеганографии (хотя бы сферической в вакууме): пользователи скрывают не только (и не столько) шифрованный трафик, сколько сам факт обмена этим трафиком. Вот сидят два условных гика, обмениваются смешными картиночками, и не привлекают особого внимания, а на деле один кидает другому секретные чертежи. И идеальная стеганография не сможет стать причиной пристального внимания к кому-либо, поскольку действия условного гика не будут отличаться от привычной активности среднего пользователя в сети.
Да, можно предположить, что пользоваться этими методами будут только полтора гика. Но это определенно приведет нас к дискуссии на тему «Честному гражданину нечего скрывать – честному государству незачем лезть в частную жизнь»
Так что из происходящего, особенно, если предположить, что Казахстан был тестовой площадкой для подобного закона, вполне логично вытекает такой алгоритм:
1. Ввести ограничения, которые не будут выполнять многие зарубежные сервисы.
2. Запретить зарубежный трафик без разрешительной бумажки.
3. Обязать весь внутренний трафик шифровать сертификатами от государства со стороны сервера. Неугодные серверы закрывать. По фактам обнаружения трафика, который нельзя расшифровать, высылать сотрудников.
Но даже при таком раскладе стеганографию никто не сможет запретить.
Поддерживаю отказ от FB или хотя бы использование нескольких соцсетей.
Во-первых, трудности при влюченной блокировке трекеров — в админку залогиниться не даст.
Во-вторых, игроков через соцсети порой бывает трудно завести в игру. У некоторых даже принципиально нет аккаунтов. А играть-то хочется.
Да, с паролями и хэшами велосипед изобретать не надо — нехэшированный пароль отправляется сервису, сервис хэширует его (предварительно добавив соль, конечно же) и сверяет с имеющимся в базе хэшем. Ключевой момент — пароль не хэшируется на стороне клиента. Иначе, если клиент сделает один хэш с одной солью, а сервис другой хэш с другой солью — хэши, ожидаемо, не сойдутся. А если хэшироваться пароли будут одинаково — модификация клиента может позволить подставлять условно слитый хэш, не генерируя его из пароля.
В случае компрометации пароля, в т.ч. при выявлении подозрительной попытки входа, пользователь меняет пароль. Иногда и сервис может сделать это принудительно. Поэтому нехэшированный пароль можно смело слать, доверяя только https. Ибо одно из главных правил: один сервис — один пароль. Даже если пароль утечёт, он будет критичен для одного сервиса (если пользователь молодец)
А что делать, если внезапно обнаружится утечка логов, в которых оказались нехэшированные биометрические клиентские данные? Мы ведь в таком случае вынуждены слать строку без хэша. Или сервис сообщит, что стал жертвой атаки, в ходе которой запросы перехватывались и отправлялись злоумышленникам? Или клиент станет жертвой атаки MitM-атаки с подменой сертификата (Минсвязи Казахстана и Минцифры РФ передают приветы и напоминают о своих корневых сертах), и биометрия будет сохранена на стороне посредника? Что в таком случае делать?
Альтернатива — хэшированные на клиенте данные вида "биометрия+timestamp", дабы запрос нельзя было повторить. Но в таком случае придётся хранить сырые данные на стороне сервиса.
Ну это примерно похоже на авторизацию в приложениях банков, да и многих других приложениях. Аутентификация в самом приложении создаёт токен, сохраняемый на клиенте, но без биометрии (или ввода пин-кода) нельзя этим токеном воспользоваться.
Впрочем, повторная аутентификация в таком приложении всё равно потребует ввода пароля и/или кода из смс и ещё 2fa-кода. Например, при смене устройства и невозможности переноса данных с прошлого.
Однако я процитирую статью:
>Если устройство или биометрия соответствуют информации в базе данных, то пользователь получает разрешение на доступ.
Если я правильно понимаю автора, речь о том, что биометрия хранится в базе данных. На стороне сервиса. И тогда получается, что сервис аутентификации будет сверять какие-то данные от устройства, считывающего биометрию, с той биометрией, что он хранит у себя в базе. Таким образом, получается, что для аутентификации нужна вовсе не строка, созданная с использование ключевой пары, а именно строка, созданная с помощью биометрии.
Если устройство хранит у себя ключ, доступ к которому есть только по биометрии — это один сценарий. Утеря устройства в таком случае приведёт к утере доступа, как уже писали в соседнем комменте.
А вот если устройство на своей стороне без каких-либо дополнительных данных преобразует биометрию в какую-то строку, которую потом передаёт сервису аутентификации, то безопасность такого решения получается даже хуже, чем авторизация по паролю. Даже если строка уникальна для каждого запроса, это не решит проблему — в таком случае в бд скорее всего придётся хранить строку, по которой можно сгенерировать такую строку для авторизации для любого запроса на любом другом сервисе, использующем тот же механизм. И подделать такой запрос, минуя само устройство, вычисляющее такую строку.
>наиболее надёжным видом беспарольной аутентификации считается вход с помощью биометрических технологий
Есть два нюанса.
1. Нельзя пошарить доступ к сервису. Нельзя завести учётку для всей семьи, не сканируя биометрию каждого члена семьи. Нельзя завести общую корпоративную readonly-учётку на весь отдел. При авторизации по паролю я могу дать доверенному лицу логин и пароль. А при авторизации по биометрии что делать? Палец отсылать почтой? А что будет с моими данными после моей смерти? При авторизации по паролю доверенные люди могут получить список моих критичных логинов и паролей.
2. Пароль в случае утечки можно сменить. Биометрию сменить не получится. Если какой-то сервис сольёт информацию, из которой можно будет слепить правдоподобный запрос на аутентификацию, пользователи окажутся беззащитными на множестве других сервисов, использующих такой же метод аутентификации.
А для магазина идеально будет, если читатель решит купить оба девайса, и в зависимости от задачи доставать то или иное с полки.
Ну и в целом, думаю, ни GPT, ни авторы блогов не возьмут на себя ответственность сказать пользователям что-то наподобие: "Бери браслет, часы тебе не нужны". GPT вообще максимально старается скинуть с себя ответственность, постоянно применяя фразы типа: "Все варианты хороши, выбирайте сами под свои потребности", — что в целом хорошо подходит корпоративным блогам.
>получает "вам товар нужен..."
Было бы странно, если бы в блоге магазина были рекомендации "не покупайте этот товар, он вам не нужен" :)
Тащемта, магазину блог, наверное, как раз для того, чтобы в каждой статье о товаре ответ был однозначным "покупайте, не пожалеете".
Многим сервисам это не подойдёт. Например, тем, у кого хотя бы часть пользователей никак не связана с РФ.
Человек, чьё хобби может быть связано с применением мотозапчастей. От конструирования инвалидной коляски с ДВС до применения каких-нибудь масел и расходников не по ожидаемому назначению.
Иронично, но прямо над фразой "Вы думаете, что у вас нет таких клиентов?" нарисован человечек за рулём с подписью "Вождение".
Не нашёл ни одной ссылки на приложение на ресурсах Сбера (может, плохо искал)
TLS-сертификат сайта никак со сбером не связан. Разработчик — юрлицо с уставным капиталом в 10к рублей.
И до кучи Сбер уже отрицал, что такое название будет использовано.
И как этому приложению верить? Откуда мне знать, что оно не передаст какой-нибудь токен, полученный после авторизации, для выполнения несанкционированных действий третьими лицами, прикинувшись официальным (и даже возможно будучи собранным из каких-нибудь слитых источников)?
ВТБ этот вопрос решало проще: публиковало ссылку на приложение на главной странице веб-интерфейса онлайн-банка. А тут вообще никаких официальных подтверждений. А потом, если что случится, сбер не скажет "ну вы сами виноваты"?
Справедливости ради, другие рабочие места, за которые я голосовал, были не менее интересными, хоть и без истории, но в топ не попали.
В общем, надеюсь, что не зря голосовал, и пост про балкон 2.0 уже на горизонте.
Но при этом логично, что сменив модель с открытого голосования на выбор жюри, теряется охват: меньше людей приведут своих знакомых или подписчиков своих каналов в конкурс и рекламный компонент будет не так эффективен. Так что жаловаться на накрутки в конкурсах с такой моделью как-то странно: подводные камни и так очевидны, вы сами выбрали этот путь. Хотя, как мне кажется, плойка — не такая ценность, чтобы ради неё покупать накрутки, тем более, что у многих участников она наверняка есть.
Отдельный момент, конечно, это сам элемент состязания: когда решают только голоса, получается, что аудитория участника имеет намного большее значение, чем его рабочее место.
Тогда происходящее выглядит каким-то натуральным вредительством. Сломали систему выдачи сертификатов по CSR, и не объясняют происходящее. Это сложно объяснить человеческой ошибкой или глупостью, поскольку видны намеренные шаги по отключению такого функционала, и остается только вариант с недобросовестным поведением. Спасибо. Из статьи было не совсем очевидно, сломали ли они это или просто не запилили, вкрутив тупую заглушку.
>Вы имеете ввиду
Исключительно поддержку. С продажниками не особо контактировал и уже не очень помню, занимались ли они выпуском сертификатов на токенах. Но помню, что периодически приходилось это делать, в том числе, в рамках установки ПО на оборудование клиентов. Видимо, в разных компаниях очень разный подход к тому, что должны знать сотрудники.
Грустно это все. С одной стороны, вероятно, затруднения у разработчиков и, возможно, отсутствие средств на разработку необходимого ПО (грубо говоря, непонятно, кто оплатит разработку пресловутого единого инструмента). С другой, оно действительно нужно небольшому количеству организаций, хотя они, вероятно, являются очень крупными налогоплательщиками. У меня вот юрлицо обслуживается бухгалтером на аутсорсе, и про мои просьбы дать копии сертификатов (один на физлицо, которым подписывалось заявление в налоговую/минюст, второй на юрлицо) почему-то в обслуживающей компании забывают. Не скажу, чтобы мне они очень были нужны, но «осадочек остался». Будь у меня больше оборот, я не стал бы делегировать подобные задачи на аутсорс и предпочел бы единолично владеть закрытыми ключами. Представить, как ведет документооборот крупный бизнес с такими сертификатами, вообще сложно.
>Что такое ЭП и как она работает не понимают даже работники УЦ.
А вот тут я не соглашусь. Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ (в т.ч. работали студенты) и отличия ГОСТ 34.10.2001 (тогда еще) от RSA многие знали. Хотя, полагаю, наше высшее руководство не сильно в этом разбиралось.
Мне тоже до сих пор непонятна логика, по которой недопустимо генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ. Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют (причем, судя по статье, зачастую безальтернативно), буду рад.
Если штрафы поднимут, количество нарушений сократится, и в целом станет чуть безопаснее. Если полицейским (ДПС и аналогам) разрешить ходить в штатском при исполнении и останавливать при этом нарушителей, станет еще безопаснее, и люди будут готовы и по десять минут ждать на светофоре, лишь бы не получить непосильный штраф.
Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности.
Не стоит недооценивать систему штрафов, она отлично навязывает привычки независимо от того, несут ли они полезную для человека функцию. Добиться приемлемого результата в определенной области таким образом можно. Но тогда возникнут проблемы другого характера, например, текучка кадров, особенно, невысокой квалификации или разного рода «итальянские забастовки». Локальная цель выполнена, безопасность возросла. Глобальная цель отдалилась – бизнес начинает тормозить. К сожалению, до сих пор много руководителей, особенно, низшего звена, которые не осознают подобные риски.
PS: А ещё есть отдельная группа менеджеров, которые навязывают небезопасные и неудобные решения, но это уже совсем грустный вариант.
Как принято считать, что не бывает одновременно быстро, дешево и качественно, так же и в вышеописанных случаях не может быть одновременно безопасно, удобно и экономично.
На исследование удобных таймингов светофора нужно, как минимум, время, а как максимум, еще и деньги на привлечение сторонних аналитиков, проводящих тесты разных настроек в разное время суток.
На модернизацию инструмента безопасности нужно время. Если инструмент делают на аутсорсе, тоже понадобятся деньги.
На внедрение менеджера паролей тоже потребуется время – пользователей нужно обучать и приучать.
Таким образом, да, бесспорно, можно сделать безопасно и удобно, но это непременно потребует дополнительных затрат. И зачастую ресурсов на покрытие этих затрат у заказчика нет. Дорожникам некогда следить за светофорами на маленьких улочках, им еще новые в эксплуатацию вводить (а обосновать наем новых сотрудников, которые дадут результат, незаметный для человека, не обладающего статистикой, будет довольно трудно). Заборы поставить проще, хотя эффективность их давно под сомнением. С паролями и уязвимостями в коде аналогично: не всякий бизнес может себе позволить вложиться в подобные решения, когда у специалистов и так полно профильных задач. Потому и потери средств мы можем предотвратить, пожертвовав либо временем и/или деньгами, или удобством. Да, в конечном счете при повышении удобства вырастет и безопасность, но все-таки цена вопроса имеет для многих немалое значение.
Да, можно предположить, что пользоваться этими методами будут только полтора гика. Но это определенно приведет нас к дискуссии на тему «Честному гражданину нечего скрывать – честному государству незачем лезть в частную жизнь»
Так что из происходящего, особенно, если предположить, что Казахстан был тестовой площадкой для подобного закона, вполне логично вытекает такой алгоритм:
1. Ввести ограничения, которые не будут выполнять многие зарубежные сервисы.
2. Запретить зарубежный трафик без разрешительной бумажки.
3. Обязать весь внутренний трафик шифровать сертификатами от государства со стороны сервера. Неугодные серверы закрывать. По фактам обнаружения трафика, который нельзя расшифровать, высылать сотрудников.
Но даже при таком раскладе стеганографию никто не сможет запретить.
Во-первых, трудности при влюченной блокировке трекеров — в админку залогиниться не даст.
Во-вторых, игроков через соцсети порой бывает трудно завести в игру. У некоторых даже принципиально нет аккаунтов. А играть-то хочется.