Жалко, что не на известной площадке какой-нибудь для митапов, а вот это всё: > заполняйте анкету регистрации(нужна авторизация ВКонтакте). > ... Мы пригласим вас в закрытую онлайн-комнату
Отдельные выделенные под конкретную задачу сервисы могут иметь свои преимущества перед комбайном. В статье же вы обошли это стороной, но упомянули, что 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.
Странно, что ничего не сказано про лицензию будущего проекта.
Жалко, что не на известной площадке какой-нибудь для митапов, а вот это всё:
> заполняйте анкету регистрации (нужна авторизация ВКонтакте).
> ... Мы пригласим вас в закрытую онлайн-комнату
Отдельные выделенные под конкретную задачу сервисы могут иметь свои преимущества перед комбайном. В статье же вы обошли это стороной, но упомянули, что 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.