Двухфакторная аутентификация PyPI привела к удалению популярного пакета

Что: 2c608b64a39de6d149f5807e8c56da30793a57af

Когда: 2022-07-10 09:48:03+03:00

Темы: python

Двухфакторная аутентификация PyPI привела к удалению популярного пакета

https://www.opennet.ru/opennews/art.shtml?num=57481
Понимаю автора -- я бы принципиально не стал страдать этой хернёй с
двухфакторной аутентификацией. Я сам в праве решать как мне обеспечивать
безопасность. Кто-то считает что нужно вводить пароль со всякими цифрами
и знаками препинания. Кто-то считает что даже парольные фразы являются
злом и нужно только криптоключи или что-то подобное использовать. А
кто-то вообще считает что SMS-ки достаточно. Тут не может быть всех
удовлетворяющего решения. А если компрометация учётной записи даже с
парольной фразой возможна, чего вроде бы нет -- тогда и OTP и подобные
решения тут не помогли бы. Всё таки есть разница между секретаршей,
априори вешающей свой цифровой шестизначный пароль на монитор и
разработчиком ПО. Понимаю, понимаю, что современные разработчики в массе
своей не далеко ушли от этих секретарш в вопросах безопасности, но это
просто унизительно бы было для нормальных и адекватных чтобы к ним
принимали схожие меры.

оставить комментарий

комментарий 0:

From: kmeaw
Date: 2023-05-26 08:42:58Z

А в чём именно проблема, если используется какой-то общепринятый
(например TOTP из RFC) алгоритм, для которого есть куча свободных
реализаций?

У пользователя по-прежнему есть выбор - либо не увеличить безопасность,
и иметь генератор TOTP на той же машине, либо унести на другое
устройство (не обязательно смартфон, это может быть "безопасный"
ноутбук, не подключенный к сети).

Потерять второй фактор можно, но это справедливо и для пароля - в
компьютере точно так же может испортиться диск с passwords.txt.gpg.

А польза, как мне кажется, очевидна - против злоумышленника, который
завладел контролем над рабочей станцией появляется неизвлекаемый секрет,
ограничивающий его контроль одной текущей сессией. А "опасные" операции
могут требовать ещё и отдельного 2FA-подтверждения. Пароль же легко
извлечь и потом продолжать атаку, даже когда рабочая станция будет
выключена.

комментарий 1:

From: Sergey Matveev
Date: 2023-05-26 09:29:06Z


>А в чём именно проблема, если используется какой-то общепринятый
>(например TOTP из RFC) алгоритм, для которого есть куча свободных
>реализаций?

В том что, это только добавляет геморрой, без какой-либо пользы для меня.

