Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,698 Сказал «Спасибо»: 500 раз Поблагодарили: 2049 раз в 1589 постах
|
Автор: nomhoi С другой стороны можно и отпечаток подставить другой. Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Используйте криптографию правильно. Изучите API и что доступно при проверке\подписании... После успешной проверки - проверяете информацию о подписанте (сертификат передаёте либо в cms, либо отдельно "ищите у себя" в известным данным из cms, для raw - будет "сложнее" - прослойку писать, чтобы найти нужный открытый ключ). |
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,698 Сказал «Спасибо»: 500 раз Поблагодарили: 2049 раз в 1589 постах
|
Автор: two_oceans
Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Не забываем, что у сервера должно быть еще доверие к УЦ. При регистрации по отпечатку - проверяющий проверил\активировал доступ... а вот с информацией (ИНН\СНИЛС) встречал такие ИС... которые "автоматически" пускали к себе и давали полный доступ (бесплатно и без смс!)... опираясь лишь на данные из сертификата, а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах
|
Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Автор: Андрей * а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Не факт... у них мог быть добавлен тестовый УЦ в доверенные, и все проверки проходили на ура. Вообще удивляюсь зачем люди добавляют тестовый УЦ в системное хранилище на "боевых" серверах, хотя можно сделать пару лишних движений для безопасности: добавить тестовый УЦ в отдельное файловое PEM/P7B хранилище, открывать такое хранилище только на тестовых билдах, вручную проверять цепочку. Например, у меня программа проверяет свой путь - если папка, где идет разработка есть в пути, используется тестовый режим; на боевом сервере путь другой и тестовые "примочки" отключаются.
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,698 Сказал «Спасибо»: 500 раз Поблагодарили: 2049 раз в 1589 постах
|
Автор: two_oceans Автор: Андрей * Не забываем, что у сервера должно быть еще доверие к УЦ. Справедливо. Подразумевается, что доверие отдельный вопрос, который проработан. Автор: Андрей * а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Не факт... у них мог быть добавлен тестовый УЦ в доверенные, и все проверки проходили на ура. Вообще удивляюсь зачем люди добавляют тестовый УЦ в системное хранилище на "боевых" серверах, хотя можно сделать пару лишних движений для безопасности: добавить тестовый УЦ в отдельное файловое PEM/P7B хранилище, открывать такое хранилище только на тестовых билдах, вручную проверять цепочку. Например, у меня программа проверяет свой путь - если папка, где идет разработка есть в пути, используется тестовый режим; на боевом сервере путь другой и тестовые "примочки" отключаются. ... программисты продумывали, писали функции\криптопрография (хеш на хеш с солью да добавить сертификатов по вкусу) и прочее ... но всё "сломалось" через .. администратора, который для теста добавил и забыл убрать корневой (или для тестов на бою?)) Хотя и первое утверждение не факт... |
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.01.2017(UTC) Сообщений: 219 Откуда: Санкт-Петербург Сказал(а) «Спасибо»: 11 раз Поблагодарили: 41 раз в 40 постах
|
И да, не забываем все это прописать в документах. причем лучше всего со схемами, графиками и ССЫЛКАМИ и ЦИТАТАМИ с инструкций и ГОСТов. Неумному проверяющему понравится количество букв и ссылки на ГОСТ, умный разберется и вопросы отпадут. Да и сам поймешь что откуда берется и куда девается. |
Цена свободы - вечная бдительность! |
2 пользователей поблагодарили nikolkas_spb за этот пост.
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans Зачем что-то присоединять, тем более постоянную часть? Другим сертификатом просто не проверится подпись, так как открытые ключи разные в сертификатах. Поэтому подмена сертификата ничего не дает. Вы в курсе как во вторую мировую вскрывали шифр машинки Энигма? Немцы тупо писали в начале каждого шифрованного сообщения что-то типа "Дорогой господин" - фиксированную фразу, что давало возможность подбирать ключ пока не получится эта фраза.
Поэтому добавлять постоянную фразу вредно, весь смысл чтобы стейт был целиком неизвестным заранее (случайно сгенерированным, например). Как вариант, может быть хэшем от соединения нескольких меняющихся частей, ведь хэш сложно спрогнозировать, если хотя бы одна часть неизвестна. Однако хэш от одной строки (даже будь она соединением нескольких) одинаков и прогнозируем. Я чуть выше писал, что state - уникальная строка, которая генерируется в момент открытия формы логина. Если информацию по сертификату можно извлечь из подписи, то и хэш присоединять не надо. Цитата:Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Понятно. Цитата:Цитата:Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Да, использовать cades. Скорее тогда не получится сделать без сертификата. Однако объем подписи будет несколько килобайт что неудобно. Обычно используют при аутентификации на странице Raw подпись до пары сотен байт, в ней нет сертификата. В приложении https://github.com/vgoma/crypto-pro, которое мы используем, используется CADES-BES. Получается, что сертификат включается в подпись. Цитата:Цитата:хэш на хэш - нехорошо Возможно это прочитали про зарубежные алгоритмы? потому что при формировании ключа которым шифруется контейнер из пароля в гост вычисляется 2000 раз хеш на хэш+соль. Главное не забывайте соль добавлять и хэш на хэш не проблема. Да, это понятно.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: two_oceans По идее (плагином) после проверки Verify или CadesVerify должен стать доступен массив Signers подписи из которого можно получить сертификат.
Ах, другое API... после CadesVerifyMessage (или другой подходящей, смотрите по смыслу) получается CADES_VERIFICATION_INFO, в которой есть pSignerCert
MS API: CryptVerifyMessageSignature ppSignerCert Спасибо, посмотрю.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: Андрей * Автор: nomhoi С другой стороны можно и отпечаток подставить другой. Можно ли с помощью браузерного плагина добавить сертфикат в подпись в момент создания подписи? Используйте криптографию правильно. Изучите API и что доступно при проверке\подписании... Как написал выше при создании подписи используется формат CADES-BES. Вот нашел в документации функцию CadesVerifyDetachedMessage: https://docs.cryptopro.r...desverifydetachedmessage__out_opt PCADES_VERIFICATION_INFO *ppVerificationInfo - здесь получается будет получена информацию по сертификатку. Пока непонятно, что и в каком там виде будет эта информация. Цитата:После успешной проверки - проверяете информацию о подписанте (сертификат передаёте либо в cms, либо отдельно "ищите у себя" в известным данным из cms, для raw - будет "сложнее" - прослойку писать, чтобы найти нужный открытый ключ).
Получается в ppVerificationInfo будет нужная информация по сертификату, или сам сертификат. И по этой информации мы будем искать ее в нашей базе пользователей для идентификации. Спасибо.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: Андрей * Автор: two_oceans
Искать отпечатку в БД достаточно и можно, все верно. Вопрос в продлении сертификата через год - если привязаться к отпечатку, то через год к аккаунту надо будет как-то привязывать новый сертификат, специальную страницу, например, процедуру подтверждения администратором. А если к аккаунту прописать снилс, то можно будет автоматом опознать что пользователь продлил сертификат по соответствующим полям нового сертификата. Выбор за Вами, но однозначно удобнее не привязываться к конкретному отпечатку. Не забываем, что у сервера должно быть еще доверие к УЦ. При регистрации по отпечатку - проверяющий проверил\активировал доступ... а вот с информацией (ИНН\СНИЛС) встречал такие ИС... которые "автоматически" пускали к себе и давали полный доступ (бесплатно и без смс!)... опираясь лишь на данные из сертификата, а то, что сертификат был сделан в тестовом УЦ и вообще другими лицами - ... как-то не смогли продумать. Вот инструкция: https://zakupki.gov.ru/e...adDocument.html?id=32884Нам нужно повторить функционал описанный в разделе 4.1 этой инструкции "Регистрация организации в ЕИС, сведения о которой включены в Сводный реестр (в соответствии с разделом III Порядка регистрации No27н)". Пока не понятно нужно ли будет повторять весь этот процесс, все пункты этого раздела. Пока делаю простой эпизод: сертификат пользователя или какая-то информация из сертификата в базе уже присутствует, нужно выполнить вход по ЭЦП. Т.е. нашем случае сразу уже определено, что если пользователя нет в базе, то и аутентификация не пройдет. Регистрация/активация нового пользователя будет выполняться как-то в ручном режиме, как выглядит этот процесс я не в курсе. Отредактировано пользователем 30 ноября 2020 г. 11:52:57(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 29.10.2020(UTC) Сообщений: 58 Сказал(а) «Спасибо»: 10 раз
|
Автор: nikolkas_spb И да, не забываем все это прописать в документах. причем лучше всего со схемами, графиками и ССЫЛКАМИ и ЦИТАТАМИ с инструкций и ГОСТов. Неумному проверяющему понравится количество букв и ссылки на ГОСТ, умный разберется и вопросы отпадут. Да и сам поймешь что откуда берется и куда девается. Ок. Спасибо.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close