Ага. Уже забыли про баг в Debian OpenSSL, из-за которого приватные ключи созданные на этой системе на протяжении полутора лет можно легко взломать? Чистый линух, не подключенный к сети, да. И это мы ещё не начинали смотреть в сторону закладок в железе.

Никакого убытка — если заранее создать несколько subkey и сертификаты отзыва, то дальше наличие мастер-ключа не требуется (пока все subkey не будут отозваны, что довольно маловероятно, и в Вашей схеме работает точно так же).

Так что ответ на вопрос "зачем" тривиален: лень. Никакого смысла в его уничтожении нет, так чего ради напрягаться? А на самом деле его не уничтожают потому, что его наличие позволяет избежать суматохи при создании начальных ключей — достаточно создать один subkey для ежедневного использования и положить master в сейф. Если когда-нибудь потребуется отозвать этот subkey и/или создать новый — это можно будет сделать тогда, когда в этом будет необходимость.

Никто не говорит что Ваша схема не работает, она работает, просто непонятно, какой в ней смысл и в чём её преимущество по сравнению с уже имеющейся.

Просто потому, что в его уничтожении нет никакого смысла. Ну или Вы пока этот смысл не смогли объяснить.

Все Ваши сценарии, которые не "экзотика" отлично решаются через PGP subkey и те же сертификаты аннулирования. Мастер-ключ при этом может лежать где-то в сейфе, острой необходимости его уничтожать через секунду после создания в этих сценариях — нет.

А в чём смысл его уничтожать? У Вас есть возможность создавать новые ключи, подписав их a-key. И эти новые ключи ничем (кроме длины цепочки, которая никак не учитывается) не отличаются от подписанных i-key.

Ещё не прояснён вопрос с тем, как именно отзываются ключи. Учитывая, что i-key удалён, надо полагать что для отзыва a-key1 нужен сам a-key1. Но ведь его могли забрать, а не скопировать (если у юзера нет бэкапов). И получается, что не имея украденного a-key1 юзер даже не сможет его отозвать. Был бы i-key — можно было бы отозвать его подпись для a-key1, но его удалили.

В общем, что такого нового и уникального даёт описанный подход — неясно. Всё крутится вокруг недоказуемости факта существования других ключей, но тут такое дело, если уже дошло до криптоанализа через паяльник — большинство сдаст все свои нычки с ключами а потом сдохнет, потому что паяльник будут использовать до последнего "а вдруг ещё одна нычка есть?"… а меньшинство сможет убедить что от стресса действительно забыли пароль от единственного ключа, или что единственный пароль был на флешке, которую специально сломали в момент нападения.

В этом есть доля истины, но на практике не зря используют многоуровневые защиты — если пробили один уровень это даёт какой-то доступ, но вовсе не обязательно полный. Если каким-то образом получили возможность читать любые файлы юзера (включая файлы в ~/.ssh/), это ещё не означает возможность запустить кейлоггер.

Ну будете вы три дня пароль подбирать вместо пары часов — велика ли разница?

На самом деле разница довольно велика — у Argon2 скорость порядка 100/сек, а у MD5 порядка 10-100 миллиардов/сек. Это разница в 9 порядков, превращающая 1-секундный взлом MD5 в 30 лет.

Ну, как я понял из доки, не столько быть ssh-agent, сколько управлять им — добавлять в него ключи из базы и удалять их по таймауту/закрытию базы. В принципе, это выглядит неплохой идеей (правда, только для десктопа).

Мне никогда не нравилась идея открыть доступ к KeePass сторонним приложениям (вроде KeeFox). Начиная с того, что они работают с KeePass по сети (пусть даже через localhost или unix-сокет, но это значит что любое приложение запущенное на этой машине тоже может подключиться), и заканчивая тем, что пользователь теряет контроль над тем, когда и какие именно пароли запрашиваются из KeePass.

Я предпочитаю чтобы плагин в браузере просто изменял заголовок окна браузера так, чтобы KeePass мог сам автоматически подобрать подходящую запись и передать пароль в окно браузера самостоятельно. Да тоже не фонтан, текущая страница может попробовать подменить заголовок окна именно в тот момент, когда я активирую горячей кнопкой KeePass (чтобы получить пароль от другого сайта), плюс иногда передаваемые KeePass символы пароля попадают не в строку ввода пароля, а куда попало. Но, всё-равно, как по мне этот способ безопаснее.

