Pull to refresh
3
0
Данис@zojl

User

Send message
А раньше схема с CSR работала исправно, и лишь в декабре обнаружилось, что подобный функционал перестал работать?

Грустно это все. С одной стороны, вероятно, затруднения у разработчиков и, возможно, отсутствие средств на разработку необходимого ПО (грубо говоря, непонятно, кто оплатит разработку пресловутого единого инструмента). С другой, оно действительно нужно небольшому количеству организаций, хотя они, вероятно, являются очень крупными налогоплательщиками. У меня вот юрлицо обслуживается бухгалтером на аутсорсе, и про мои просьбы дать копии сертификатов (один на физлицо, которым подписывалось заявление в налоговую/минюст, второй на юрлицо) почему-то в обслуживающей компании забывают. Не скажу, чтобы мне они очень были нужны, но «осадочек остался». Будь у меня больше оборот, я не стал бы делегировать подобные задачи на аутсорс и предпочел бы единолично владеть закрытыми ключами. Представить, как ведет документооборот крупный бизнес с такими сертификатами, вообще сложно.

>Что такое ЭП и как она работает не понимают даже работники УЦ.
А вот тут я не соглашусь. Мои коллеги в те времена понимали суть, а у некоторых было образование по профилю ИБ (в т.ч. работали студенты) и отличия ГОСТ 34.10.2001 (тогда еще) от RSA многие знали. Хотя, полагаю, наше высшее руководство не сильно в этом разбиралось.
Когда-то давно работал у партнеров сервиса, разрабатывающего аналогичное СБИСу ПО. Формально, у нас была инструкция, по которой мы генерировали ключевую пару, записывая ее сразу на токен без права ее копировать. Не уверен, что была возможность извлечь потом сертификат и сохранить у себя, однако исключать подобное я не могу. С тех пор прошло почти девять лет, а воз и нынче там: УЦ генерируют ключи и передают клиентам.

Мне тоже до сих пор непонятна логика, по которой недопустимо генерировать ключевую пару на стороне клиента и лишь подписывать получившийся сертификат на стороне УЦ. Если кто-нибудь сможет пояснить, почему такой подход до сих пор применяют (причем, судя по статье, зачастую безальтернативно), буду рад.
Есть кейсы, когда неудобный подход все-таки побеждает.
Если штрафы поднимут, количество нарушений сократится, и в целом станет чуть безопаснее. Если полицейским (ДПС и аналогам) разрешить ходить в штатском при исполнении и останавливать при этом нарушителей, станет еще безопаснее, и люди будут готовы и по десять минут ждать на светофоре, лишь бы не получить непосильный штраф.

Аналогично и с бизнесом: если сотрудникам в договоре прописать штраф в размере месячной зарплаты за использование слабого пароля и ненадлежащее его хранение, они будут вынуждены применять неудобные методы обеспечения безопасности.

Не стоит недооценивать систему штрафов, она отлично навязывает привычки независимо от того, несут ли они полезную для человека функцию. Добиться приемлемого результата в определенной области таким образом можно. Но тогда возникнут проблемы другого характера, например, текучка кадров, особенно, невысокой квалификации или разного рода «итальянские забастовки». Локальная цель выполнена, безопасность возросла. Глобальная цель отдалилась – бизнес начинает тормозить. К сожалению, до сих пор много руководителей, особенно, низшего звена, которые не осознают подобные риски.

PS: А ещё есть отдельная группа менеджеров, которые навязывают небезопасные и неудобные решения, но это уже совсем грустный вариант.
Предположу, что рассматривать безопасность/удобство следует в контексте третьего фактора – затратность.

Как принято считать, что не бывает одновременно быстро, дешево и качественно, так же и в вышеописанных случаях не может быть одновременно безопасно, удобно и экономично.
На исследование удобных таймингов светофора нужно, как минимум, время, а как максимум, еще и деньги на привлечение сторонних аналитиков, проводящих тесты разных настроек в разное время суток.
На модернизацию инструмента безопасности нужно время. Если инструмент делают на аутсорсе, тоже понадобятся деньги.
На внедрение менеджера паролей тоже потребуется время – пользователей нужно обучать и приучать.

