Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Критика шифрования ключей в OpenSSH"	+/–
Сообщение от opennews (??), 05-Авг-18, 12:53
Недавняя подстановка (https://www.opennet.dev/opennews/art.shtml?num=48960) вредоносного ПО в популярный NPM-модуль eslint, привела к отправке злоумышленникам SSH-ключей доступа, хранящихся в домашней директории нескольких тысяч разработчиков. Многие разработчики не придали этому должного внимания из-за того, что их ключи были зашифрованы с использованием пароля. Тем не менее по умолчанию в SSH для закрытых RSA-ключей применяется устаревший и ненадёжный (https://latacora.singles/2018/08/03/the-default-openssh.html) метод шифрования, использующий блочный шифр AES с ключом в виде MD5-хэша от заданного пользователем пароля (с солью). Функция bcrypt_pbkdf, обеспечивающая должную защиту от подбора, применяется только для ключей на базе эллиптических кривых (Ed25519). Применение по умолчанию неэффективного шифрования на базе MD5, производительность подбора хэшей для которого на современном оборудовании может достигать миллиардов проверок в секунду, не только сводит на нет пользу от шифрования ключа, но и, по мнению автора статьи (https://latacora.singles/2018/08/03/the-default-openssh.html), делает защиту даже менее надёжной, чем использование открытого текста без шифрования. Суть данного мнения в том, что часто пользователи используют один и тот же пароль для разных сервисов. В случае шифрования ключей SSH, как правило, не применяются менеджеры паролей и пользователь использует знакомый ему типовой пароль, который он держит в голове. Применение типового пароля в изначально ненадёжной схеме хэширования ставит под удар сам пароль и упрощает компрометацию публичных сервисов для которых применяется данный пароль. SSH-ключ, отправленный в ходе запуска вредоносного модуля NPM, при надлежащей настройки ограничения доступа к SSH не позволит скомпрометировать хост, но может быть использован для подбора пароля, применяемого для его шифрования. Используя открытый ключ для проверки успешности подбора, атакующий с достаточно высокой вероятностью может определить изначальный пароль и использовать его для атаки. URL: https://news.ycombinator.com/item?id=17682946 Новость: https://www.opennet.dev/opennews/art.shtml?num=49082
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Критика шифрования ключей в OpenSSH"	+/–
Сообщение от Аноним (1), 05-Авг-18, 12:53
Настоящей утечки SSH ключей не было. Код закладки в eslint содержал ошибку и не работал
Ответить | Правка | Наверх | Cообщить модератору

	3. "Критика шифрования ключей в OpenSSH"	+7 +/–
	Сообщение от Аноним (3), 05-Авг-18, 13:00
	Это совершенно меняет дело
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от Аноним (30), 05-Авг-18, 16:54
	Скорее недоработка, которая приводила к сбою в некоторых окружениях. Параметры около 4500 разработчиков за пару часов успели на pastebin скопировать.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Критика шифрования ключей в OpenSSH"	+13 +/–
Сообщение от Alexey (??), 05-Авг-18, 13:00
NаPоMойке криптография не нужна. Пусть используют телнет.
Ответить | Правка | Наверх | Cообщить модератору

4. "Критика шифрования ключей в OpenSSH"	–5 +/–
Сообщение от Oleg (??), 05-Авг-18, 13:06
NPM имеет доступ ко всем файлам на компьютере. Нормальные люди устанавливают приложения в Snap и отключают доступ к домашней директории. Благо это так же просто как в Android 6+.
Ответить | Правка | Наверх | Cообщить модератору

	7. "Критика шифрования ключей в OpenSSH"	+4 +/–
	Сообщение от Ага (?), 05-Авг-18, 13:08
	на секундочку Олег. И часто вы пакуете в снап ? а эту армию бибизян пробовали учить?
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Критика шифрования ключей в OpenSSH"	+4 +/–
	Сообщение от Аноним (14), 05-Авг-18, 13:34
	>snap это тот, в популярных репах которого недавно криптомайнер нашли? Исходя из того, что васянам доверия нет, давайте будем честными - сколько разработчиков пакуют свои поделки официально? А сколько пользователей бубунты способны собрать свой собственный снап/флатпак и настроить это дело правильно (как Вы говорите - с изоляцией и свистелками)? О том и речь.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	19. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Смузи на гироскутере (?), 05-Авг-18, 13:57
	>>snap > это тот, в популярных репах которого недавно криптомайнер нашли? Это он, наш модный снап, и репа одна как AUR, как Google Play. > Исходя из того, что васянам доверия нет, давайте будем честными - сколько > разработчиков пакуют свои поделки официально? А сколько пользователей бубунты способны > собрать свой собственный снап/флатпак и настроить это дело правильно (как Вы > говорите - с изоляцией и свистелками)? О том и речь. Справедливости ради программа внутри снапа ничего с системой сделать не может и для противодействия майнерам можно выключить ей интернет.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от Khariton (ok), 05-Авг-18, 19:49
	1. Отключенный интернет остановит криптософт от расчетов за счет моего процессора?))) 2. А если софтина в которую встроили криптомайнер без интернета не имеет смысла?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от Аноним (41), 05-Авг-18, 23:52
	т.е. ты на полном серьезе считаешь, что автор майнера настолько идиот, что всем пихает одинаковый пейлоад?
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от нах (?), 06-Авг-18, 11:09
	> 1. Отключенный интернет остановит криптософт от расчетов за счет моего процессора?))) нет, но, поскольку он не сможет больше получать задания и сливать результаты в пул, ты можешь наслаждаться тем, что купив билет, таки поехал зайцем - владельцу трояна не удастся на этом заработать ;-)
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	21. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от Crazy Alex (ok), 05-Авг-18, 14:03
	Просто ставьте софт из репозитория дистрибутива штатным методом - и будет вам счастье.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	67. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от J.L. (?), 07-Авг-18, 17:29
	> Просто ставьте софт из репозитория дистрибутива штатным методом - и будет вам счастье. а тот софт которого случайно не оказалось в репозиториях моего дистрибутива? а тот софт которого случайно не оказалось в репозиториях ЛЮБОГО дистрибутива?
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от KareemJabbar (?), 05-Авг-18, 14:51
	Snap? Это тот, который не позволяет создавать свои собственные репозитории внутри сети? Проходите, молодой человек, проходите. Не задерживайтесь. Snap сдохнет ближайшие 2 года как и всё, что рождается в потрохах Canonical (mir, unity, upstart). Готов ставить крупные деньги, что к 2020 году про snap уже никто не будет помнить.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	37. "Критика шифрования ключей в OpenSSH"	–2 +/–
	Сообщение от Аноним (37), 05-Авг-18, 22:48
	Ну что же, поставь. Давай ты ставишь 10 тысяч долларов USA, что snap не будет существовать к 1 января 2020 года. Если будет, то ты переводишь указанную сумму в российских ржублях по курсу ЦБ РФ на мой кошелек в Яндекс.Деньгах. Если согласен, то кошелек я сообщу.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Критика шифрования ключей в OpenSSH"	+4 +/–
	Сообщение от anonymous (??), 06-Авг-18, 00:57
	"Крупные деньги" это 500 рублей.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Критика шифрования ключей в OpenSSH"	–1 +/–
	Сообщение от Аноним (37), 06-Авг-18, 05:27
	Это сколько в деньгах? Меньше 10 долларов? А что на это купить можно?
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Критика шифрования ключей в OpenSSH"	–1 +/–
	Сообщение от каноник (?), 06-Авг-18, 19:40
	> Snap сдохнет ближайшие 2 года как и всё, что рождается в потрохах Canonical да ну, бросьте, мы так быстро бабки не пилим, надо ж иногда и отдыхать. Лет пять еще проживет, а может и семь. А мы пока телеметрией поторгуем... такой - даже у гугля нет!
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	81. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от anonymous (??), 05-Сен-21, 04:35
	Snap все еще живее всех живых
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