Подход именно такой, но я писал о том, что в пункте 5 нет никакого смысла создавать отдельный тикет, фиксить это надо в рамках исходной задачи — собственно, пока ветка этой задачи не смержена (а мерж автоматом блокируется если не проходят тесты) — задача не считается закрытой, так что все работы до мержа продолжаются в её рамках.

Так ведь и в том, как они пароли хранят, уверенности тоже никакой нет.

А чего просто пароль не продублировать? По логике вещей, секретный вопрос/ответ это просто альтернативный пароль, можно войти через пароль, а можно через этот секретный вопрос/ответ. Вменяемый сервис должен хранить ответы на секретные вопросы точно так же, как пароли (т.е. в виде хеша, а не открытым текстом). Используя что-то отличное от пароля в ответе на секретный вопросы Вы, зачем-то, создаёте два способа войти в аккаунт, при этом лично Вам нужен и полезен только один из них — доступ к своему KeePass.

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

В схеме в этом месте речь об открытом pull/merge-request. Т.е. создали фиче-бранч под таску, написали кода и тестов, сделали git push на гитхаб, CI по этому пушу запустил тесты, которые провалились. Кто-то действительно в этот момент будет создавать отдельную таску "пофиксить проваливающиеся автотесты"?

Ещё один момент — совершенно не обязательно ограничиваться бесплатными продуктами при сборке pipeline. Многие могут захотеть держать код в приватных репо на гитхабе, или собирать в CircleCI.

У DevOps полно задач помимо контроля площадок: настройка конфигурации с которой запускается проект на разных площадках, управление всяческими ключами/паролями, масштабирование, оптимизация CI по скорости сборки, подготовка и обновление базовых образов докера используемых приложением, etc.

Что до Security Engineer, то на схеме отсутствует основная точка, где необходимо контролировать наличие уязвимостей — ревью кода на pull/merge request. Плюс есть такая штука как архитектурные уязвимости, поэтому крайне желательно дополнительное ревью ТЗ между этапами его написания и декомпозиции задач разработчикам. Причём, по моему опыту, зачастую в проектах нет ресурсов на отдельный этап "Обнаружение уязвимостей" перед релизом, но есть возможность контролировать их на ревью в описанном мной стиле.

"commit кода в репозиторий" →
"Запуск автотестов" →
"Информировании о получении неудовлетворительного результата" →
"Заведение task'а на исправление"

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

"code-review (ручное)" →
"Получение положительного результата"

А что, отрицательного на ваших ревью не бывает? Это вообще основная проблема схемы — в каких-то местах она избыточно (и некорректно) детальна, а в других местах отсутствует масса негативных веток (скорее всего потому, что они бы дико усложнили схему — вроде отмены фичи или переделки ТЗ в связи с фактами проявившимися в процессе реализации). Но Вы ведь вроде бы сервис хотите сделать, так вот сервис как раз такие ситуации учитывать обязан.

"merge кода из feature в dev" →
"запуск автотестов"

Пустая трата времени, тесты этого коммита уже выполнились перед ревью.

"merge кода из release в master" →
"Заведение task'а на создание документации"

Плохая привычка, документацию нужно писать одновременно с кодом, и, в идеале, мержить в том же PR что и фичу.

Ещё одна плохая привычка — наделять ветку master конкретным смыслом. В таких схемах лучше использовать названия веток по их сути (feature, dev, staging, pre-prod, prod), потому что в разных проектах ветка master может быть синонимом любой из них (кроме feature).

Из важных этапов пропущена одна нетривиальная тема: миграции БД. Ещё пропущены сложные задачи постепенного (с обновлением только части узлов) выката новой версии на prod и откат prod при проблемах (что может потребовать отката и миграции БД).

Постановка задач, хранение кода и артефактов, task-tracker — Gitlab, Redmine, S3

Redmine это кошмар, лучше посмотрите на Youtrack — я с ним работал мало, но по первому впечатлению это самый юзабельный трекер из имеющихся в данный момент (если не считать гитхабовского, но он не очень подходит если в проекте несколько репо и с трекером должны активно работать менеджеры и бизнес).

Кстати, а как вы смотрите на то, если в рамках платформы будет
возможность выбора — захотел, выбрал Jenkins, не захотел — GitLab Runner?

Очень положительно. А ещё лучше, чтобы из коробки был именно GitLab Runner, а не Jenkins.

Или же не важно, что внутри, главное, чтобы всё как надо билдилось, тестилось и деплоилось?

Может, когда-нибудь, в далёком будущем, когда оно будет работать как часы. А пока всё это продолжает создавать проблемы лучше понимать, что под капотом и иметь возможность это фиксить.

