>>В контексте всего вышесказанного: чем собственно вас не устраивает стандартная схема двух
>>сертификатов? У сервера (serverhost.crt) и запароленый персональный у клиента (client.p12) +
>>ес-сно авторизация по логину/паролю??
>>
>>Лично я не могу себе представить что-нить более ударопрочное. Сам так работаю...
>>
>Я предполагаю, что компьютер пользователя неконтролируем системным администратором, например, при удаленном доступе.
>В таком случае, с затрояненного компьютера можно слить и сертификат, и
>что немаловажно, пароль в открытом виде.
Тогда это будет уже не вина вашего комплекса - это во-первых. За утерю, равно как и передачу (Вы ведь не планируете страховаться еще и от передачи учетных данных, сканируя радужную оболочку глаза, я надеюсь?) учетных данных третьему лицу разработчик не может нести ответственность. Как пример: ISP не возмещает убытков, связанных с передачей/утерей пароля пользователя.> А так -- пароль зашифрован,
>и, при каждой новой сессии шифруется заново. То есть при каждом
>подключении к серверу, последовательность записываемых символов зашифрованного пароля разная. Следовательно теряется
>смысл брутфорса пароля, так как он будет разный. Кстати, можно и
>ключевую фразу генерить случайным образом, с определенной периодичностью.
Так если вернуться к вашему предыдущему абзацу, реч идет о случае, когда у пользователя в системе уже стоит кейлоггер и у некоего негодяя есть рутовые права... Наука еще не придумала как с этой ситуацией справиться. Даже биометрия не поможет, т.к. можно драйвера перекомпилить ... НЕ ЗАГОНЯЙТЕСЬ.
Цепочка (наличие сертификата)-(пароль к сертификату)-(аутентификация на сервере) достаточно прочна.
Если пользователю кажется, что сертификат и пароль к нему знает 3-е лицо, помогает опять-же стандартная процедура отзыва сертификата... :)
Этот велосипед уже придуман. Не стоит ломать над еще одним голову :)
>Думаю, что имеет смысл перенести обсуждение этого вопроса. Пишите в мыло, дам
>свою аську.
Если-что - буду рад помочь... Дело хорошее :)
