Pull to refresh
32
0
Send message
Извините, Роман, я перепутал имя обращаясь к Вам. :)
Живые примеры есть, были отправлены Яндексу, публиковать их в открытом доступе, считаю не совсем правильным решением. Хотя, полагаю, Яндекс не считает вышесказанное проблемой. Со мной они не связались, исправления которые они внесли не закрывают проблему. Вчера проверил, перебор пароля все равно возможен. По большому счету функцию защиты пароля надо убирать, так как она таковой не является, но на это они пойти не могут. Полагаю, причиной появления этой фичи явилась проблема с mail.ru и подсмотренный у Google Password Alert https://googleblog.blogspot.ru/2015/04/protect-your-google-account-with.html
Мне приводили пример про бронежилет. Бронежилет не гарантирует безопасности, но это дополнительная защита. Но хочу отметить, когда бойцам дают бронежилет, им не говорят, что теперь они могут идти в атаку во весь рост и с ними «ничего такого не случится»» :)
Полагаю, это была одна из причин появления данной фичи в Яндекс браузере.
Иван, вы так и не ответили на третий пункт. И да, посмотрел вечером исправление в версии 15.12, оно не устранило возможность перебора паролей, более того позволяет увеличить скорость перебора на два порядка.
Проверялось на версии 15.10.2454.3865 в конце октября, тогда же вам и сообщил.
Хотелось бы услышать Ваш комментарий на третий пункт.
Яндекс в курсе.
Сила знает пароль(скорее его хэш) если он сохранен в хранилище паролей браузера. И да, она сравнивает его перед отправкой формы и останавливает отправку формы.
Это и огорчает…
Переданные данные всегда хэшируются, не вводите в заблуждение сообщество. Не хотите это слушать от меня, проконсультируйтесь с тем кому вы доверяете.
Практика показывает, что создание доверенной среды на рабочем месте видится невозможным :)
То что эти действия завернуты в одну функцию сути не меняет. Данные хэшируются, затем подписываются.
Сертифицированная (используемая) в России криптография без хэша не работает.
Вы описали действительно правильное решение! На сколько я знаю, именно такое решение и ожидается после сертификации Secure Messaging-а в новой версии Рутокен ЭЦП. Ну а токены с мониторчиками есть — http://www.rutoken.ru/products/all/rutoken-pinpad/
Лучше по порядку. Схемы с хранением закрытых ключей на сервере существуют, они вполне легетимны. Все упирается в доверие сервису. Плюс к тому необходимо обеспечить защиту канала и аутентификацию сервера. Вариантов реализации много. Вторая проблема Man in the Browser, в случае заражения компьютера пользователя. В этом случае проблема с токеном существует при любой схеме использования, что в общем-то и встречается в существующей действительности. Зловред может подсунуть на подпись любой документ и в «классической» схеме, и в описанной. И действительно, гарантировано решить эту проблему может только использование доверенных устройств с отдельным экраном.
Подписать можно только хэш документа, по другому — никак.
Могу сказать что скорость хэширования токена (Рутокен ЭЦП) около 100 кб в секунду. То есть 10 мб файл будет хэшироваться грубо полторы минуты. На сервере это доли секунды. Для маленьких файлов предлагаемая схема не интересна, для больших весьма эффективна. А автору, конечно, надо бы приложить результаты тестов для показательности.
Если вам так хочется считать, то пожалуйста :) Просто есть совсем крошечная разница между «воткнуть токен в USB порт» и установить и настроить Крипто Про. Кто знает эту разницу, тот поймет о чем речь. :)
Рутокен ЭЦП сертифицирование средство электронной подписи. В плагине нет крипты.
Витя, привет! разродились все-таки :)

Information

Rating
Does not participate
Registered
Activity