5. "Критика шифрования ключей в OpenSSH"	–1 +/–
Сообщение от Alexey (??), 05-Авг-18, 13:06
SSH w. PKCS#8: https://habr.com/post/181320/
Ответить | Правка | Наверх | Cообщить модератору

	8. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от Аноним (8), 05-Авг-18, 13:13
	Да, но на самом деле ssh-keygen все это уже умеет. Генерируем RSA-ключ: $ ssh-keygen -o -t rsa -b 4096 -f <путь к ключу> Конвертируем существующий ключ: ssh-keygen -o -p -t rsa -b 4096 -f <путь к ключу>
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (8), 05-Авг-18, 13:14
	Только при конвертации "-t rsa -b 4096" конечно не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Критика шифрования ключей в OpenSSH"	–1 +/–
	Сообщение от Alexey (??), 05-Авг-18, 13:20
	-o - спасибо,проглядел. 10 лет назад такого не было и вот, опять.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

6. "Критика шифрования ключей в OpenSSH"	–1 +/–
Сообщение от AnonPlus (?), 05-Авг-18, 13:07
Как вариант, можно не хранить ключ в домашней директории. Тебе не нужно беспокоится о слабом шифровании, если злоумышленник вообще не получит ключа. Допустим, можно хранить его в базе KeePass, а уж база шифруется вполне надёжно. А плагин KeeAgent выступает в роли агента аутентификации, запрашивая у пользователя одобрения всякий раз, когда кто-то запрашивает ключ.
Ответить | Правка | Наверх | Cообщить модератору

	13. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Alexey (??), 05-Авг-18, 13:33
	Вот ещё способ хранения закрытых ключей: https://dev.rutoken.ru/pages/viewpage.action?pageId=3440675 (токенов можно взять у свих бухгалтеров. банки раз в год ключи меняют, новые выдают, старые остаются)
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от Аноним (32), 05-Авг-18, 17:52
	не знаю как у Вас, но сдаешь токен и получаешь с новым эцп, они же перезаписываемые у нас сейчас ввели нарядную систему в электронном журнале (1с) эцп выдали каждому сотруднику, ивц заставили выдавать и следить за токенами, ивц же и обновляет их, перезаписывая токены либо у бухов вообще эцп на обычной флешке хранятся
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (59), 06-Авг-18, 23:14
	Только вот ruToken использует для токенов обычные незащищенные микроконтроллеры, а не специальные микроконтроллеры для смарт-карт. Впрочем, последних ведь с поддержкой ГОСТ-шифрования и не бывает.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	51. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (51), 06-Авг-18, 12:30
	>можно не хранить ключ в домашней директории можно хранить, но под отдельным пользователем без доступа всем прочим. И su при необходимости работать с этим всем
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

