The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Критика шифрования ключей в OpenSSH

05.08.2018 11:58

Недавняя подстановка вредоносного ПО в популярный NPM-модуль eslint, привела к отправке злоумышленникам SSH-ключей доступа, хранящихся в домашней директории нескольких тысяч разработчиков. Многие разработчики не придали этому должного внимания из-за того, что их ключи были зашифрованы с использованием пароля. Тем не менее по умолчанию в SSH для закрытых RSA-ключей применяется устаревший и ненадёжный метод шифрования, использующий блочный шифр AES с ключом в виде MD5-хэша от заданного пользователем пароля (с солью). Функция bcrypt_pbkdf, обеспечивающая должную защиту от подбора, применяется только для ключей на базе эллиптических кривых (Ed25519).

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

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

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: В популярный NPM-модуль внедрено вредоносное ПО, копирующее параметры аутентификации
  3. OpenNews: Репозиторий NPM семь часов был недоступен через прокси
  4. OpenNews: Выявлена попытка включения бэкдора в популярный NPM-пакет mailparser
  5. OpenNews: Критическая проблема в NPM 5.7, приводящая к смене прав доступа на системные каталоги
  6. OpenNews: Сбой антиспам-системы привёл к коллапсу в репозитории NPM
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/49082-ssh
Ключевые слова: ssh, md5
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (74) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:53, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Настоящей утечки SSH ключей не было. Код закладки в eslint содержал ошибку и не работал
     
     
  • 2.3, Аноним (3), 13:00, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Это совершенно меняет дело
     
  • 2.30, Аноним (30), 16:54, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скорее недоработка, которая приводила к сбою в некоторых окружениях. Параметры около 4500 разработчиков за пару часов успели на pastebin скопировать.
     

  • 1.2, Alexey (??), 13:00, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    NаPоMойке криптография не нужна. Пусть используют телнет.
     
  • 1.4, Oleg (??), 13:06, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    NPM имеет доступ ко всем файлам на компьютере. Нормальные люди устанавливают приложения в Snap и отключают доступ к домашней директории. Благо это так же просто как в Android 6+.
     
     
  • 2.7, Ага (?), 13:08, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    на секундочку Олег. И часто вы пакуете в снап ? а эту армию бибизян пробовали учить?
     
  • 2.14, Аноним (14), 13:34, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >snap

    это тот, в популярных репах которого недавно криптомайнер нашли?

    Исходя из того, что васянам доверия нет, давайте будем честными - сколько разработчиков пакуют свои поделки официально? А сколько пользователей бубунты способны собрать свой собственный снап/флатпак и настроить это дело правильно (как Вы говорите - с изоляцией и свистелками)? О том и речь.

     
     
  • 3.19, Смузи на гироскутере (?), 13:57, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>snap
    > это тот, в популярных репах которого недавно криптомайнер нашли?

    Это он, наш модный снап, и репа одна как AUR, как Google Play.


    > Исходя из того, что васянам доверия нет, давайте будем честными - сколько
    > разработчиков пакуют свои поделки официально? А сколько пользователей бубунты способны
    > собрать свой собственный снап/флатпак и настроить это дело правильно (как Вы
    > говорите - с изоляцией и свистелками)? О том и речь.

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

     
     
  • 4.33, Khariton (ok), 19:49, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. Отключенный интернет остановит криптософт от расчетов за счет моего процессора?)))
    2. А если софтина в которую встроили криптомайнер без интернета не имеет смысла?
     
     
  • 5.41, Аноним (41), 23:52, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    т.е. ты на полном серьезе считаешь, что автор майнера настолько идиот, что всем пихает одинаковый пейлоад?
     
  • 5.50, нах (?), 11:09, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > 1. Отключенный интернет остановит криптософт от расчетов за счет моего процессора?)))

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

     
  • 2.21, Crazy Alex (ok), 14:03, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Просто ставьте софт из репозитория дистрибутива штатным методом - и будет вам счастье.
     
     
  • 3.67, J.L. (?), 17:29, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Просто ставьте софт из репозитория дистрибутива штатным методом - и будет вам счастье.

    а тот софт которого случайно не оказалось в репозиториях моего дистрибутива?
    а тот софт которого случайно не оказалось в репозиториях ЛЮБОГО дистрибутива?

     
  • 2.24, KareemJabbar (?), 14:51, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Snap? Это тот, который не позволяет создавать свои собственные репозитории внутри сети? Проходите, молодой человек, проходите. Не задерживайтесь.

    Snap сдохнет ближайшие 2 года как и всё, что рождается в потрохах Canonical (mir, unity, upstart). Готов ставить крупные деньги, что к 2020 году про snap уже никто не будет помнить.

     
     
  • 3.37, Аноним (37), 22:48, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну что же, поставь.
    Давай ты ставишь 10 тысяч долларов USA, что snap не будет существовать к 1 января 2020 года. Если будет, то ты переводишь указанную сумму в российских ржублях по курсу ЦБ РФ на мой кошелек в Яндекс.Деньгах. Если согласен, то кошелек я сообщу.
     
     
  • 4.43, anonymous (??), 00:57, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    "Крупные деньги" это 500 рублей.
     
     
  • 5.46, Аноним (37), 05:27, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это сколько в деньгах? Меньше 10 долларов? А что на это купить можно?
     
  • 3.55, каноник (?), 19:40, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Snap сдохнет ближайшие 2 года как и всё, что рождается в потрохах Canonical

    да ну, бросьте, мы так быстро бабки не пилим, надо ж иногда и отдыхать. Лет пять еще проживет, а может и семь.

    А мы пока телеметрией поторгуем... такой - даже у гугля нет!

     

  • 1.5, Alexey (??), 13:06, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    SSH w. PKCS#8:
    https://habr.com/post/181320/
     
     
  • 2.8, Аноним (8), 13:13, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, но на самом деле ssh-keygen все это уже умеет. Генерируем RSA-ключ:
    $ ssh-keygen -o -t rsa -b 4096 -f <путь к ключу>

    Конвертируем существующий ключ:
    ssh-keygen -o -p -t rsa -b 4096 -f <путь к ключу>

     
     
  • 3.9, Аноним (8), 13:14, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Только при конвертации "-t rsa -b 4096" конечно не нужно.
     
  • 3.11, Alexey (??), 13:20, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    -o - спасибо,проглядел. 10 лет назад такого не было и вот, опять.
     

  • 1.6, AnonPlus (?), 13:07, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Как вариант, можно не хранить ключ в домашней директории. Тебе не нужно беспокоится о слабом шифровании, если злоумышленник вообще не получит ключа.

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

     
     
  • 2.13, Alexey (??), 13:33, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот ещё способ хранения закрытых ключей:
    https://dev.rutoken.ru/pages/viewpage.action?pageId=3440675
    (токенов можно взять у свих бухгалтеров. банки раз в год ключи меняют, новые выдают, старые остаются)
     
     
  • 3.32, Аноним (32), 17:52, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    не знаю как у Вас, но сдаешь токен и получаешь с новым эцп, они же перезаписываемые
    у нас сейчас ввели нарядную систему в электронном журнале (1с) эцп выдали каждому сотруднику, ивц заставили выдавать и следить за токенами, ивц же и обновляет их, перезаписывая токены
    либо у бухов вообще эцп на обычной флешке хранятся
     
  • 3.59, Аноним (59), 23:14, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Только вот ruToken использует для токенов обычные незащищенные микроконтроллеры, а не специальные микроконтроллеры для смарт-карт. Впрочем, последних ведь с поддержкой ГОСТ-шифрования и не бывает.
     
  • 2.51, Аноним (51), 12:30, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >можно не хранить ключ в домашней директории

    можно хранить, но под отдельным пользователем без доступа всем прочим. И su при необходимости работать с этим всем

     

  • 1.10, Аноним (10), 13:19, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Используйте уже наконец ed25519.
     
     
  • 2.12, Аноним (8), 13:21, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Привет, админ локалхоста.
     
     
  • 3.17, Аноним (17), 13:42, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что, где-то еще остались сервисы у которых ssh не понимает ed25519?
     
     
  • 4.18, PereresusNeVlezaetBuggy (ok), 13:49, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    До фига таких, сторонних. :(

    Установил кто-то когда-то в локальной сети vSphere 5.5, и работает оно до сих пор, например.

    Или там CentOS древний, на котором крутится Очень Важный Сервис, Который Нечем Заменить.

    Или коммутатор, который спасибо что вообще про SSHv2 слышал.

    Имя им — легион.

     
  • 4.20, Аноним (20), 14:03, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что, где-то ещё остались люди, способные понять, о чём вообще идёт речь в тексте новости?
     
  • 4.27, username (??), 16:02, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Виртуалки? Нет, кроме окаменелостей конечно. А вот железяк даже новых - предостаточно.
     
  • 4.29, Module 5 temperature (?), 16:45, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Куча вполне себе живых и работающих коммутаторов даже SSHv2 не понимает.
     
  • 4.44, marios (ok), 02:06, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну в dropbear их нету
     
  • 4.52, Аноним (37), 13:02, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В embedded очень распространено использование dropbear, а тот в ed25519 никак не умеет по религиозным причинам.
     
  • 3.39, Michael Shigorin (ok), 23:05, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Как автор термина -- поморщился: он вообще-то не о противопоставлении гадюшнику, именуемому "ынтерпрайзом".  И тем более не теми, кто неспособен для соответствующего хлама держать хоть DSA, а для нормальных систем -- нормальные ключи (ed25519 или на худой конец RSA от 4096 бит).

    Это типа алаверды :)

     
  • 2.40, Ivan_83 (ok), 23:30, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Элиптическое крипто менее безопасно чем RSA с ключом нужной длины.
     
  • 2.56, Xasd (ok), 19:44, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Используйте уже наконец 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

     
     
  • 3.63, пох (?), 07:28, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а угадай -- что именно *поумолчанию* генерирует ssh-keygen ?

    то что совместимо со всеми, и не вызывает, пока, проблем с надежностью. И маловероятно что при 4k ключах вообще когда-либо в обозримом будущем вызовет.

    а вот зачем оно еще и формат закрытого ключа использует совместимый незнамо с чем (в OpenSSH_5.8p2, Feb 2013 - уже понимается новый формат, хотя и не генерируется - нужен фокус с openssl, и тоже поновее 2013го года), требуя тайного знания о каких-то новоизобретенных ключах - хотя закрытые как раз никто никогда и никуда не копирует, за редкими исключениями (и там чаще всего их требуется конвертировать) - это действительно загадка.

     

  • 1.15, Аноним (15), 13:35, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Нужно это гогно пускать из докер контейнера.
     
     
  • 2.23, angra (ok), 14:33, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это который "Буква S в docker означает security"? А уж как удобно будет из под этого кодить, ты просто не поймешь за неимением опыта.
     
     
  • 3.26, username (??), 15:59, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    А что неудобного? Каталог с хост системы прокинут в контейнер, ты себе сейвишь в редакторе как и раньше. Ничего по скорости и юзкейсам не изменилось.
    Расскажите вашу боль, может вы у себя ссзб.
     
     
  • 4.47, angra (ok), 07:19, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну если задачи той сложности, что сохранения в редакторе достаточно для продуктивной работы, то таки можно. Мне же требуется несколько больше. Причем я даже знаю или могу быстро выяснить как каждую из моих хотелок реализовать при помощи docker/lxd/openvz, вот только городить и работать с этой системой костылей и подпорок всё равно неудобно. И если в случае openvz я хотя бы получаю реальную безопасность и оно того стоит, то в случае с docker только ее иллюзию. А для решения самых тупых проблем типа как в сабже хватит и чрута или отдельного пользователя.
     
  • 3.35, имя (?), 20:51, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    нормально под это кодить, подключил вольюм к контейнеру и все работает. Тестировать для разных версий тоже довольно удобно.
     
  • 2.34, Led (ok), 19:50, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > Нужно это гогно пускать из докер контейнера.

    Пускать гогно из гогна? Оригинально.

     

  • 1.16, Аноним (14), 13:38, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Имхо, отчасти они правы - в таком софте, по дефолту настройки должны быть наиболее сесурными (а всякое легаси оставлять как опцию). Что не отменяет того факта, что разработчики на ноде, в контексте новости, ссзб
     
  • 1.28, Аноним (28), 16:25, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Либо я идиот либо автор этой критики и все комментаторы. ssh не хранит MD5-хеш пароля, сам MD5-хеш является паролем для AES. MD5 плох тем, что можно быстро подобрать коллизию пароля по хешу, но у нас нет хеша! Он у нас появится только после успешного взлома. Из хеша можно получить коллизию суммы пароля и соли, а не сам пароль. Так, что это вообще никак не компрометирует сторонние сервисы! А если пользователь использовал слабый пароль, подбираемый по словарю, то при чём здесь ssh и MD5 вообще?
     
     
  • 2.38, пох (?), 22:53, 05/08/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Либо я идиот

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

    тут речь не о уязвимости md5 к подбору валидного хэша от левого источника. Речь о попытках подобрать валидный пароль, не левый, а вполне настоящий - тyпым перебором по словарю (а пароли от ключа у многих простые, потому что ключи в любом случае не принято разбрасывать жестом сеятеля). В данном случае недостаток md5 просто в том, что он считается слишком быстро, как и сам aes-cbc, и этих попыток можно даже на небыстром железе делать _много_ - пока не угадаешь, и это произойдет достаточно скоро.

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

     
     
  • 3.48, Аноним (28), 07:28, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Переборы по словарю всегда очень быстры. И это до сих пор считалось само собой разумеющемся, просто потому, что безопасники всегда исходят из идеи, что у взломщика есть суперкомпьютер или ботнет. Раньше никто не использовал видеокарты и всё равно успешно подбирали по словарю. Даже были случаи удалённых взломов по словарю. Всё дело в том, что паролей в словаре так мало, что это нивелирует ЛЮБУЮ сложность алгоритма.
     

  • 1.31, kvaps (ok), 17:29, 05/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Та причина почему нужно использовать ssh-agent, а сам ключ прятать в keepassxc
     
     
  • 2.42, Аноним (42), 00:28, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Новость как раз про то, что по умолчанию keepass не поможет
     
     
  • 3.49, kvaps (ok), 09:07, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Новость как раз про то, что по умолчанию keepass не поможет

    Это почему? Если ключ хранится в кипассе используется шифрование кипасса, а не ssh. При этом сам ключ может физически отсутствовать на диске.

     
     
  • 4.57, Xasd (ok), 19:50, 06/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > При этом сам ключ может физически отсутствовать на диске.

    а вирус может взять ключ от Кипаса из оперативной памяти?

    или Кипас настолько божественнен что запрещает законам физики-и-логики работать?

    нет мыслей о том что сохранив все нужные пароли в Кипасе -- пользователь на золотом блюдечке приложил хакеру свои пароли? особенно учитывая что Кипас то и дело нужно открывать и вводить туда пароль

     
     
  • 5.60, AnonPlus (?), 02:14, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А злоумышленник может взять вас в заложники и отрезать пальцы, пока вы не скажете ему пароль.

    Это проблема кипасса или openssh?

     
  • 5.61, AnonPlus (?), 02:16, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Судя по всему Кипасс вы даже не пробовали, а то знали бы, что кроме ключа там ещё и ключевые файлы.

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

     
     
  • 6.64, нах (?), 11:18, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по всему Кипасс вы даже не пробовали, а то знали бы, что кроме ключа там ещё и ключевые
    > файлы.

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

    > И если у вас на машине сидит нечто с рут-правами

    зачем мне рут-права чтобы стырить _твои_ файлы и _твой_ буфер (в линуксе проще сразу сесть на клавиатуру, не мучаясь с анализом содержимого clipboard) ? Выскочил из браузерного сэндбоксика, и все, ты мой.
    Или ты настолько альтернативно-одаренный, что keepass запускаешь от рута?

     
     
  • 7.69, Аноним84701 (ok), 19:52, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > это чтоб при битом секторе на диске тебе уже и никакой ключ не помог?

    Eсли ключ не забэкаплен, значит он не важен/нужен. Логично же. И вообще, тогда нельзя использовать все форматы-контейнеры/cжатие без восстановительной инфы.


    > зачем мне рут-права чтобы стырить _твои_ файлы и _твой_ буфер (в линуксе
    > проще сразу сесть на клавиатуру, не мучаясь с анализом содержимого clipboard)

    Не знаю, что вы собрались делать с зашифрованной базой, но вообще-то кипасовый авто-тайп как минимум не ловится xspy-демкой и не остается в буфере обмена. Ну и не следует недооценивать защитный комплекс "Неуловимый Джо".

     
  • 5.62, kvaps (ok), 03:12, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/

    > а вирус может взять ключ от Кипаса из оперативной памяти?
    > или Кипас настолько божественнен что запрещает законам физики-и-логики работать?
    > нет мыслей о том что сохранив все нужные пароли в Кипасе --
    > пользователь на золотом блюдечке приложил хакеру свои пароли? особенно учитывая что
    > Кипас то и дело нужно открывать и вводить туда пароль

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

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

    Сам приватный ключ ssh, замечу, не пароль от него, можно хранить как аттачмент внутри базы.
    А при запуске кипасса, подключать его в пользовательский сеанс ssh-agent. С этой задачей отлично справляется KeepassXC.

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

     
     
  • 6.79, Xasd (ok), 11:28, 13/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > единственный способ украсть его - это взломать ваш кипасс

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

     
     
  • 7.80, kvaps (ok), 11:48, 13/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> единственный способ украсть его - это взломать ваш кипасс
    > что наверняка является тривиальной и многократно-решённой задачей, так как защититься
    > от взлома по факту не возможно при условии что злоумышленник софт
    > запускает прямо у тебя на компьютере, и при этом соблазн решить
    > задачу взлома именно Keepass* (а не чего-то другого) высокий так как
    > достоверно ясно что там будут пароли

    Но согласитесь, что украсть зашифрованный ssh-rsa ключ и украсть зашифорванную базу keepass - две совершенно разные вещи.
    Как минимум на один вектор атаки меньше.

     
  • 5.68, Аноним84701 (ok), 19:48, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> При этом сам ключ может физически отсутствовать на диске.
    > а вирус может взять ключ от Кипаса из оперативной памяти?

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

    > нет мыслей о том что сохранив все нужные пароли в Кипасе

    Нет мыслей, что вообще храня пароли, пользователь на золотом блюдечке предлагает их (х|к)акирам?
    А не храня -  всем тем, кто после попытки угона паролей оставляет банальный "form grabber" и отлавливает все вводимые логины, плюс всем тем, кто взламывает БД с данными пользователя, т.к. держание всех паролей в голове обычно результирует в многократном использовании пары-тройки простых паролей.

     
     
  • 6.71, пох (?), 20:35, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А еще вирус может проделывать абсолютно то же самое с браузером

    открыл америку!

    > И по вашей же логике, мастерпароли не помогут

    естественно. Его и вводить не надо, ты его еще в начале сессии ввел.

    мастерпароль - исключительно от товарища прапорщика, который изъял у тебя компьютер в качестве вещдока, а заодно гоняет на нем GTA5. К лейтенанту он обращаться не будет (а то дальше в gta будет играть майор), поэтому за свой вконтактик можешь не беспокоиться.

    у мурзилы там, кстати, довольно странное шифрование, в него десяток лет никто не заглядывал, так что о надежности даже заикаться не стоит.


     
     
  • 7.72, Аноним84701 (ok), 20:52, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> А еще вирус может проделывать абсолютно то же самое с браузером
    > открыл америку!

    Всегда рад помочь. Обращайтесь!

    >> И по вашей же логике, мастерпароли не помогут
    > естественно. Его и вводить не надо, ты его еще в начале сессии ввел.

    Да ну? Правда? Защищает только от угона ФФ-файла с паролями (причем так, что как минимум кидисы со своими угонщиками и прочими iStealerами обламывали зубы)? Тогда да, не нужно …
    А вообще, речь шла о "ненужности" паролехранилок и попытке с моей стороны показать, что "альтернативы" еще хуже. Так что не будь таким занудой - один Астахал у нас тут уже есть.

    > мастерпароль - исключительно от товарища прапорщика, который изъял у тебя компьютер в
    > качестве вещдока, а заодно гоняет на нем GTA5. К лейтенанту он обращаться не будет (а то дальше в gta будет играть майор),

    Кроме лейтенанта и товарища прапорщика есть возможность про*бать или  "задарить" какому нибудь Васяну IRL. И вот чтобы потом не орать дурным голосом, выдирая волосы на седалище и судожно пытаясь сменить пароли всех ресурсов …
    В общем, защита (в ослабленном варианте) от того же самого, что и шифрование диска/хомяка, плюс (в моей реальности) как минимум от кучи малвари, потому что угнать файл обычно всегда проще, чем спереть пароли из памяти.
    Не, если у вас в форточках все еще можно сделать OpenProcess(PROCESS_VM_READ …) любого пользовательского процесса без доп. привилегий, то это все таки ваши, форточковые проблемы.


     
     
  • 8.73, пох (?), 23:21, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    а зачем его угонять, если наиболее вероятный вектор - сам файрфокс, точнее откры... текст свёрнут, показать
     
     
  • 9.78, Аноним84701 (ok), 12:49, 08/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше тем, что их не очень удобно таскать с собой, перепечатывать, как и хранить... текст свёрнут, показать
     

  • 1.45, Аноним (45), 02:38, 06/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    NPM -- передовая технология по обнаружению проблем с безопасностью в SSH (а также самом NPM)
     
  • 1.65, Аноним (65), 16:49, 07/08/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хранение ключей на флешке решает проблему?
     
     
  • 2.66, Аноним (-), 17:19, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    только до того момента, пока флешка не вставленна в пеку.

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

    Берите старый цпу от амд, ддр3, хдд (что там у нас еще то было с уязвимостями, кроме рязаней, ддр4 и ссд...), загоняйте все в виртуалку и можете хоть плайнтекстом хранить на хосте

     
  • 2.70, пох (?), 20:27, 07/08/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хранение ключей на флешке решает проблему?

    нет, добавляет - теперь надо не прое... еще и флэшку, причем ее и терять нельзя, и упускать в чужие руки нельзя, и еще надо заботиться о дублировании и надежном/безопасном хранении уже и копии флэшки.

    А смонтированная в $HOME/.ssh - ничем она не отличается от просто $HOME/.ssh

    решает проблему хранение ключей в токене, но не бестолковом убикее (во всяком случае, в его популярных вариантах применения) а в таком, где ключ никогда не покидает токен, и расшифровка осуществляется _токеном_ (да, небыстренько будет, но для ssh терабиты и не нужны). Причем только после подтверждения пином, что ты действительно его хозяин. Выдергивание токена на ходу - автоматически обеспечивает killswitch.
    Чуть менее надежный вариант, но не ограничивающий производительность - генератор otp-паролей на базе смарткарты. Опять же нужно стырить у тебя смарткарту _и_ при этом еще и пин подсмотреть. Что неколько сложнее чем по отдельности то и другое, и позволяет пину быть простым и запоминаемым.
    Насколько я понял, законченное решение такого типа продает RSA. За $NNNNNN/штука.


     
     
  • 3.74, Аноним (74), 03:38, 08/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    не понятна претензия к юбикею: он умеет быть смарткартой аж двумя способами. гуглить yubikey piv и yubikey openpgp. в первом случае даже есть спец. процедура аттестации, позволяющая удостовериться, что приватный ключ был сгенерен внутри токена и поэтому точно неизвлекаем / не сдублирован где-то еще. оба способа вполне себе популярны и рекомендуемы
     
     
  • 4.75, Аноним (75), 09:22, 08/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > удостовериться, что приватный ключ был сгенерен внутри токена

    И насколько надежные ключи оно генерит?

     
     
  • 5.77, нах (?), 12:12, 08/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> удостовериться, что приватный ключ был сгенерен внутри токена
    > И насколько надежные ключи оно генерит?

    от васяна - вполне надежные, даже если вам попалась версия с багом.

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

     
  • 4.76, нах (?), 12:10, 08/08/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не понятна претензия к юбикею: он умеет быть смарткартой аж двумя способами.

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

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

    правильное использование смарткарты, о котором вам писали - вообще не предполагает ее сования в компьютер.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру