Здравствуйте.

Конечная цель какая?

Не рассматривался случай, когда контейнер на съемном носителе и который на момент проверки не подключен?

InstallCert.png (25kb) загружен 88 раз(а).


см. пример установки (через IE)
https://cryptopro.ru/certsrv/certfnsh.asp

Имя и расположение контейнера известно?

Дорогие мои, ну когда научимся задачу описывать адекватно?
"Хочу перебрать ключи (контейнеры)CAPICOM-ом" ответ: невозможно.
"Если пользователь открывает страницу"- откуда известно имя контейнера? Его только что сгенерили? Тогда у вас все есть. Есть история создания запросов и имена созданных контейнеров (с расположением). В чем вопрос?
Если у вас что-то типа УЦ и по запросу получаем сертификат, то в чем вопрос? Есть история.
Если просто ставим сертификат, то скажу страшную тайну - наплевать на имя и расположения ключа (контейнера), КриптоПро пусть ищет. А она найдет и попросит вставить коли потребуется. И перезапишет при совпадении имен...
Вот игрушка, всем клиентам ставлю. CrtView.rar (42kb) загружен 21 раз(а).
Посмотри, поиграйся. Правда это ми6, т.е. vb6. Однако при обращении к COM я думаю разница очень мала.
ХиХи: только щасс заметил. Я хотел имя контейнера писать, но при обращении к отчуждаемому носителю просили ему вставить. Отказался.
Но у cert.PrivateKey есть свойство IsHardware...
Стыдно, но ранее я об этом не подумал. Завтра поиграюсь и учту.
Успехов...

Добрый день. Наличие может быть можно определить, а вот с остальным...

Полагаю, в описанном случае немного путаются понятия об идентификации и аутентификации и есть логическая ошибка. Опознание кто пришел - идентификация. Проверка, что это именно он (по паролю или смс или наличию закрытого ключа) - аутентификация. Зная кто пришел, Вы конечно можете поднять историю на своей стороне, определить имя последнего запроса и искать конкретный запрос от этого пользователя.

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

С другой стороны, представим что пользователь хочет получить результат с другого места (перенеся туда контейнер) и там не оказалось запроса - фатал еррор и предложение генерировать снова? Это делает невозможным нормальный процесс идентификации по наличию запроса.

Поэтому наверно (если так уж хочется избавиться от всех посторонних идентификаторов) более правильный вариант будет не искать запрос, а выводить на клиентской стороне список контейнеров (или даже уже: контейнеров без сертификата). Закрытым ключом выбранного контейнера подписать некие сгенерированные сервером данные и хэш открытого ключа из контейнера. Тогда серверная сторона сможет найти по хэшу открытого ключа выпущенный на серверной стороне сертификат (идентификация клиента) и этим сертификатом проверить подпись (аутентификация по факту наличия закрытого ключа у клиентской стороны), а сгенерированные данные защищают от атак повтором известного ответа. Однако тут не уверен, возможно упираемся что такой функциональности (перечисления контейнеров, получения открытого ключа из контейнера и подписи ключом без сертификата) не найдется в интерфейсе плагина, так как это низкоуровневые функции из криптопровайдера.

Отредактировано пользователем 4 августа 2020 г. 11:04:06(UTC)  | Причина: Не указана