10. "Критика шифрования ключей в OpenSSH"	+4 +/–
Сообщение от Аноним (10), 05-Авг-18, 13:19
Используйте уже наконец ed25519.
Ответить | Правка | Наверх | Cообщить модератору

	12. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от Аноним (8), 05-Авг-18, 13:21
	Привет, админ локалхоста.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (17), 05-Авг-18, 13:42
	А что, где-то еще остались сервисы у которых ssh не понимает ed25519?
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 05-Авг-18, 13:49
	До фига таких, сторонних. :( Установил кто-то когда-то в локальной сети vSphere 5.5, и работает оно до сих пор, например. Или там CentOS древний, на котором крутится Очень Важный Сервис, Который Нечем Заменить. Или коммутатор, который спасибо что вообще про SSHv2 слышал. Имя им — легион.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от Аноним (20), 05-Авг-18, 14:03
	А что, где-то ещё остались люди, способные понять, о чём вообще идёт речь в тексте новости?
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	27. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от username (??), 05-Авг-18, 16:02
	Виртуалки? Нет, кроме окаменелостей конечно. А вот железяк даже новых - предостаточно.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	29. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Module 5 temperature (?), 05-Авг-18, 16:45
	Куча вполне себе живых и работающих коммутаторов даже SSHv2 не понимает.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	44. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от marios (ok), 06-Авг-18, 02:06
	Ну в dropbear их нету
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	52. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (37), 06-Авг-18, 13:02
	В embedded очень распространено использование dropbear, а тот в ed25519 никак не умеет по религиозным причинам.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	39. "Критика шифрования ключей в OpenSSH"	–4 +/–
	Сообщение от Michael Shigorin (ok), 05-Авг-18, 23:05
	Как автор термина -- поморщился: он вообще-то не о противопоставлении гадюшнику, именуемому "ынтерпрайзом".  И тем более не теми, кто неспособен для соответствующего хлама держать хоть DSA, а для нормальных систем -- нормальные ключи (ed25519 или на худой конец RSA от 4096 бит). Это типа алаверды :)
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	40. "Критика шифрования ключей в OpenSSH"	–1 +/–
	Сообщение от Ivan_83 (ok), 05-Авг-18, 23:30
	Элиптическое крипто менее безопасно чем RSA с ключом нужной длины.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	56. "Критика шифрования ключей в OpenSSH"	–1 +/–
	Сообщение от Xasd (ok), 06-Авг-18, 19:44
	> Используйте уже наконец ed25519. а угадай -- что именно *поумолчанию* генерирует ssh-keygen ? там есть такая опция      -t dsa | ecdsa | ed25519 | rsa              Specifies the type of key to create.  The possible values are “dsa”, “ecdsa”, “ed25519”, or “rsa”. что будет если её НЕ указывать? предлагаешь чтобы программист свалил вину за неправльный выбор на пользователя, в случае если в криптографии окажется какаято проблема? типа -- "ну пользователь же сам написал -t XXX и выбрал плохой алгоритм! сам виноват!" # P.S.: подсказка: оно выбирет RSA
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	63. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от пох (?), 07-Авг-18, 07:28
	> а угадай -- что именно *поумолчанию* генерирует ssh-keygen ? то что совместимо со всеми, и не вызывает, пока, проблем с надежностью. И маловероятно что при 4k ключах вообще когда-либо в обозримом будущем вызовет. а вот зачем оно еще и формат закрытого ключа использует совместимый незнамо с чем (в OpenSSH_5.8p2, Feb 2013 - уже понимается новый формат, хотя и не генерируется - нужен фокус с openssl, и тоже поновее 2013го года), требуя тайного знания о каких-то новоизобретенных ключах - хотя закрытые как раз никто никогда и никуда не копирует, за редкими исключениями (и там чаще всего их требуется конвертировать) - это действительно загадка.
	Ответить | Правка | Наверх | Cообщить модератору