Это *моё* дело как я обезапашиваю пароль от учётной записи. Кто-то пишет
на бумажках на мониторе, кто-то использует один пароль на всё, кто-то
хранит в password manager зашифрованном, кто-то предпочитаем внешние
аппаратные ключи, и т.д.. Не все могут безопасно обращаться с паролями:
например секретаршам, вешающим бумажки на мониторах, стоит насильно
выдать криптоключи/*OTP.

Я не буду использовать аппаратные *OTP ключи, так как не доверяю их
реализации (как мне проверить что действительно память там не тривиально
считывается при физическом вскрытии или же нормально шифруется?). Если
мне нужно нечто физически изолированное и внешнее относительно моего
компьютера, то я возьму ноутбук/RPi/whatever и там реализую всё что мне
надо. И безусловно больше всего меня напрягает то, что я не могу сделать
копии этих ключей на случай поломки. Где-то возможно и могу. Или же я
должен несколько ключей заводить.

>Потерять второй фактор можно, но это справедливо и для пароля - в
>компьютере точно так же может испортиться диск с passwords.txt.gpg.

Нет, passwords.txt.gpg не могут потеряться, так как пользователь обязан
иметь и делать резервные копии где-то вне жёсткого диска. Если он этого
не делает, то, грубо говоря, его пока вообще не стоит допускать до всей
этой техники.

>У пользователя по-прежнему есть выбор - либо не увеличить безопасность,

Это очень спорное заявление что *OTP увеличивают безопасность. Куча
критериев. Недоверенный OTP, который ничего не шифрует, легко
"извлекаем", который физически проще спереть у меня чем весь
ноутбук/компьютер/диск -- точно не будет безопаснее. Если я захочу
сейчас приобрести аппаратный *OTP, то как мне понять можно ли ему
доверять? Возможно читая статьи/блоги/исследования и найду нужный, но
стоит ли колоссальное количество потерянного на это времени? Какова
вероятность что я буду атакован, что над моим компьютером получат
контроль, что произойдёт так или иначе компрометация? Лично у меня, по
моим прикидкам, она гораздо ниже ниже чем стоимость потерянного времени
на поиск *OTP. Даже на поиск software реализаций и изучением как ими
пользоваться. Более того, если *Я* хочу донести своё доверие к пакету,
то я прикреплю к нему PGP подпись (да, теперь уже не могу, PyPI
выпилили, судя по их блогу, и эту возможность). Если человек качает
пакеты и запускает ничего не проверяя, не прибивая конкретные версии, и
всё в таком духе -- это его проблемы, а не PyPI или мои (разрабочтика
пакета).

>и иметь генератор TOTP на той же машине, либо унести на другое
>устройство (не обязательно смартфон, это может быть "безопасный"
>ноутбук, не подключенный к сети).

И тут вопрос "стоит ли оно того?". И это *мне*, разработчику, решать.
Кто-то возможно захочет проводить церемонии открытия ключей, приглашая
людей для сбора кворума, и делать это всё на одноразовом
компьютере/диске, записывая какие-нибудь промежуточные контрольные суммы
на бумажку. Забывчивый неаккуратный человек запросто предпочтёт *OTP.
Другой человек не увидит в этом пользы. Но в общем случае, не нужно меня
приравнивать к секретарше и заставлять использовать *OTP. Либо мне
придётся использовать software реализацию на своём компьютере, которая
ничем не будет отличаться от пароля, кроме как просто лишним геморроем
необходимости её использовать.

Интерфейсы программ становятся text-less, только с иконками, дабы ими
могли пользоваться неграмотные люди. *OTP активно используется в том
числе и для тех, кто не в состоянии безопасно работать с паролями. Все
стали бегать с проблемой компрометации компьютеров -- наверное потому
что поголовно качают непойми какие пакеты, выполняют curl|bash, первый
попавшийся dockerfile запускают? Может быть нужно стараться не пытаться
придумывать средства для уменьшения урона от подобных деяний, а учить
людей грамотности, основам безопасности? Понимаю: внедрение 2FA это
сразу мгновенный хороший profit и кучи урона как не бывало, а создание
компетентных ответственных людей это процесс на долгие годы. Но тот факт
что PyPI стало использовать 2FA, говорит только о том, что вот этих
некомпетентных людей стало на этом ресурсе чересчур много, так много,
что они решили что проще всех приравнять к ним. Ведь нет же смысла
оценивать может быть вот эта случайная секретарша умеет LaTeX с Git-ом?

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

PS: не пытаюсь задеть или обидеть секретарш :-). Просто использую их
стереотип.

комментарий 2:

From: kmeaw
Date: 2023-05-26 11:40:15Z

Но ведь те же аргументы справедливы и для современных криптографических
примитивов и протоколов. Например, D. J. Bernstein решил, что в
реализациях Curve25519 люди будут ошибаться и выбрал параметры такими,
чтобы лишить некомпетентного разработчика части возможностей сделать
небезопасную реализацию. В WireGuard зафиксировали выбор
криптографических конструкций вместо того, чтобы сделать так же гибко,
как в IPsec (или хотя бы как в OpenVPN), посчитав, что неправильная
настройка некомпетентным пользователем приведёт к снижению безопасности.

На мой взгляд, это не делает Curve25519 и WireGuard плохими. Наоборот,
это даёт доступ к технологии для более широкого круга людей.

TOTP (по крайней мере для PyPI) совершенно необязательно использовать
аппаратный - достаточно простой программной реализации. Мне сложно
назвать геморроем необходимость вызова totp.sh < ~/secrets/pypi/totp

И у меня есть свобода выбора - я могу либо "ноутбук/RPi/whatever"
использовать для вызова totp.sh, а могу не увеличивать безопаность
дополнительной изоляцией и хранить ~/secrets/pypi/totp рядом с
~/secrets/pypi/password, если мне так удобно. Проблем с бекапами в любой
из этих схем никаких нет.

Причину, почему так сделали в PyPI я тоже понимаю - у них есть
статистика по скомпрометированным аккаунтам. Учитывая, как часто люди
делают pip install whatever, совершенно не задумываясь о последствиях,
легко представить себе червя, который будет угонять пароль от PyPI и
добавлять себя в postinstall всех опубликованных пакетов. Если дать
людям выбор продолжать использовать пароли, то большинство просто
прокликает все предупреждения не включая мозг - будут решать задачу
"какую тут кнопку нажать, чтобы система поскорее от меня отвязалась".

Действительно, если я умею безопасно и ответственно обращаться со своими
паролями, то для меня это будет лишней нагрузкой. Но меня ничего не
обязывают покупать или устанавливать - простенький скрипт на несколько
строк для меня почти ничего не стоит, зато меры по принудительному
включению 2FA заставят хотя бы часть безответственных разработчиков
частично обезопасить себя (и своих пользователей, бездумно делающих pip
install), сокращая множество уязвимых для этого червя машин.

Преимущества для себя я тоже могу найти - с 2FA я могу хоть как-то
использовать сервис с недоверенной машины. С PyPI у меня, правда, такой
потребности не возникало, а вот необходимость получить какой-то файл без
предварительной подготовки пару десятков раз была - тут бы выручил SSH
или HTTP-сервер с TOTP.

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

комментарий 3:

From: Sergey Matveev
Date: 2023-05-26 12:23:02Z


>Но ведь те же аргументы справедливы и для современных криптографических
>примитивов и протоколов.

Там огромная цена некомпетентного использования. И компетентных людей в
этой области очень мало. Грубо говоря, 99.99% с *25519, WireGuard и
прочим будут только рады и более безопасны. А предполагать что на PyPI
ходят люди на 90%+ некомпетентные для (достаточно безопасной) работы с
паролями -- это уже мне кажется не правильно.

>В WireGuard зафиксировали выбор
>криптографических конструкций вместо того, чтобы сделать так же гибко,
>как в IPsec (или хотя бы как в OpenVPN), посчитав, что неправильная
>настройка некомпетентным пользователем приведёт к снижению безопасности.

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

>TOTP (по крайней мере для PyPI) совершенно необязательно использовать
>аппаратный - достаточно простой программной реализации. Мне сложно
>назвать геморроем необходимость вызова totp.sh < ~/secrets/pypi/totp

Да я даже как-то поисследовал и прям даже буквально на PyPI поигрался с
TOTP, когда уже решил удалить оттуда свои пакеты. Просто чтобы вообще
иметь представление какие для этого есть инструменты и как вся эта
процедура происходит. Нашёл простые Go реализации тривиальные к которым
у меня претензий не было.

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

>Причину, почему так сделали в PyPI я тоже понимаю - у них есть
>статистика по скомпрометированным аккаунтам. Учитывая, как часто люди
>делают pip install whatever, совершенно не задумываясь о последствиях,
>легко представить себе червя, который будет угонять пароль от PyPI и
>добавлять себя в postinstall всех опубликованных пакетов. Если дать
>людям выбор продолжать использовать пароли, то большинство просто
>прокликает все предупреждения не включая мозг - будут решать задачу
>"какую тут кнопку нажать, чтобы система поскорее от меня отвязалась".

У меня полностью такое же мировоззрение и предположения обо всём этом,
согласен! Но я категорически не согласен с тем, что *я* что-то должен
делать и предпринимать, на меня дополнительный геморрой ложится, из-за
таких вот click-everything-you-see пользователей. Если PyPI, а точнее
Python экосистема, стала засильем curl|bash-идиотов (а это по факту так
и есть) -- мне с ней не по пути. Точнее не по пути с этими людьми, а
TOTP сделан ради/для них.

>Действительно, если я умею безопасно и ответственно обращаться со своими
>паролями, то для меня это будет лишней нагрузкой. Но меня ничего не
>обязывают покупать или устанавливать - простенький скрипт на несколько
>строк для меня почти ничего не стоит, зато меры по принудительному
>включению 2FA заставят хотя бы часть безответственных разработчиков
>частично обезопасить себя (и своих пользователей, бездумно делающих pip
>install), сокращая множество уязвимых для этого червя машин.

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

>Преимущества для себя я тоже могу найти - с 2FA я могу хоть как-то
>использовать сервис с недоверенной машины. С PyPI у меня, правда, такой
>потребности не возникало, а вот необходимость получить какой-то файл без
>предварительной подготовки пару десятков раз была - тут бы выручил SSH
>или HTTP-сервер с TOTP.

Я не говорю что OTP решения это зло и бесполезная вещь :-). Где-то могут
пригодится. Пример с SSH мне нравится, действительно серьёзный
реалистичный use-case. Но "я хочу PyPI отовсюду в любое время иметь
возможность безопасно использовать" -- это я уже не мог бы считать
чем-то адекватным :-)

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

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

Почему PyPI вводит TOTP? Потому что куча людей, аналогично, идиоты
неаккуратные и наплевательские. Но для меня кардинальная разница в том,
что на PyPI, что среди программистов, просто не должно быть этих
безалаберных и опасных для окружающих типов. Эти люди не должны были
становится программистами (в смысле: рано им ещё выкладывать пакеты,
если не понимают базовых основ аккуратного обращения с
аутентификационными данными). Раньше же, 1 (2?) десятка лет не было
никаких проблем с этими фишинговыми пакетами, с постоянной утерей
ключей/паролей у людей? Что изменилось? Тьма компьютеров у одного
человека, больное желание делать всё с любого устройства (коммитить из
туалета на смартфоне), курсы по ЯП за одну неделю, после которой человек
уже рвётся клепать свои пакеты. Падение культуры разработки. Я считаю
что проблема фишинговых-пакетов -- это не проблема PyPI, а проблема
конечных пользователей этих пакетов, которые даже не смотрят на название
того, чего скачивают. PyPI (или любой другой репозиторий) предоставляет
бесплатный централизованный хостинг статических файлов, с возможностью
поиска по метаинформации? Вот пускай этим и занимается, а не цензурой и
решениями кто из пакетов важен, а кто нет. А если пользователь не может
отличить поддельный пакет от нормального? Значит ему просто не нужно
пользоваться пакетами, пользоваться PyPI/Python/whatever, и учиться,
повышать свой уровень, дабы не делать слепой запуск произвольного кода.
Есть жизненно важные потребности, где человека кто-то вынужден защищать,
оберегать и предпринимать какие-то решения за него. Но программирование,
выкладываемые библиотеки -- точно к этому не могут относится, по моему.

Сгенерирован: SGBlog 0.34.0