"Мерж dev в release" →
"Заведение таска на обнаружение уязвимостей" →
"Обнаружение уязвимостей" →
"Уязвимости не обнаружены" →
"Информировании о получении неудовлетворительного результата" →
"Заведение таска на исправление"

:)

Согласен, но тут слишком много "если", "случайно" и "вовремя" чтобы имело смысл на всё это заморачиваться. Если что-то правильное таки случайно случится, то это однозначно произойдёт вовремя и само собой.

Вопрос не в ML, а в том, что либо Яндекс воспринимает описанное в статье и комментах как багрепорт и идёт фиксить свой ML, добавляет ручные исключения для типовых сценариев вроде "мне понадобился ящик для регистрации где-то, светить основной не хочется, отдавать яндексу телефон и документы тоже не хочется"… либо радуется возможности принудить юзеров сдать свои телефоны и документы отмазываясь "это не мы, это ML".

На "истину" я вроде не претендовал. Но есть вещи, довольно очевидные: действия РКН в этой ситуации можно описать только термином "беспредел"; РКН, суды и зомбоящик будут проводить генеральную линию партии, не сильно волнуясь о том, как это выглядит со стороны, и не обращая внимания на здравый смысл. Они так делают уже довольно давно, и пока что нет никаких признаков того, что они испытывают из-за этого какие-то неудобства, или что в стране есть какая-то альтернативная сила, которая может и хочет их за это наказать.

Честно говоря, я наивно думал что после этого фиаско хотя бы главу РКН показательно снимут/повысят (что, впрочем, всё-равно ничего бы не изменило), чтобы немного остудить возмущение общественности, но даже этого не произошло.

Это не так. Мне без телефона уже давно не получается зарегистрироваться, хотя у меня и белый статический IP, и VPN на свой dedicated сервер в другой стране — ни с VPN ни без зарегистрировать аккаунт без телефона не даёт.

У гугла свои алгоритмы, которые логически не понять.

На хабре действительно есть небольшое количество людей (в смысле — не кремлеботов), которые считают, что блокировки "вредной информации" приносят пользу, и что "копирасты в своём праве" (и это не обязательно одни и те же люди). Это нормально, у них есть право на своё мнение. Но вот в отношении законности действий РКН во время войны с телеграм, по крайней мере по моим наблюдениям, таких нет — аккаунты, с которых изредка раздавались голоса в поддержку действий РКН не выглядели адекватными (имеющими нормальные статьи/комменты на другие темы), и их было очень мало.

А те люди, о которых Вы говорите, относятся не к категории думающих и что-то понимающих, они относятся к категории верующих в то, что говорят по зомбоящику, либо тех, кому на интернет вообще и РКН в частности просто положить. Да, их намного больше, чем нас. Но их в чём-то "убедить", или что-то им "доказать" всё-равно нереально, пока об этом не скажут по ящику — все эти суды на их мнение не повлияют.

Поэтому упомянутая Ваши риторика «все мы понимаем» относится к тем людям, которые вообще способны что-то самостоятельно понимать и интересуются этой темой, а не ко всему населению страны.

У меня свой почтовик на домашнем сервере уже примерно лет 17.

К сожалению, одноразовой настройкой обойтись невозможно — периодически этот IP (белый статический, с настроенным reverse dns и SPF, разумеется) попадает в базы всяких спамхаусов и прочих вымогателей. Причём регулярно, раз в год-два. Не менее периодически другие альтернативно одарённые, вроде AOL.com или mail.ru, внезапно перестают принимать от меня почту. Достучаться что до первых, что до вторых, и объяснить что они неправы… получается примерно в 50% случаев. Из оставшихся иногда проблема проходит сама, через несколько недель, иногда проще отправить нужное письмо с gmail и посоветовать перенести ящик на более адекватный сервис.

Помимо этого есть ещё проблема фильтрации спама, чем тоже приходится заниматься самостоятельно.

Плюс, не помешает иметь дружественный сервер где-то в другом месте, чтобы прописать его вторым MX.

В общем, реализовать это реально, но, в отличие от VPN, почту поддерживать в рабочем состоянии заметно сложнее, и никто кроме гиков с уклоном в администрирование это не осилит.

Показало кому? Были те, кто сомневался в незаконности действий РКН, и вот теперь, наконец-то, их сомнения развеялись?

У всех требует, а у Вас нет — фантастика. Не подскажете, с IP какой страны Вы заходили на gmail и какую страну указали при регистрации?

Заголовок новости не очень-то соответствует решению суда. Все мы понимаем, что происходит на самом деле, но новость-то про решение суда, а оно как раз никаких нарушений у РКН не нашло.