Таким образом, да, бесспорно, можно сделать безопасно и удобно, но это непременно потребует дополнительных затрат. И зачастую ресурсов на покрытие этих затрат у заказчика нет. Дорожникам некогда следить за светофорами на маленьких улочках, им еще новые в эксплуатацию вводить (а обосновать наем новых сотрудников, которые дадут результат, незаметный для человека, не обладающего статистикой, будет довольно трудно). Заборы поставить проще, хотя эффективность их давно под сомнением. С паролями и уязвимостями в коде аналогично: не всякий бизнес может себе позволить вложиться в подобные решения, когда у специалистов и так полно профильных задач. Потому и потери средств мы можем предотвратить, пожертвовав либо временем и/или деньгами, или удобством. Да, в конечном счете при повышении удобства вырастет и безопасность, но все-таки цена вопроса имеет для многих немалое значение.
Разных code-conventions много, но такие, где были бы еще и аргументы по каждому требованию — это редкость. А предложенное в статье выделяется из общей массы лишь тем, что местами противоречит PSR. Возникает очень много «почему» практически по каждому пункту.
Полагаю, нужно чуть глубже копнуть в суть стеганографии (хотя бы сферической в вакууме): пользователи скрывают не только (и не столько) шифрованный трафик, сколько сам факт обмена этим трафиком. Вот сидят два условных гика, обмениваются смешными картиночками, и не привлекают особого внимания, а на деле один кидает другому секретные чертежи. И идеальная стеганография не сможет стать причиной пристального внимания к кому-либо, поскольку действия условного гика не будут отличаться от привычной активности среднего пользователя в сети.

Да, можно предположить, что пользоваться этими методами будут только полтора гика. Но это определенно приведет нас к дискуссии на тему «Честному гражданину нечего скрывать – честному государству незачем лезть в частную жизнь»
Почти полгода, как сертификаты отменили.

Так что из происходящего, особенно, если предположить, что Казахстан был тестовой площадкой для подобного закона, вполне логично вытекает такой алгоритм:
1. Ввести ограничения, которые не будут выполнять многие зарубежные сервисы.
2. Запретить зарубежный трафик без разрешительной бумажки.
3. Обязать весь внутренний трафик шифровать сертификатами от государства со стороны сервера. Неугодные серверы закрывать. По фактам обнаружения трафика, который нельзя расшифровать, высылать сотрудников.
Но даже при таком раскладе стеганографию никто не сможет запретить.
Поддерживаю отказ от FB или хотя бы использование нескольких соцсетей.
Во-первых, трудности при влюченной блокировке трекеров — в админку залогиниться не даст.
Во-вторых, игроков через соцсети порой бывает трудно завести в игру. У некоторых даже принципиально нет аккаунтов. А играть-то хочется.
Я бы скорее предположил, что это какое-то относительно хитрое колдунство с перенаправлением внутреннего трафика на стороне роутера.
Например, микротики довольно спокойно можно так настроить одним правилом в разделе Firewall NAT. Такое бывает, когда пользователь пытается пробросить порт наружу и сделать устройство внутри сети доступным по внешнему адресу как снаружи, так и изнутри сети. Иногда что-то идёт не так, правило составляют с ошибкой и, в лучшем случае, лишь проверяют, работает ли нечто ожидаемое, забыв проверить, не поломали ли чего-нибудь другого.
Есть, что скрывать.

Примеры:
  • У меня есть доступ с личных компьютеров к сведениям под NDA. Специфика работы по фрилансу над некоторыми проектами.
  • Иногда друзья обращаются ко мне с просьбами или советами и просят не раскрывать полученную информацию никому. Если я обязался не сообщать никому, то «ну уж этому-то человеку можно сказать» недопустимо.

А ещё таким же образом могут получить доступ к почте дети и гости. И хотя у меня пока нет детей, я уверен, что в будущем мне будет, что от них скрывать.

