GitHub запрещает парольную аутентификацию при доступе к Git

Говорят, не все ещё с svn слезли

Представь себе конскую монорепу уровня FAANG/яндекс/мейл. И теперь представь на ней гит или hg

Где-то читал статью про использование git lfs в одной из компаний FAANG. Впрочем, утверждать ничего не берусь, все это было довольно давно, и ссылок у меня не осталось.

Просто не надо хранить БД паролей только на одном устройстве.

А аутентификация по токену не требует раскрытия токена?

Требует. Поэтому ключи лучше. (Вру. Если используется digest authentication, то токен не будет светиться открытым текстом.)

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

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

Все было бы гладко и красиво, вот только Github рекомендует использовать токены, а не ключи.

Не в лфс дело. Ты хоть раз видел репу, у которой история даже в виде диффа занимает больше 50 гиг? Я видел, гит на таком сдохнет

Это только потому, что для токенов можно гибко настраивать доступы, а ключ — он сразу на весь аккаунт. Было бы зашибись, если бы можно было добавить SSH-ключ, но дать ему только определённый набор доступов.

Очевидно, что если бы был некий заговор гитхаба (как утверждается в сообщении, на которое я отвечал), то токены были бы сугубо вторичными, а не наоборот. В этом смысл.

Да.

Есть конторы в которых только https можно до github/gitlab достучаться.

А что? Там можно с паролем было?

Это те самые, которые нужно указывать в виде аргументов командной строки? Или всё же есть безопасный метод их ввода?

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

GitHub запрещает парольную аутентификацию при доступе к Git (комментарий)

на которую под одним и тем же аккаунтом могут логиниться человек 10

Источник проблемы - неправильный процесс. Как обычно.

Аааа, не тогда кроссавчики, это же по-сути те же пароли, только их за тебя сгенерировали. Я думал это токены типа как для API, которые в URL нужно указывать.

Пароль по сети не передаётся, передаётся его хэш

А теперь подумай ещё раз, умный ты наш. Лол.

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

Какая удобная альтернатива паролю?

Agent forwarding.

или это заговор против работающего метода шифрования, чтобы пересадить всех на сомнительные алгоритмы

А определять, какой алгоритм «работающий», а какой «сомнительный», у нас кто будет? Ты?

Ну вот, например, Брюс Шнайер высказывал что-то на эту тему. Недостаточно авторитет для тебя?

Да, тупняк.

Что конкретно он высказывал?

Брюс Шнайер, может, и авторитет, но слова «ну Брюс Шнайер что-то говорил» точно не авторитет.

Насколько я понимаю, RSA в современном постквантовом мире стал уже небезопасным

В коком месте? Я что-то пропустил? Насколько я знаю, ничего больше 256 бит сломать пока что не смогли.

Помню, мне Legioner написал, что «RSA можно наговнокодить так, что поломают в два счета, то ли дело — элиптическая криптография». Я однажды сел и все-таки в общих чертах разобрался с элиптической криптографией. А также с тем, как у Sony PS похакали, поскольку она использовал для подпили неслучайное зерно. Достаточно найти две подписи с двумя одинаковыми зернами — и по ним можно вычислить закрытый ключ. Очень безопасно, ага.

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

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

Неужели есть люди, которые до сих пор используют аутентификацию по https на гитхабе? В смысле не один раз в год, а регулярно

А что не так с https? Там слабое шифрование? На рабстве только по https и ходю.

А на самом деле на суперкомпьютерах АНБ давно всё можно взломать

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

Элиптическая криптография не позволяет <…>

Наверное, всё-таки не «эллиптическая криптография» как таковая, а конкретное семейство алгоритмов — варианты DSA поверх кривых.

Наверное, всё-таки не «эллиптическая криптография» как таковая, а конкретное семейство алгоритмов — варианты DSA поверх кривых

RSA позволяет подписывать «из коробки», ему больше ничего не нужно. В случае элиптической криптографии вообще в целом «формирование предсказуемой подписи» значит «спалить закрытый ключ». Короче говоря, элиптическая криптография сильно ограничена по возможностям как метод, и эти ограничения приходится обходить — примерно как низкую стойкость MD5 когда-то пытались обходить добавлением соли к паролю аля «security through obscurity». Но если соль постоянно одна и та же, то по итогу пароль ломают. Та же история с элиптической криптографией, только получение закрытого ключа дает намного печальнее последствия.

https://www.schneier.com/blog/archives/2013/09/the_nsas_crypto_1.html

Much of the public-key cryptography we use today involves elliptic curves, something that is even more ripe for mathematical breakthroughs. It is not unreasonable to assume that the NSA has some techniques in this area that we in the academic world do not. Certainly the fact that the NSA is pushing elliptic-curve cryptography is some indication that it can break them more easily.

Говорят, не все ещё с svn слезли.

У меня компания (очень серьёзная) только в позапрошлом году перелезла с CVS на git/github. Причём, старые проекты (очень важные), так в CVS и сидят, и апдейтить приходится оба, git и cvs репы. Вот где геморой!

А трагедия с паролями на гитхубе реально не понятна. Залей ключ, забудь про пароли.

Я однажды сел и все-таки в общих чертах разобрался с элиптической криптографией

как-то очень хреново разобрался, как я смотрю) Давно не читал такой дичи на форумах.

Я вообще не видел ни разу шильдик «одобрено АНБ».

Дело не в https, а в использовании пароля.

Там слабое шифрование?

Нет, обычно очень сильное. С другой стороны нет нужды его брутфорсить, есть более простые методы.

Ключ обычно тоже делают с паролем. То есть получить закрытую часть будет недостаточно для получения доступа.

Создайте тред про openssh и пароли - все комментарии там будут «используй ключи». Интересно.

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

В коком месте? Я что-то пропустил?

Вот здесь у них обоснование:

https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

Насколько я знаю, ничего больше 256 бит сломать пока что не смогли.

Вот вполне себе простые люди собрались и похакали RSA 512-bit для цели подписывания кастомных образов на Panasonic 3DO:

http://www.arts-union.ru/smf/index.php?topic=258.0
http://forum.3doplanet.ru/viewtopic.php?f=17&t=534

В коком месте? Я что-то пропустил?

Вот здесь у них обоснование:
https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-...

А, так вот что... На самом деле там никакого обоснования нет. Причина в том, что конкретный алгоритм ssh-rsa использует SHA-1, который ломается на раз-два. То есть, RSA тут вообще не при чем, используй rsa-sha2-512, и проблем не будет.

Вот вполне себе простые люди собрались и похакали RSA 512-bit для цели подписывания кастомных образов на Panasonic 3DO

Хорошо, допустим, уже научились ломать 512. Но 1024 если кто-то и поломает, то только АНБ и за бешенные деньги. А 2048 не поломает даже АНБ.

Пришлось таки добавить открытый ключ от другой репы.

Правда из конфига для параметра pushurl пришлось убрать git+ssh. Для pull оставил https, чтобы пароль к ключу не спрашивал.

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

Как будто ваш токет или ssh-ключ не могут спереть. А вообще если что-то постоянно сперают то тут явно что-то не так, да? Либо пользователи, либо ваш гитхаб решето. Токеты тут не помогут!