Расслабон, очевидно же. Тоже дело хорошее, периодически просто необходимое, но к медитации отношения не имеющее.

Я о той, которая медитация. Что в этих приложениях я точно не знаю, никогда не пользовался… но предполагаю, что да, к медитации они имеют слабое отношение. По крайней мере как только речь заходит о подборе звукового сопровождения под текущее состояние/эмоции сразу возникают вопросы. Да, иногда лучше медитируется в тишине, иногда под некоторые альбомы БГ, иногда под разные альбомы с мантрами… но сомневаюсь, что приложение может само различать эти ситуации, и к текущим эмоциям это всё вообще никакого отношения не имеет.

Аутотренинг штука рабочая, но к медитации отношения не имеет.

Вы действительно думаете, что числа — это что-то не имеющее смысла?

Нет, я такого не говорил. Я говорил, что число — это не объект. Смысл, как и методы, к числу 3 можно прилепить самые разнообразные (это вопрос упомянутой Вами интерпретации). А можно этого и не делать. Число 3 от такого отношения к нему не испортится, не сломается, не обидится, и не станет менее полезным. Это и отличает данные от объектов: у объекта есть "смысл"/интерпретация, пользуясь Вашей терминологией, а у данных этого нет. Да, к данным это можно добавить, и мы получим объект. Но делать это вовсе не обязательно.

А если смысл всё-таки есть, то разве методы (операции, возможности) вроде "+", "-", "*", "/" существуют не для пояснения смысла, заключенного в число?

В этом-то и проблема. Пока это число 3, это просто данные, и мы можем наделять их любым смыслом, что позволяет интерпретировать и использовать их как угодно. Как только число 3 превращают в объект, к нему гвоздями прибивают какой-то один смысл, и привязанный к этому смыслу набор методов. Для такого отношения нет никаких оснований (кроме пуризма "всё есть объект"), оно ограничивает наши возможности по интерпретированию числа 3 каким-то иным образом (как код символа, например, к которому методы вычитания и умножения не очень-то лепятся), а так же усложняет, замедляет и делает хуже читаемыми программы, которым тупо нужно обычное число 3.

Читая, хотелось аплодировать стоя — совершенно волшебная демагогия.

Возвращаясь к числу 3, невозможно понять его смысл, пока нет объекта, который этот смысл упаковывает, и методов, которые этот смысл поясняют.

Расскажите это на уроке математики.

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

Вопрос не в том, что текущий подход сложно обновить на использование нормальных алгоритмов, а в том, зачем вообще они использовали такие слабые алгоритмы — потому что единственное напрашивающееся объяснение это создание условий для дешёвого брутфорса паролей юзеров на их серверах.

Палец промахнулся раза в два по порядку, на самом деле там 10^19 лет, но это всё-равно более чем.

Не совсем так. Злонамеренный сервер может прислать в браузер модифицированный клиент, который сольёт пароль — это да. Но — это возможно заметить. Такие популярные приложения всегда находятся под наблюдением, рано или поздно, если сервер будет выкидывать такие фокусы, его на этом поймают. Да, это может произойти не сразу, и да, они могут попытаться всё списать на "баг" или злонамеренного разработчика внедрённого к ним ФСБ специально ради удара по репутации, но почти наверняка репутационный ущерб будет громадным, как и финансовые потери. Поэтому вряд ли они станут таким заниматься.

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

Вы всё ещё не распутались. :) Никто обратно не танцует. И в оригинальном комментарии и в ответе я говорил о том, что SHA512 не годится для паролей, так что от того, что я упомянул, что существуют задачи для которых SHA512 подходит — ничего не изменилось, для паролей он по-прежнему не годится.

Статистика сложности пользовательских паролей доступна в интернетах, почитайте сами, не отказывайте себе в возможности узнать что-то новое. Я вот тоже использую KeePass, но на одном из моих проектов у 10% юзеров (и речь о тысячах юзеров) был пароль 123456 (да, проект раньше хранил пароли открытым текстом, так что я смог собрать статистику, и нет, писал этот проект не я — когда до него добрался я пароли переехали в Argon2 и возможность ставить слабые пароли была заблокирована). Сколько из оставшихся 90% паролей входили в топ 1000 популярных паролей я проверять не стал, решил пожалеть свои нервы.

Не верите мне — почитайте ту же википедию. Она хоть и не особо достоверный источник, но, тем не менее, если посмотреть в подвал страницы сравнения хеш-функций то Вы обнаружите, что функции подходящие для обработки паролей выделены в отдельную категорию Key derivation functions и никаких SHA среди них нет в принципе.

