Жалко, что не на известной площадке какой-нибудь для митапов, а вот это всё: > заполняйте анкету регистрации(нужна авторизация ВКонтакте). > ... Мы пригласим вас в закрытую онлайн-комнату
Отдельные выделенные под конкретную задачу сервисы могут иметь свои преимущества перед комбайном. В статье же вы обошли это стороной, но упомянули, что Gitea в целом представляет собой хорошее решение. Вот и хотелось бы чуть более детального сравнения, а не просто "CI/CD с ним был не очень удобен в работе.".
Но эта простота может иметь и обратную сторону. В приложении нет готового CI/CD, и для реализации этих механизмов приходится использовать стороннее решение. В нашем случае у клиента эту роль играл Jenkins, для которого существует специальный плагин. Однако данный выбор был скорее историческим наследием, чем технической необходимостью. CI/CD с ним был не очень удобен в работе. Для оптимизации процесса деплоя мы сошлись на переходе на GitLab, а это означало и замену самой Gitea, функции которой теряли смысл. Также в процессе работ были найдены мелкие проблемы, которые мешали миграции.
Интересно узнать подробности о том, почему связка Gitea + внешний CI/CD (тут Jenkins) оказалась настолько неудобной, что решились на замену всего стека.
Смысл в том, чтобы следовать тому кодексу/этике, который сам выбрал + всегда иметь возможность сказать, что "я попытался постучаться в дверь и уведомить о проблеме". Иначе от недостатка информации может возникнуть подозрение, что и не собирался этого делать: как в этом случае, так и других. То, что дверь не открыли сразу или вообще не открыли, в комментариях вполне обосновано разнесут в более свободной манере речи.
Как показала практика, публикация в открытых источниках - единственный способ добиться от них хоть какой-то реакции.
Это не противоречит и не доказывает обратного тому, что можно соблюсти хотя бы формально нормальный подход с таймлайном, а не сразу "full disclosure" делать. Или уже честно написать в посте, что никакой коммуникации по этим проблемам не было. Но это конечно же зависит от изначальной цели.
Приехали. Платных почтовых сервисов и так немного, так ещё и текущие начали ограничивать :(
К слову, не так уж и давно у Fastmail появились проблемы и с непосредственно австралийскими властями https://fastmail.blog/legal-policy/aabill-and-fastmail/
Здорово, что сделали линуксовую сборку для анализа C#. А почему сразу не упаковать эту джобу, вернее всё необходимое для неё, в отдельный Docker-образ?
Как мы видим, ошибки не найдены, и исполнение задачи прошло успешно, что мы и хотели проверить.
В выводе джобы много мусора, включая плашку копирайта, и нет информации о найденной ошибке...
Давайте всё-таки определимся, что и как мы сравниваем в контексте безопасности. Вероятность и сложность угрозы с физическим доступом к личному устройству просто не сопоставимы с таковыми при получения злонамеренного доступа к учётной записи из-за проблем парольной аутентификации. Особенно в контексте атак на большое количество пользователей и удобства сценария аутентификации для них же.
войти на озон и личный кабинет оператора связи, да.
А также получить доступ (на разном уровне) к куче мессенджеров и других популярных приложений, к кодам банковских приложений и восстановлению аккаунтов на других сервисах, а также просто попробовать тогда и сразу разблокировать устройство, раз уж оно оказалось у вас в руках. При этом я специально выше явным образом обозначил, что:
Но мы конечно принимаем во внимание и такие типы угроз, поэтому следите за нашими анонсами. Будем добавлять больше разных интересных фишек безопасности тут.
Физический доступ к устройству со знанием номера телефона жертвы — это, согласитесь, достаточно серьёзный фактор для реализации угрозы в контексте конкретного человека. Имея такой доступ, вы сможете многое. Но мы конечно принимаем во внимание и такие типы угроз, поэтому следите за нашими анонсами. Будем добавлять больше разных интересных фишек безопасности тут.
Вообще-то, всегда было, что логин, пароль ПЛЮС одноразовый код безопаснее.
Вы правы — чем больше факторов, тем лучше (безопаснее). Но у самого фактора пароля есть длинная и обширная история проблем. В качестве второго фактора в такой схеме обычно используется либо всё тот же СМС-код, либо HOTP/TOTP-решения. У каждого из этих вариантов есть свои плюсы и минусы. Ниже в комментариях я постарался развёрнуто ответить по вопросу развития нашей системы аутентификации.
Ага, а еще бесит тот факт, что для входа на сайт оставили безальтернативный вариант по одноразовому SMS-коду, убрав пару «логин-пароль» в принципе.
Аутентификация с помощью логина и пароля уже давно считается небезопасной сама по себе и требует усиления с помощью 2FA. Если кратко, то человеку сложно придумать уникальный и достаточно стойкий пароль, также как и запомнить его. Парольные менеджеры конечно помогают, но этого не достаточно. Поэтому интернет-индустрия активно исследует и испытывает новые способы аутентификации, в том числе и безпарольные. Например, в рамках известного проекта FIDO2, о котором были материалы тут же на Хабре. Мы поддерживаем это движение и планируем дальше повышать безопасность системы аутентификации.
В современных реалиях при использовании Scrum/Agile моделей важно в каждой команде иметь хотя бы одного человека, который может выступать проводником ваших рекомендаций и «болеть» за безопасность продукта.
А расскажи подробнее, как у вас обычно такой человек проходит путь от "мне интересна и безопасность" до полноценного "чемпиона по безопасности"? Как решается вопрос совмещения этого с его основными обязанностями по работе?
Хорошее выступление и здорово, что сделали текстовую версию. Было бы интересно подробнее узнать про взаимодействие с разработчиками и интеграцию с CI/CD и ревью кода, чтобы не уходить отдельно читать про
SonarQube.
«В своей маркетинговой политике WhatsApp использует слова «сквозное шифрование» как магическое заклинание, которое само по себе должно автоматически обеспечивать безопасность всех коммуникаций. Однако эта технология не может сама по себе гарантировать вам абсолютную конфиденциальность», — продолжает Дуров.
Пока в Телеграме нет этого самого сквозного шифрования для всех чатов по умолчанию, о чём вообще можно говорить?
Жалко, что не на известной площадке какой-нибудь для митапов, а вот это всё:
> заполняйте анкету регистрации (нужна авторизация ВКонтакте).
> ... Мы пригласим вас в закрытую онлайн-комнату
Отдельные выделенные под конкретную задачу сервисы могут иметь свои преимущества перед комбайном. В статье же вы обошли это стороной, но упомянули, что Gitea в целом представляет собой хорошее решение. Вот и хотелось бы чуть более детального сравнения, а не просто "CI/CD с ним был не очень удобен в работе.".
Интересно узнать подробности о том, почему связка Gitea + внешний CI/CD (тут Jenkins) оказалась настолько неудобной, что решились на замену всего стека.
Смысл в том, чтобы следовать тому кодексу/этике, который сам выбрал + всегда иметь возможность сказать, что "я попытался постучаться в дверь и уведомить о проблеме". Иначе от недостатка информации может возникнуть подозрение, что и не собирался этого делать: как в этом случае, так и других. То, что дверь не открыли сразу или вообще не открыли, в комментариях вполне обосновано разнесут в более свободной манере речи.
Это не противоречит и не доказывает обратного тому, что можно соблюсти хотя бы формально нормальный подход с таймлайном, а не сразу "full disclosure" делать. Или уже честно написать в посте, что никакой коммуникации по этим проблемам не было. Но это конечно же зависит от изначальной цели.
Безотносительно опасности находки:
Странно видеть подобный пост в блоге компании
В посте нет упоминания о том, была ли коммуникация с заинтересованными лицами по вопросу исправления описанных уязвимостей
Не то, чтобы прямо понятно, что они будут делать с текущими российскими пользователями.
Приехали. Платных почтовых сервисов и так немного, так ещё и текущие начали ограничивать :(
К слову, не так уж и давно у Fastmail появились проблемы и с непосредственно австралийскими властями https://fastmail.blog/legal-policy/aabill-and-fastmail/
Странно, что не упомянуты (?) чаты в Слаке как вредный отвлекающий фактор. Имхо, похуже отдельных встреч может быть.
Здорово, что сделали линуксовую сборку для анализа C#. А почему сразу не упаковать эту джобу, вернее всё необходимое для неё, в отдельный Docker-образ?
В выводе джобы много мусора, включая плашку копирайта, и нет информации о найденной ошибке...
Давайте всё-таки определимся, что и как мы сравниваем в контексте безопасности. Вероятность и сложность угрозы с физическим доступом к личному устройству просто не сопоставимы с таковыми при получения злонамеренного доступа к учётной записи из-за проблем парольной аутентификации. Особенно в контексте атак на большое количество пользователей и удобства сценария аутентификации для них же.
А также получить доступ (на разном уровне) к куче мессенджеров и других популярных приложений, к кодам банковских приложений и восстановлению аккаунтов на других сервисах, а также просто попробовать тогда и сразу разблокировать устройство, раз уж оно оказалось у вас в руках. При этом я специально выше явным образом обозначил, что:
Давайте, пожалуйста, дискутировать в одном треде. Например в том, что выше. Так будет удобно и нам, и читателям.
Выше ответил касательно физического доступа к телефону.
Физический доступ к устройству со знанием номера телефона жертвы — это, согласитесь, достаточно серьёзный фактор для реализации угрозы в контексте конкретного человека. Имея такой доступ, вы сможете многое. Но мы конечно принимаем во внимание и такие типы угроз, поэтому следите за нашими анонсами. Будем добавлять больше разных интересных фишек безопасности тут.
Вы правы — чем больше факторов, тем лучше (безопаснее). Но у самого фактора пароля есть длинная и обширная история проблем. В качестве второго фактора в такой схеме обычно используется либо всё тот же СМС-код, либо HOTP/TOTP-решения. У каждого из этих вариантов есть свои плюсы и минусы. Ниже в комментариях я постарался развёрнуто ответить по вопросу развития нашей системы аутентификации.
Аутентификация с помощью логина и пароля уже давно считается небезопасной сама по себе и требует усиления с помощью 2FA. Если кратко, то человеку сложно придумать уникальный и достаточно стойкий пароль, также как и запомнить его. Парольные менеджеры конечно помогают, но этого не достаточно. Поэтому интернет-индустрия активно исследует и испытывает новые способы аутентификации, в том числе и безпарольные. Например, в рамках известного проекта FIDO2, о котором были материалы тут же на Хабре. Мы поддерживаем это движение и планируем дальше повышать безопасность системы аутентификации.
Хорошая статья!
А расскажи подробнее, как у вас обычно такой человек проходит путь от "мне интересна и безопасность" до полноценного "чемпиона по безопасности"? Как решается вопрос совмещения этого с его основными обязанностями по работе?
А как там история с nginx? Отстали?
Хорошее выступление и здорово, что сделали текстовую версию. Было бы интересно подробнее узнать про взаимодействие с разработчиками и интеграцию с CI/CD и ревью кода, чтобы не уходить отдельно читать про
SonarQube.
Пока в Телеграме нет этого самого сквозного шифрования для всех чатов по умолчанию, о чём вообще можно говорить?