Впрочем, я вижу в этом комментарии перевод темы из «это небезопасно» в «безопасность не нужна».
Код может быть шестизначным, и тогда перебор будет ощутимо дольше.
Поставщик смс может отреагировать на массовую отправку смс (а она, как мы знаем, недавно у некоторых подорожала в шесть раз) и после n-ного сообщения сказать: «слишком много запросов, подождите пять минут».

Но, соглашусь, с «невозможно» они переборщили. Вероятность всё-таки ненулевая, хоть и низкая на уровне погрешности.
Легко, соглашусь. Однако, пин-код подсматривается, как мне кажется, проще: пользователь совершает отрывистые нажатия на «клавиши» с чётко определёнными границами, имеющими иногда свойство неотключаемо подсвечиваться после нажатия. Для сравнения, жест при вводе графического ключа, если отключить демонстрацию ввода, выглядит как хаотичное движение пальцем по экрану, в котором опасность представляет только анализ жирового следа.
К тому же, ввод пин-кода от сим-карты нельзя заменить сканированием отпечатка пальца, FaceID или иной биотметрией, которую нельзя атаковать через слежку за пользователем.

>Protonmail <...> сделали возможность авторизации только по одному паролю
Да, причём, где-то полгода-год назад, как мне показалось, и это выглядит логичным: если тип второго фактора авторизации совпадает с типом первого, дополнительную безопасность они обеспечат вместе только для слишком замороченных пользователей.
Как правило, сим-карты в последние года выдаются с пин-кодами 0000 или 1234, выключенными по умолчанию. Большинство пользователей не стремится их включать, поскольку это затягивает процесс включения телефона, но при этом нечасто (пока ещё) даёт эффективную защиту.
В целом, пин-коды — штука легко подбираемая соц. инженерией в бытовых, семейных условиях. Что-то вроде «подглядеть из-за спины», пока партнёр вводит пин-код в перезагруженном злоумышленником телефоне. Графические ключи такую атаку делают более сложной. Но их в сим-карты, к сожалению, не завезли.

Имхо, использовать только смс без пароля — в целом опаснее, чем внедрять пароль без смс, поскольку взломы почт нужны не только незнакомым злоумышленникам, но и знакомым: ревнивым женам/мужьям или завистливым коллегам.
Печальная новость.
Теперь читать почту близких людей будет проще.
Взял телефон спящего супруга/супруги, зашёл в почту. Если телефон заблокирован и не показывает коды в первых строчках уведомлений на главном экране — переставил симку и получил ещё один код для входа.
С кражей паролей бороться было проще: сменил пароль на новый и уникальный, сохранил туда, откуда не утащат, и больше не паришься до следующего слива. С кражей телефонов бороться будет значительно сложнее.
Расскажите, пожалуйста, о сроке жизни на одном аккумуляторе. Сильно падает? Не планируете сделать подсветку отключаемой?

Cам, кстати, тоже являюсь обладателем двух Inch A6i и не перестаю радоваться, хотя, после того, как один разбился при довольно загадочных обстоятельствах, просто лёжа всю ночь в машине, второй пытаться модифицировать жалко. Да и аккумуляторы у обоих уже довольно грустные.
Задеплоить бложик компании на вордпрессе или лендинг с двумя скриптами на PHP иногда проще на шаред хостинге.
Заказчик оплачивает домен и ресурсы сервера в одном месте и не парится даже с добавлением DNS-записей. Аутсорсный разработчик пакует свою работу в архив, заказчик его разворачивает своими руками. В итоге даже на одного программера в штат денег не надо.
Было бы здорово, если бы кто-нибудь из присутствующих на рынке «накрутчиков» в такое умел. А то сейчас большинство берёт деньги за абсолютно бездумный массфоловинг просто по спискам, от которого отдачи очень мало, соответственно, задачу заказчика «а накрутите мне условные 5к подписчиков» они выполняют медленнее, чем могли бы.
Казань, Таттелеком, не работает Pocket (ec2-52-72-69-150.compute-1.amazonaws.com), на который когда-то меня подсадили ребята из Mozilla. Теперь мои закладки (на сайтах) доступны только через прокси.
2

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Бэкенд разработчик