Вообще, вопрос не в том, подходит ли SHA512 для паролей — ответ на него известен абсолютно всем (кроме Вас, но, надеюсь, мы вот-вот исправим это недоразумение).
Вопрос в том, почему разработчики телеграм, в квалификации которых особых сомнений нет, выбрали такой алгоритм, который позволит им без особых усилий взломать пароли большинства пользователей.

Вы немного запутались. Речь не о том, что любой SHA512 (или даже более простые хеши) можно "взломать" за небольшое время. Речь о том, что пользовательские пароли — слабые, поэтому вариантов, которые требуется перебрать для взлома паролей большинства юзеров — не так много. И вот здесь начинает иметь значение скорость перебора — чем быстрее скорость, тем быстрее будут взламываться пароли. Да, не все. Если пароль выглядит примерно так, как Ваш хеш — вряд ли его взломают за приемлемое время, даже если использовать MD5 вместо SHA512.

Так вот. Скорость перебора SHA512 на порядок меньше скорости SHA256 — но порядок цифр всё-равно гигантский: сотни миллионов в секунду на одном компе. Поэтому для хеширования паролей есть специальные алгоритмы (вроде Argon2), которые снижают эту скорость до десятков в секунду, т.е. на 7 порядков! А это значит, что перебор паролей будет идти в 10 миллионов раз медленнее, и даже у слабых паролей будет шанс продержаться некоторое время.

SHA512 хороший алгоритм и подходит для множества задач, для которых его надёжности более чем хватает. Но хеширование паролей к ним не относится.

Хотелось бы услышать комментарии на тему выбора SHA вместо Argon2 или PBKFD2 для хеширования пароля пользователя. Потому что действительно выглядит довольно сомнительно — пароли у юзеров слабые, и SHA позволит взламывать их вообще моментально.

И: получив root на своём устройстве, вы оставляете его (устройство) без штатной защиты.

Это чушь. Кто-нибудь вообще видел проявление этой "защиты" в интересах юзера в реальной жизни? Это обычный FUD, не более того. А вот наоборот в реальной жизни случается регулярно, когда в "родных" прошивках находят самую разнообразную малварь, слежку и удалённый контроль. Равно как в 99% случаев производитель перестаёт выпускать обновления для затыкания известных дыр через несколько месяцев, максимум год после выпуска телефона.

сами теперь отвечаете за то, что будет происходить с устройством.

Да. Раньше никто не отвечал, если смотреть реально и без розовых очков, а теперь хоть кто-то. Пусть не очень квалифицированный для этой задачи, но, хотя бы, искренне в ней заинтересованный. Хуже от того, что юзер получит рута, поставит TWRP и LineageOS — точно не станет! По крайней мере в плане безопасности и надёжности. В плане фич могут потеряться некоторые очень специфичные для железа фишки, но тут уж, имея рута, пользователь может сам решить, оставаться на стрёмной и, почти наверняка, со встроенной малварью (как минимум в плане утечки личных данных на сервера производителя телефона) родной прошивке ради этих фишек, или нет.

— А где гарантия, что в обновлениях не появятся новые «дыры»?

Есть гарантия, что новые появятся. Но ломают обычно не через новые, а через известные, т.е. в большинстве случаев — через старые. Так что обновлённая система может иметь столько же, а то и больше дыр в теории, но на практике она безопаснее.

хочешь максимально надёжную систему — детально разбирайся в вопросах безопасности, и пиши свою ОС.

В теории — да. На практике — нет необходимости бежать быстрее льва, достаточно бежать быстрее другого парня. Поэтому максимально надёжная система та, которую ломать сложнее и дороже обычной/средней системы. Потому что если кому-то понадобитесь лично Вы, причём этот кто-то будет иметь достаточно ресурсов — он всё-равно получит необходимое, в самом крайнем случае применив терморектальный криптоанализ. А от большинства остальных атак такая система защитит, в отличие от средней системы.

— Главное знать, что именно важно сохранять, и тогда вопросов не будет.
Насчёт шифрования: не всем нужно сверхнадёжное шифрование.

Важное определить сложно. Сделать это заранее и наверняка — почти невозможно. Поэтому намного проще сохранять всё и не париться. Сверхнадёжное шифрование сейчас стоит примерно столько же, сколько и ненадёжное — так что на этом нет смысла экономить и проще всё шифровать надёжными алгоритмами.

Думаете, там можно что-то испортить?