15. "Критика шифрования ключей в OpenSSH"	–3 +/–
Сообщение от Аноним (15), 05-Авг-18, 13:35
Нужно это гогно пускать из докер контейнера.
Ответить | Правка | Наверх | Cообщить модератору

	23. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от angra (ok), 05-Авг-18, 14:33
	Это который "Буква S в docker означает security"? А уж как удобно будет из под этого кодить, ты просто не поймешь за неимением опыта.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Критика шифрования ключей в OpenSSH"	–3 +/–
	Сообщение от username (??), 05-Авг-18, 15:59
	А что неудобного? Каталог с хост системы прокинут в контейнер, ты себе сейвишь в редакторе как и раньше. Ничего по скорости и юзкейсам не изменилось. Расскажите вашу боль, может вы у себя ссзб.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Критика шифрования ключей в OpenSSH"	+2 +/–
	Сообщение от angra (ok), 06-Авг-18, 07:19
	Ну если задачи той сложности, что сохранения в редакторе достаточно для продуктивной работы, то таки можно. Мне же требуется несколько больше. Причем я даже знаю или могу быстро выяснить как каждую из моих хотелок реализовать при помощи docker/lxd/openvz, вот только городить и работать с этой системой костылей и подпорок всё равно неудобно. И если в случае openvz я хотя бы получаю реальную безопасность и оно того стоит, то в случае с docker только ее иллюзию. А для решения самых тупых проблем типа как в сабже хватит и чрута или отдельного пользователя.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от имя (?), 05-Авг-18, 20:51
	нормально под это кодить, подключил вольюм к контейнеру и все работает. Тестировать для разных версий тоже довольно удобно.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	34. "Критика шифрования ключей в OpenSSH"	+11 +/–
	Сообщение от Led (ok), 05-Авг-18, 19:50
	> Нужно это гогно пускать из докер контейнера. Пускать гогно из гогна? Оригинально.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

16. "Критика шифрования ключей в OpenSSH"	+1 +/–
Сообщение от Аноним (14), 05-Авг-18, 13:38
Имхо, отчасти они правы - в таком софте, по дефолту настройки должны быть наиболее сесурными (а всякое легаси оставлять как опцию). Что не отменяет того факта, что разработчики на ноде, в контексте новости, ссзб
Ответить | Правка | Наверх | Cообщить модератору

28. "Критика шифрования ключей в OpenSSH"	–1 +/–
Сообщение от Аноним (28), 05-Авг-18, 16:25
Либо я идиот либо автор этой критики и все комментаторы. ssh не хранит MD5-хеш пароля, сам MD5-хеш является паролем для AES. MD5 плох тем, что можно быстро подобрать коллизию пароля по хешу, но у нас нет хеша! Он у нас появится только после успешного взлома. Из хеша можно получить коллизию суммы пароля и соли, а не сам пароль. Так, что это вообще никак не компрометирует сторонние сервисы! А если пользователь использовал слабый пароль, подбираемый по словарю, то при чём здесь ssh и MD5 вообще?
Ответить | Правка | Наверх | Cообщить модератору

	38. "Критика шифрования ключей в OpenSSH"	+5 +/–
	Сообщение от пох (?), 05-Авг-18, 22:53
	> Либо я идиот ну зачем же так? просто неумелец читать буковки и складывая из них слова понимать написанное, таких много. тут речь не о уязвимости md5 к подбору валидного хэша от левого источника. Речь о попытках подобрать валидный пароль, не левый, а вполне настоящий - тyпым перебором по словарю (а пароли от ключа у многих простые, потому что ключи в любом случае не принято разбрасывать жестом сеятеля). В данном случае недостаток md5 просто в том, что он считается слишком быстро, как и сам aes-cbc, и этих попыток можно даже на небыстром железе делать _много_ - пока не угадаешь, и это произойдет достаточно скоро. И автор намекает, что это даже хуже, чем без пароля - потому что теперь у кого-то, помимо ключа, есть еще и твой пароль, и фиг знает где еще тебя угораздило на такой пароль положиться (причем это где-то могло использовать надежное хранение пароля, в отличие от ssh, и просто так его бы не взломали).
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Критика шифрования ключей в OpenSSH"	+3 +/–
	Сообщение от Аноним (28), 06-Авг-18, 07:28
	Переборы по словарю всегда очень быстры. И это до сих пор считалось само собой разумеющемся, просто потому, что безопасники всегда исходят из идеи, что у взломщика есть суперкомпьютер или ботнет. Раньше никто не использовал видеокарты и всё равно успешно подбирали по словарю. Даже были случаи удалённых взломов по словарю. Всё дело в том, что паролей в словаре так мало, что это нивелирует ЛЮБУЮ сложность алгоритма.
	Ответить | Правка | Наверх | Cообщить модератору

