Доброго времени суток!
Не подскажете ли способ сделать (в проге на WinAPI) ввод пароля, защищенный от "подглядывания"
других приложений (хотя бы от клавиатурных хуков)? Работать предстоит под
Win2K/XP, т.е. вариант с собственным драйвером отпадает (т.к. может не
быть прав на его инсталляцию).
Лучшее до чего я додумался -- это ставить свой хук, не передающий
управление дальше по hook chain, но этот подход стопроцентной гарантии не
дает...
Здравствуйте, a-lex, Вы писали:
AL>Доброго времени суток! AL>Не подскажете ли способ сделать (в проге на WinAPI) ввод пароля, защищенный от "подглядывания"
Можно его шифровать. Генерить случайный пароль шифрования
и при вводе текста сразу его шифровать.
А перед использованием расшифровывать.
На мне сейчас Kossовские уши и в них играет — silent
Здравствуйте, siavol, Вы писали:
S>Можно его шифровать. Генерить случайный пароль шифрования S>и при вводе текста сразу его шифровать. S>А перед использованием расшифровывать.
Беда в том, что "шпион" может поставить глобальный клавиатурный хук и записать "сырые" нажатия клавиш. Из получившегося лога относительно легко вытащить последовательности символов, возможно являющиеся паролем.
Здравствуйте, a-lex, Вы писали:
AL>Доброго времени суток! AL>Не подскажете ли способ сделать (в проге на WinAPI) ввод пароля, защищенный от "подглядывания" AL>других приложений (хотя бы от клавиатурных хуков)? Работать предстоит под AL>Win2K/XP, т.е. вариант с собственным драйвером отпадает (т.к. может не AL>быть прав на его инсталляцию). AL>Лучшее до чего я додумался -- это ставить свой хук, не передающий AL>управление дальше по hook chain, но этот подход стопроцентной гарантии не AL>дает...
А если поставить свой хук и из него передавать приложению
код другой клавиши, а приложение этот код преобразует обратно
Вот только чей хук будет раньше срабатывать ваш или вражеский?
На мне сейчас Kossовские уши и в них играет — Bt — The Road To Lostwithiel
Здравствуйте, siavol, Вы писали:
S>А если поставить свой хук и из него передавать приложению S>код другой клавиши, а приложение этот код преобразует обратно S>Вот только чей хук будет раньше срабатывать ваш или вражеский?
Интересная идея. Можно еще генерировать ложные нажатия клавиш (напр. через SendInput). Надо попробовать.
Для меня лично остается открытым вопрос: "Как сделать что бы твой хук гарантированно выполнялся раньше вражинского?"
Если есть решение, то очень хотелось бы о нем узнать
На мне сейчас Kossовские уши и в них играет — Bt & Paul Van Dyke — Flaming June
Здравствуйте, siavol, Вы писали:
S>Здравствуйте, a-lex
S>Для меня лично остается открытым вопрос: "Как сделать что бы твой хук гарантированно выполнялся раньше вражинского?" S>Если есть решение, то очень хотелось бы о нем узнать
Предположим, такой алгоритм существует. Тогда если он будет применем вражеским хуком, он будет выполняться раньше вашего. Отсюда следует, что гарантии этого быть не может.
есть ссылочка на исходники PGP, там это дело как-то защищается, можешь гдлянуть если интересно.
AL>Спасибо за ссылку, поглядел. Хорошо, но не панацея...
я кстати сам не смотрел раскажи хоть что высмотрел
Если хочешь что-бы нельзя было проследить ввод пароля — тогда самый дейсвенный способ — не нажымать вобще этих "кнопок" — тоесть я могу предложить реализацию:
Рисуешь на экране клавиатуру (можно даже для верности специальным цветом) и ввод осуществляешь мышью.
Здравствуйте, vasketsov, Вы писали:
V>Предположим, такой алгоритм существует. Тогда если он будет применем вражеским хуком, он будет выполняться раньше вашего. Отсюда следует, что гарантии этого быть не может.
Разумно, хотя и печально
Тогда, наверно, остается единственный вариант — завалить противника синтезированным дерез SendInput ложным вводом.
Здравствуйте, Odi$$ey, Вы писали:
OE>я кстати сам не смотрел раскажи хоть что высмотрел
Там на время ввода пароля ставится куча хуков: WH_KEYBOARD, WH_CBT, WH_GETMESSAGE и WH_MSGFILTER; все они не вызывают CallNextWindowsHookEx и возвращают 0 (WH_KEYBOARD, кроме того, записывает нажатия клавиш для получения введенной строки).
Такая система должна быть уязвима для "подглядывания" при помощи WH_KEYBOARD_LL и WH_DEBUG.
Здравствуйте, Whisperer, Вы писали:
W>Если хочешь что-бы нельзя было проследить ввод пароля — тогда самый дейсвенный способ — не нажымать вобще этих "кнопок" — тоесть я могу предложить реализацию:
W>Рисуешь на экране клавиатуру (можно даже для верности специальным цветом) и ввод осуществляешь мышью.
W>От клавиатурных хуков железно спасаешься
Боюсь, пользователь меня не поймет. Но вообще, что-то в этом есть
Здравствуйте, a-lex, Вы писали:
AL>Там на время ввода пароля ставится куча хуков: WH_KEYBOARD, WH_CBT, WH_GETMESSAGE и WH_MSGFILTER; все они не вызывают CallNextWindowsHookEx и возвращают 0 (WH_KEYBOARD, кроме того, записывает нажатия клавиш для получения введенной строки). AL>Такая система должна быть уязвима для "подглядывания" при помощи WH_KEYBOARD_LL и WH_DEBUG.
В DriveCrypt (на которую, кстати, Ody$$ey ссылку и дал) на время ввода пароля можно перейти в какой-то особый "консольный" режим, в котором не работают ни хуки, не подглядывание в TextBox. Исходники там есть. Вроде, http://www.drivecrypt.com/.
Здравствуйте, retalik, Вы писали:
R>Здравствуйте, a-lex, Вы писали:
AL>>Там на время ввода пароля ставится куча хуков: WH_KEYBOARD, WH_CBT, WH_GETMESSAGE и WH_MSGFILTER; все они не вызывают CallNextWindowsHookEx и возвращают 0 (WH_KEYBOARD, кроме того, записывает нажатия клавиш для получения введенной строки). AL>>Такая система должна быть уязвима для "подглядывания" при помощи WH_KEYBOARD_LL и WH_DEBUG. R>В DriveCrypt (на которую, кстати, Ody$$ey ссылку и дал) на время ввода пароля можно перейти в какой-то особый "консольный" режим, в котором не работают ни хуки, не подглядывание в TextBox. Исходники там есть. Вроде, http://www.drivecrypt.com/.
Если я не ошибаюсь, оно как раз и реализовано с помощью собственного драйвера, что мне, увы, не подходит
Здравствуйте, a-lex, Вы писали:
AL>Доброго времени суток! AL>Не подскажете ли способ сделать (в проге на WinAPI) ввод пароля, защищенный от "подглядывания" AL>других приложений (хотя бы от клавиатурных хуков)? Работать предстоит под AL>Win2K/XP, т.е. вариант с собственным драйвером отпадает (т.к. может не AL>быть прав на его инсталляцию). AL>Лучшее до чего я додумался -- это ставить свой хук, не передающий AL>управление дальше по hook chain, но этот подход стопроцентной гарантии не AL>дает...
AL>Заранее спасибо
Я не смотрел, что там есть в исходниках, на которые тут приводили ссылки, поэтому возможно ничего нового не предложу. Тем не менее есть такая мысль:
1) Сделать свой декстоп на WINSTA0 (CreateDesktop)
2) Установить этот декстоп на поток, где вводится пароль (SetThreadDesktop)
3) Создать окно ввода пароль
4) Активировать десктоп (SwitchDestop)
5) Запросить пароль
6) Переключить десктоп обратно (SwitchDestop)
7) Установить старый декстоп на поток, где вводится пароль (SetThreadDesktop)
8) Удалить дектоп (CloseDesktop)
Эти действия можно делать из сервиса, играя с настройками доступа, для пущей безопасности.
Logon в систему на NT сделан примерно также, т.е. ввод пароля и хранитель экрана — это другие десктопы.
Здравствуйте, Roman_M, Вы писали:
RM>Я не смотрел, что там есть в исходниках, на которые тут приводили ссылки, поэтому возможно ничего нового не предложу. Тем не менее есть такая мысль: RM>[skipped]
Здравствуйте, a-lex, Вы писали:
AL>Здравствуйте, vasketsov, Вы писали:
V>>Предположим, такой алгоритм существует. Тогда если он будет применем вражеским хуком, он будет выполняться раньше вашего. Отсюда следует, что гарантии этого быть не может.
AL>Разумно, хотя и печально AL>Тогда, наверно, остается единственный вариант — завалить противника синтезированным дерез SendInput ложным вводом.
А как бороть прогу которая будет засекать нажаты или нет те или иные клавиши через определённые (очень короткие) промежутки времени, например функцией GetAsyncKeyState?
раскажи хоть что высмотрел
— тоесть я могу предложить реализацию:
