Comments 29
Вопрос не по теме :)

"javax/swing/JPasswordField".equals(className)


Есть какой-то особый смысл в этом? Обычно сравнение инвертировали, чтобы случайно не опечататься и не выполнить присваивание вместо него. Но в случае с equals() такой угрозы нет. Привычка? :)
В Java так страхуются от null. Иначе если в className вдруг окажется null, то приложение выбросит NullPointerException.
Я бы сказал, что в с случае, если логикой алгоритма не предусматривается, что className может быть null, то лучше пусть программа выбросит исключение, чем просто тихо ничего не произойдет.
Сравнивают константу со значением, а не наоборот, чтобы в случае если значение null, не было NullPointerException. В Java начиная с 7 можно сделать так — Objects.equals(«javax/swing/JPasswordField»,className); Это будет работать при null значениях параметров (метод внутри проверяет на null).
P.S. Не успел чуть чуть с ответом :-) Но оставлю, т.к. есть ещё инфа.
Когда сам столкнулся с подобной проблемой, написал плагин, который при загрузке проекта, выбрасывал пароли от keystore и key в консоль. Т.к. плагины могут получить доступ к этому хранилищу.
«А пароль оказался тем же самым, что и был записан, но вводился в русской раскладке»
Обычно так бухгалтера делают :) Не с 1С программиста начинали?
Я вас умоляю, бухгалтера используют даты рождения :)
А ввод не в той раскладке это как доп. мера защиты. Не обязательно же использовать словарное слово, можно выдумать свое, которое будет легко запомнить на русском, но в другой раскладке это будет набор букв (+ не забываем что до сих пор в некоторых местах пароль может содержать только английские символы). Добавить сюда пару цифр и символов и вот у вас уже вполне хороший пароль.
Ха-ха, нет. Просто раскладку забыл видимо поменять, потому-то второй пароль был как полагается английскими буквами
но на самом деле при атаке по словарю оба варианта одинаково слабы
Согласен, но второй вариант избавляет от проблем с раскладкой
Интересно. Наверно, Eclipse Memory Analyzer'ом (или другим анализатором) было бы нетрудно выдрать, просто сняв дамп памяти, когда окошко с паролем на экране, а потом поискав в дампе все объекты типа JPasswordField.
Во-первых, я не додумался :)
Во-вторых, разработчики могли не ставить сохраненный пароль в JPasswordField, а брать напрямую из хранилища
В-третьих, писать программу все таки веселей, чем нудно искать по дампу последовательность символов
Я не критикую, просто предлагаю альтернативный вариант :-) Писать программы очень весело, с этим целиком согласен. Но и по дампу искать не нудно: вводите название класса, получаете все его экземпляры. Не думаю, что в памяти очень много компонентов JPasswordField. Если бы не было сохранённого пароля, то да, было бы посложнее. Эклипс обычно не заполняет форму с сохранённым паролем: если хочешь поменять, вводи заново. В таких случаях можно подцепиться отладчиком через remote debug, поставить брейкпоинт на вход в какой-нибудь подходящий метод.
Можно проще. Альтернативное решение: скачать исходники IntelliJ IDEA Community Edition (ядро идеи) с гитхаба, прописать в вашу главную идею в bin/idea.exe.vmoptions две дополнительные строки
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5006

Запускаем первую идею, запускаем вторую идею с сорцами. Коннектимся. Ставим break point в класс DialogWrapper и вытаскиеваем то, что нужно.
Возможно, сработает, не спорю. Но мой метод позволяет увидеть пароль в вообще любой java-программе, где используется JPasswordField.
Основная мораль поста — сохраненные пароли в java это ОЧЕНЬ небезопасно.
Сохраненные пароли где угодно — это небезопасно. Т. к. сохраненный пароль где-то должен лежать plain text'ом. В нормальном варианте используется мастер-пароль, которым это хранилище обратимо шифруется.
В Idea тоже все зашифровано мастер-паролем, но в какой-то момент все равно все равно в открытом виде светится.
Ниже klirichek написал один из вариантов. И такое я уже встречал в части софта. Причем, количество «звездочек» может соответствовать или не соответствовать длине пароля, зависит от того, как задумал автор. И оно не сильно сложнее простой подстановки пароля в текстовое поле (один внешний индекс, чтобы определить, есть ли пароль для данного случая).
Как написал ниже — главное если пароль должен куда-то передаться, то его можно отследить и перехватить. Да, с этим можно бороться, но так как пароль в какой-то момент времени будет в открытом виде, то из-за наличия технологии java agent и библиотек позволяющих менять байт-код на лету, данные можно считать.
Поможет видимо только физическая защита компьютера :)
Это принципиально ничем не отличается от вытаскивания этого пароля из памяти любого другого процесса под ida. Если вы хотите, чтобы ключ было невозможно скопировать — то берите внешний токен (смарт-карта), который сам выполнит подпись/шифрование не раскрывая ключа. Все остальные способы светят ключ в памяти (т. к. он нужен при работе алгоритма шифрования/подписи), а значит его можно извлечь.

Просто такая атака практически может быть слишком дорогой, что понизит рентабельность предприятия по её осуществлению. В случае java она немного дешевле.
Ну, на самом деле не пароль, а текст, вставленный в это поле!
А пароль… Например, я могу просто узнать длину и вставить туда нужное количество звёздочек. А пароль никуда не вставлять, а просто использовать по назначению.
Пароль то все равно будет в какой-то момент в открытом виде, необязательно при вставке в текстовое поле. И вот этот момент можно отследить и перехватить пароль.
Поэтому правильный вариант — не сохранять пароли. Как бы вы их не зашифровали, если зашифрованный файл и хитрая программа, которая этот файл расшифровывает, лежат рядом — пароль можно расшифровать.
Only those users with full accounts are able to leave comments. Log in, please.