31. "Критика шифрования ключей в OpenSSH"	–1 +/–
Сообщение от kvaps (ok), 05-Авг-18, 17:29
Та причина почему нужно использовать ssh-agent, а сам ключ прятать в keepassxc
Ответить | Правка | Наверх | Cообщить модератору

	42. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (42), 06-Авг-18, 00:28
	Новость как раз про то, что по умолчанию keepass не поможет
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от kvaps (ok), 06-Авг-18, 09:07
	> Новость как раз про то, что по умолчанию keepass не поможет Это почему? Если ключ хранится в кипассе используется шифрование кипасса, а не ssh. При этом сам ключ может физически отсутствовать на диске.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Xasd (ok), 06-Авг-18, 19:50
	> При этом сам ключ может физически отсутствовать на диске. а вирус может взять ключ от Кипаса из оперативной памяти? или Кипас настолько божественнен что запрещает законам физики-и-логики работать? нет мыслей о том что сохранив все нужные пароли в Кипасе -- пользователь на золотом блюдечке приложил хакеру свои пароли? особенно учитывая что Кипас то и дело нужно открывать и вводить туда пароль
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от AnonPlus (?), 07-Авг-18, 02:14
	А злоумышленник может взять вас в заложники и отрезать пальцы, пока вы не скажете ему пароль. Это проблема кипасса или openssh?
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от AnonPlus (?), 07-Авг-18, 02:16
	Судя по всему Кипасс вы даже не пробовали, а то знали бы, что кроме ключа там ещё и ключевые файлы. И если у вас на машине сидит нечто с рут-правами, что может стырить и буфер обмена, и переслать саму базу, и вообще всё может, то может уже признать, что это не софт виноват, а прокладка меж монитором и стулом?
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	64. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от нах (?), 07-Авг-18, 11:18
	> Судя по всему Кипасс вы даже не пробовали, а то знали бы, что кроме ключа там ещё и ключевые > файлы. это чтоб при битом секторе на диске тебе уже и никакой ключ не помог? Правильное решение, архиверное. Еще один способ прос..ть все полимеры. А от чего защищает - я что-то не вкуриваю. (а, ну да, тут рядом подсказали - это для любителей хранить пароли в дропбоксе. Правда, неясно, где они хранят ключевые файлы и какой иначе прок от паролей в дропбоксе) > И если у вас на машине сидит нечто с рут-правами зачем мне рут-права чтобы стырить _твои_ файлы и _твой_ буфер (в линуксе проще сразу сесть на клавиатуру, не мучаясь с анализом содержимого clipboard) ? Выскочил из браузерного сэндбоксика, и все, ты мой. Или ты настолько альтернативно-одаренный, что keepass запускаешь от рута?
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним84701 (ok), 07-Авг-18, 19:52
	> это чтоб при битом секторе на диске тебе уже и никакой ключ не помог? Eсли ключ не забэкаплен, значит он не важен/нужен. Логично же. И вообще, тогда нельзя использовать все форматы-контейнеры/cжатие без восстановительной инфы. > зачем мне рут-права чтобы стырить _твои_ файлы и _твой_ буфер (в линуксе > проще сразу сесть на клавиатуру, не мучаясь с анализом содержимого clipboard) Не знаю, что вы собрались делать с зашифрованной базой, но вообще-то кипасовый авто-тайп как минимум не ловится xspy-демкой и не остается в буфере обмена. Ну и не следует недооценивать защитный комплекс "Неуловимый Джо".
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от kvaps (ok), 07-Авг-18, 03:12
	> а вирус может взять ключ от Кипаса из оперативной памяти? > или Кипас настолько божественнен что запрещает законам физики-и-логики работать? > нет мыслей о том что сохранив все нужные пароли в Кипасе -- > пользователь на золотом блюдечке приложил хакеру свои пароли? особенно учитывая что > Кипас то и дело нужно открывать и вводить туда пароль Ну, KeePass использет надежные методы шифрования и разрабатывался как раз  с идеей что саму базу паролей можно закинуть в какой-нибудь ненадежный Dropbox и не переживать за секьюрность. Кроме того,если уж на то пошла речь, он реализует и защиту буфера обмена, а его исходники уже много раз анализировались на уязвимости независимыми командами разработчиков. Сам приватный ключ ssh, замечу, не пароль от него, можно хранить как аттачмент внутри базы. А при запуске кипасса, подключать его в пользовательский сеанс ssh-agent. С этой задачей отлично справляется KeepassXC. Таким образом получается что приватный ssh-ключ у вас не хранится в файловой системе вообще и единственный способ украсть его - это взломать ваш кипасс.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	79. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Xasd (ok), 13-Авг-18, 11:28
	> единственный способ украсть его - это взломать ваш кипасс что наверняка является тривиальной и многократно-решённой задачей, так как защититься от взлома по факту не возможно при условии что злоумышленник софт запускает прямо у тебя на компьютере, и при этом соблазн решить задачу взлома именно Keepass* (а не чего-то другого) высокий так как достоверно ясно что там будут пароли
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от kvaps (ok), 13-Авг-18, 11:48
	>> единственный способ украсть его - это взломать ваш кипасс > что наверняка является тривиальной и многократно-решённой задачей, так как защититься > от взлома по факту не возможно при условии что злоумышленник софт > запускает прямо у тебя на компьютере, и при этом соблазн решить > задачу взлома именно Keepass* (а не чего-то другого) высокий так как > достоверно ясно что там будут пароли Но согласитесь, что украсть зашифрованный ssh-rsa ключ и украсть зашифорванную базу keepass - две совершенно разные вещи. Как минимум на один вектор атаки меньше.
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним84701 (ok), 07-Авг-18, 19:48
	>> При этом сам ключ может физически отсутствовать на диске. > а вирус может взять ключ от Кипаса из оперативной памяти? А еще вирус может проделывать абсолютно то же самое с браузером, угоняя сохраненные в браузере или в паре дюжин самых распространенных программ (FileZilla, почтовый клиент) пароли. И по вашей же логике, мастерпароли не помогут т.к. кипасс принципиально -- хранилище с мастерпаролем (на самом деле мастерпароль отсечет большую часть поделок и, при правильной конфигурации, неплохо осложнит жизнь оставшимся, но … это в другом, не черно-белом мире). > нет мыслей о том что сохранив все нужные пароли в Кипасе Нет мыслей, что вообще храня пароли, пользователь на золотом блюдечке предлагает их (х|к)акирам? А не храня -  всем тем, кто после попытки угона паролей оставляет банальный "form grabber" и отлавливает все вводимые логины, плюс всем тем, кто взламывает БД с данными пользователя, т.к. держание всех паролей в голове обычно результирует в многократном использовании пары-тройки простых паролей.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	71. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от пох (?), 07-Авг-18, 20:35
	> А еще вирус может проделывать абсолютно то же самое с браузером открыл америку! > И по вашей же логике, мастерпароли не помогут естественно. Его и вводить не надо, ты его еще в начале сессии ввел. мастерпароль - исключительно от товарища прапорщика, который изъял у тебя компьютер в качестве вещдока, а заодно гоняет на нем GTA5. К лейтенанту он обращаться не будет (а то дальше в gta будет играть майор), поэтому за свой вконтактик можешь не беспокоиться. у мурзилы там, кстати, довольно странное шифрование, в него десяток лет никто не заглядывал, так что о надежности даже заикаться не стоит.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним84701 (ok), 07-Авг-18, 20:52
	>> А еще вирус может проделывать абсолютно то же самое с браузером > открыл америку! Всегда рад помочь. Обращайтесь! >> И по вашей же логике, мастерпароли не помогут > естественно. Его и вводить не надо, ты его еще в начале сессии ввел. Да ну? Правда? Защищает только от угона ФФ-файла с паролями (причем так, что как минимум кидисы со своими угонщиками и прочими iStealerами обламывали зубы)? Тогда да, не нужно … А вообще, речь шла о "ненужности" паролехранилок и попытке с моей стороны показать, что "альтернативы" еще хуже. Так что не будь таким занудой - один Астахал у нас тут уже есть. > мастерпароль - исключительно от товарища прапорщика, который изъял у тебя компьютер в > качестве вещдока, а заодно гоняет на нем GTA5. К лейтенанту он обращаться не будет (а то дальше в gta будет играть майор), Кроме лейтенанта и товарища прапорщика есть возможность про*бать или  "задарить" какому нибудь Васяну IRL. И вот чтобы потом не орать дурным голосом, выдирая волосы на седалище и судожно пытаясь сменить пароли всех ресурсов … В общем, защита (в ослабленном варианте) от того же самого, что и шифрование диска/хомяка, плюс (в моей реальности) как минимум от кучи малвари, потому что угнать файл обычно всегда проще, чем спереть пароли из памяти. Не, если у вас в форточках все еще можно сделать OpenProcess(PROCESS_VM_READ …) любого пользовательского процесса без доп. привилегий, то это все таки ваши, форточковые проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от пох (?), 07-Авг-18, 23:21
	> Да ну? Правда? Защищает только от угона ФФ-файла с паролями (причем так, а зачем его угонять, если наиболее вероятный вектор - сам файрфокс, точнее открытый в нем сайт? когда мне понадобился дамп этих паролей - первое, что нашел гугль, был какой-то банальный скрипт, который просто вывел их все текстом в очередной таб. Не думаю что нельзя было вместо этого вывести в POST. > А вообще, речь шла о "ненужности" паролехранилок и попытке с моей стороны > показать, что "альтернативы" еще хуже. Так что не будь таким занудой ну стикеры на мониторе немного получше. Камеру только заклеивать не забывай, и на мобиле, с которой ходишь мимо этого монитора, тоже. > Кроме лейтенанта и товарища прапорщика есть возможность про*бать или  "задарить" какому > нибудь Васяну IRL. ну так васян тоже умеет отжимать мабилы, а не подбирать пароли. Тут я буду спать спокойно - во всяком случае, после их неторопливой смены. > Не, если у вас в форточках все еще можно сделать OpenProcess(PROCESS_VM_READ …) > любого пользовательского процесса без доп. привилегий, то это все таки ваши, а у "вас" какие дополнительные привиллегии нужны пользователю, чтобы подцепиться отладчиком (о ужас, ему доступна память процесса!)  к собственному процессу? У вас,как и в форточках, давным-давно уже вся мультиюзерность чисто для галочки, а на деле у вас есть root и ваш любимый логин vasya (которому, внезапно, и принадлежит вся стоящая информация на данной машинке, и от него же все и работает). проламывают либо первое, через дырки в демонах, либо второе, через браузер и прочее. а такого чтоб шелл от nobody получить, бывает нынче исключительно редко почему-то.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним84701 (ok), 08-Авг-18, 12:49
	> ну стикеры на мониторе немного получше. Камеру только заклеивать не забывай, и > на мобиле, с которой ходишь мимо этого монитора, тоже. Лучше тем, что их не очень удобно таскать с собой, перепечатывать, как и хранить на них автогенерированные пароли 12+ знаков? Сомнительное преимущество. А чтобы угнать пароли со стикера с помощью камеры, нужен доступ к этой самой камере, но тогда угон паролей со стикеров будет не самой насущной твоей проблемой. >> Не, если у вас в форточках все еще можно сделать OpenProcess(PROCESS_VM_READ …) >> любого пользовательского процесса без доп. привилегий, то это все таки ваши, > а у "вас" какие дополнительные привиллегии нужны пользователю, чтобы подцепиться отладчиком > (о ужас, ему доступна память процесса!)  к собственному процессу? > У вас,как и в форточках, давным-давно уже вся мультиюзерность чисто для галочки, Ну да, все ж дурны-ы-ы-е, не догадываются, куда им до опеннетчиков … https://github.com/openssh/openssh-portable/blob/5ee3fb5affd... platform_disable_tracing(int strict) { #if defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE)     /* Disable ptrace on Linux without sgid bit */     if (prctl(PR_SET_DUMPABLE, 0) != 0 && strict)         fatal("unable to make the process undumpable"); #endif #if defined(HAVE_SETPFLAGS) && defined(__PROC_PROTECT)     /* On Solaris, we should make this process untraceable */     if (setpflags(__PROC_PROTECT, 1) != 0 && strict)         fatal("unable to make the process untraceable"); #endif #ifdef PT_DENY_ATTACH     /* Mac OS X */     if (ptrace(PT_DENY_ATTACH, 0, 0, 0) == -1 && strict)         fatal("unable to set PT_DENY_ATTACH"); #endif } > а на деле у вас есть root и ваш любимый логин vasya Плохая из тебя Ванга: % awk -F':' '$3>999 { print $1}' /etc/passwd nobody anonym restricted sandbox
	Ответить | Правка | Наверх | Cообщить модератору

45. "Критика шифрования ключей в OpenSSH"	+/–
Сообщение от Аноним (45), 06-Авг-18, 02:38
NPM -- передовая технология по обнаружению проблем с безопасностью в SSH (а также самом NPM)
Ответить | Правка | Наверх | Cообщить модератору

65. "Критика шифрования ключей в OpenSSH"	+/–
Сообщение от Аноним (65), 07-Авг-18, 16:49
Хранение ключей на флешке решает проблему?
Ответить | Правка | Наверх | Cообщить модератору

	66. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (-), 07-Авг-18, 17:19
	только до того момента, пока флешка не вставленна в пеку. А в контексте новости (возможность распространять малваре через npm) и это не спасет, если там кейлоггер (ну, вернее - утекут только лишь те ключи, которые вводились за время наличия гадости на пеке). Берите старый цпу от амд, ддр3, хдд (что там у нас еще то было с уязвимостями, кроме рязаней, ддр4 и ссд...), загоняйте все в виртуалку и можете хоть плайнтекстом хранить на хосте
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Критика шифрования ключей в OpenSSH"	+1 +/–
	Сообщение от пох (?), 07-Авг-18, 20:27
	> Хранение ключей на флешке решает проблему? нет, добавляет - теперь надо не прое... еще и флэшку, причем ее и терять нельзя, и упускать в чужие руки нельзя, и еще надо заботиться о дублировании и надежном/безопасном хранении уже и копии флэшки. А смонтированная в $HOME/.ssh - ничем она не отличается от просто $HOME/.ssh решает проблему хранение ключей в токене, но не бестолковом убикее (во всяком случае, в его популярных вариантах применения) а в таком, где ключ никогда не покидает токен, и расшифровка осуществляется _токеном_ (да, небыстренько будет, но для ssh терабиты и не нужны). Причем только после подтверждения пином, что ты действительно его хозяин. Выдергивание токена на ходу - автоматически обеспечивает killswitch. Чуть менее надежный вариант, но не ограничивающий производительность - генератор otp-паролей на базе смарткарты. Опять же нужно стырить у тебя смарткарту _и_ при этом еще и пин подсмотреть. Что неколько сложнее чем по отдельности то и другое, и позволяет пину быть простым и запоминаемым. Насколько я понял, законченное решение такого типа продает RSA. За $NNNNNN/штука.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	74. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (74), 08-Авг-18, 03:38
	не понятна претензия к юбикею: он умеет быть смарткартой аж двумя способами. гуглить yubikey piv и yubikey openpgp. в первом случае даже есть спец. процедура аттестации, позволяющая удостовериться, что приватный ключ был сгенерен внутри токена и поэтому точно неизвлекаем / не сдублирован где-то еще. оба способа вполне себе популярны и рекомендуемы
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от Аноним (75), 08-Авг-18, 09:22
	> удостовериться, что приватный ключ был сгенерен внутри токена И насколько надежные ключи оно генерит?
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от нах (?), 08-Авг-18, 12:12
	>> удостовериться, что приватный ключ был сгенерен внутри токена > И насколько надежные ключи оно генерит? от васяна - вполне надежные, даже если вам попалась версия с багом. но вот пользоваться этим для ssh, и быть застрахованным от такого же васяна, но получившего доступ к вашей системе - не получится (во всяком случае, без геморроя).
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Критика шифрования ключей в OpenSSH"	+/–
	Сообщение от нах (?), 08-Авг-18, 12:10
	> не понятна претензия к юбикею: он умеет быть смарткартой аж двумя способами. ну так прочитайте внимательно, о чем речь. умеет. только у меня настоящих смарткарт  -полные карманы. По цене пластмассы и без геморроя с покупкой. а работать в качестве законченного решения - не умеет (умеет другими способам, которые, обычно, и используют - либо извлекая из него ключ, либо используя его otp, разумеется, хакнувшему тебя васяну все это тоже доступно, кнопка - защита никакая). Соответственно, ненужен. правильное использование смарткарты, о котором вам писали - вообще не предполагает ее сования в компьютер.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема