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

    Кроме того, организация MITM после первичного обмена открытыми ключами невозможна.
  • Вместо паролей тату и… таблетки
    +2
    Кстати, Google владеет Motorola Mobility :)
  • Как работает FIDO
    +2
    Возможно и не важный. Строгая (двухфакторная) аутентификация известна давно, однако широкого применения в интернет она так и не нашла.
  • Берем под контроль криптографию в облачном хранилище MEGA
    0
    Если это его заинтересует, то только в качестве PR. Цель использования шифрования на МЕГЕ защитить хостинг от правообладателей. Как бы это не было реализовано на МЕГЕ, оно свою задачу выполнят. Безопасность информации их вряд ли волнует.
    Однако подобный подход может быть эффективен при организации защищенного обмена информацией на различных публичных чатах и сервисах электронной почты. Интересно было бы посмотреть такие решения.
  • Алгоритм генерации QR-кода
    0
    Можно использовать Google API — developers.google.com/chart/infographics/docs/qr_codes Ниже в примере закодирована эта ссылка:
    image
  • Безопасная среда выполнения криптографических операций
    0
    Да, защитить можно только тех, кто этого хочет. Однако в системах ДБО банк вынужден обеспечивать безопасность клиентов, и как вы верно заметили удобство используемых механизмов безопасности играет далеко не последнюю роль.
  • Безопасная среда выполнения криптографических операций
    0
    описание здесь
  • HTTPS в браузере Xpress
    0
    Вам как сотруднику компании должно быть известно точно :)
  • HTTPS в браузере Xpress
    0
    К сожалению, общественность была проинформирована только после публикации на эту тему. А это не айс.
  • HTTPS в браузере Xpress
    0
    Да, возможно «читаем» было бы вернее.
    Многие мобильные браузеры используют оптимизацию трафика на своих серверах. Однако, или не трогают https (Amazon Silk) или предупреждают (Opera Mini).
  • HTTPS в браузере Xpress
    +1
    Если информация где-то присутствует в открытом виде, рано или поздно, она станет достоянием общественности.
    p.s. https прокси не имеет доступа к передаваемому содержимому, а передает зашифрованные данные как есть.
  • Щит и меч в системах ДБО. Прикладное решение
    +2
    В данном контексте touchscreen уместно, однако такие устройства чаще называют trustscreen :)
  • От идеи до гаджета. Путь «Самурая» в России (часть 2)
    +1
    Укажите пожалуйста длину ключа.

    Это верно? «Портативный накопитель информации по п.17, отличающийся тем, что аппаратный ускоритель шифрации выполнен обеспечивающим шифрование данных в соответствии с взятыми за основу симметричными алгоритмами шифрования ГОСТ 28147-89 с измененной длиной ключа до 32 бит.»
  • От идеи до гаджета. Путь «Самурая» в России (часть 2)
    +1
    Не понятна логика…
    Вы собираетесь проводить сертификацию устройство в ФСБ? Если да, изменение алгоритмов не пройдет. Если нет, зачем городить огород с ГОСТ если есть аппаратные решения с AES. Решения эти в разы производительней и дешевле. Если вы боитесь «закладок» в реализации AES алгоритмов, то ваше решение ни чего не меняет. Во первых, почему мы должны доверять вашей реализации? Во вторых, никто не отменял возможности производителя чипов реализовать «закладки» позволяющей извлечь содержимое вашего микропроцессора.
    Так же хотелось бы понять юридические аспекты. Разработка средств защиты информации требует наличия лицензии ФСТЭК, а разработка средств шифрования лицензии ФСБ. Как у вас с этими вопросами?
  • От идеи до гаджета. Путь «Самурая» в России (часть 2)
    –1
    Какие алгоритмы шифрования? Какая скорость чтения\записи?
  • Phorm
    0
    Думаю, проблема с позиционирование этого решения в массах. Короче PR не отработал. Я к тому, что это решение не сильно отличается от того, что есть сейчас со сбором и таргетированием рекламы. Просто это надо как-то донести конечному пользователю. :)
  • Phorm
    0
    Кстати, использование такой системы вполне себе отвечает интересам СОРМ. :)