Консорциум W3C анонсировал (http://www.w3.org/News/2013.html#entry-9675) доступность черновых вариантов web-стандарта с реализацией Web API для использования криптографических операций в web-приложениях:
- Web Cryptography API (http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/) - определяет JavaScript API для выполнения базовых криптографических операций на стороне web-приложений, таких как манипуляции с криптографическими хэшами, генерация и проверка цифровых подписей, кодирование и декодирования данных с использованием различных методов шифрования, формирование криптографически надёжных случайных чисел. В API также предусмотрены функции для генерации ключей и управления ими. Для размещения ключей предусмотрено как временное хранилище, действующее только в пределах текущего сеанса, так и постоянное хранилище. Доступ к ключам осуществляется на основе привязки к домену (same-origin). В качестве примеров применения Web Cryptography API называется обеспечение аутентификации, использование цифровых подписей, сохранение целостности данных, реализация шифрованных коммуникаций, отличных от SSL/TLS.
- WebCrypto Key Discovery API (http://www.w3.org/TR/2013/WD-webcrypto-key-discovery-20130108/) - JavaScript API с реализацией дополнительных методов обнаружения уже подготовленных криптографических ключей, для их дальнейшего использования через Web Cryptography API.- Web Cryptography API Use Cases (http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108/) - обзор сценариев применения Web Cryptography API в Web, показывающих как решить при помощи данного API тех или иных практических задач. Например, использование Web Cryptography API для организации взаимодействия в online-банках, шифрования трафика, в видеосервисах, размещения зашифрованных документах в online-хранилищах и т.п.
URL: http://www.w3.org/News/2013.html#entry-9675
Новость: http://www.opennet.me/opennews/art.shtml?num=35788
ну так-то хорошо конешно.но это лишний уровень безопасности.
например, в случае если злоумышленнику ПОЛУЧИТЬСЯ выполнить MitM (например через компрометирующий httpS/SSL-сертификат) -- то от защиты ключами -- толку не будет (так как злоумышленник сможет подсунуть Javascript-код который заставит браузер выполнить любую операцию с ключами, нужную злоумышлешнику).
а если злоумышленнику НЕ удасться выполнить MitM -- то тогда на кой вообще нужна эта возня с ключами? обычный httpS/SSL окажется достаточным.
тоесть вся безопасность упирается в httpS/SSL (получитсья его "взломать"? или нет?). а ключи совершенно не создают погоду.
# P.S.: использовани управляемой криптографии на стороне клиента в браузере -- напоминает безопасность наподобие массивной железной двери во двор, при отсутствии стены/забора. дверь выбить с ноги нельзя, но никто и не будет пытаться даже :-)
Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ к взаимодействия с ними, а выкачать или что-либо подобное сделать будет нельзя.
> Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ
> к взаимодействия с ними, а выкачать или что-либо подобное сделать будет
> нельзя.ды в чём не прав то? доступа к ключам не будет (а я и не говорил что он будет).
но злоумышленний получит возможность выполнить любую операцию с этими ключами. тоесть это совершенно ни чем не отличается от ситуации как еслибы вообще не былобы этой системы с ключами.
# P.S.: вы думаете что в банковских системах злоумышленнику главное это украть пароль? откуда такая наивность? злоумышленнику главное совершить операцию с деньгами! желательно в момент когда пользователь сам её совершает... а на пароль ему чхать вообще
>> Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ
>> к взаимодействия с ними, а выкачать или что-либо подобное сделать будет
>> нельзя.
> ды в чём не прав то? доступа к ключам не будет (а
> я и не говорил что он будет).
> но злоумышленний получит возможность выполнить любую операцию с этими ключами. тоесть это
> совершенно ни чем не отличается от ситуации как еслибы вообще не
> былобы этой системы с ключами.Ну.... беру часть своих слов обратно :) может что-нибудь придумают? Например:
Ну например, ГУЙ будет извещать при любом взаимодействии с ключами. Например будет выводить мессадж что такой-то сайт пытается произвести какое-то действие с текущими ключами.
Или может мы что-то не учитываем,не замечаем - иначе действительно MiTM всё портит
ды нет. скорее всего всё оставят как есть. :) ..дело в том что если что-то стандартизировали -- то это вовсе не значит что это что-то полезное. :-) :-)
может быть банкам некоторым нужно *ФОРМАЛЬНО* соблюсти ряд правил.. типа "аудентификация через криптографический сертификат!".. а уж то насколько всё это безопасно сделано (где узкое горлышко в безопасности?) -- банкам может быть совершенно не важно.
С другой стороны готовится https 2.0 или как его там зовут, может там будет шифрование получше что исключит на десятки лет возможность MiTM атак. Ещё уязвимость в центрах сертификации. В общем если так жить, то ничему доверять нельзя.
ды я тож думаю что даже сейчас реализовать MitM-атаку -- ну просто нереально!поэтому и считаю что использование SSL (https) уже достаточно для безопасности :-) ..
..но вот видемо банки хотят именно использование клиентских сертификатов . наверно кому-то они там греют душу, чтоле. вот толку от этих сертификатов никакого не будет, зато *ПОКАЗУШНЫЙ* эффект безопасности наверно увеличится :-) .
> С другой стороны готовится https 2.0 или как его там зовут, может
> там будет шифрование получше что исключит на десятки лет возможность MiTMtrustwave снисходительно улыбаются.
> будет выводить мессаджА бухша потребует настроить так, чтобы эта штука не выскакивала, а если это будет невозможно - побежит к начальству жаловаться.
Одмин, который не в состоянии убедить бухшу, что так и должно быть, и начальник ИТ-отдела, который не в состоянии убедить начальство надавать бухше по башке - не на своем месте.
Хрен там, я идиотам мозги вправлять не нанимался. Моё дело объяснить, а если начальство предпочитает ради душевного комфорта жить с закрытыми глазами - на здоровье. Служебка с отметкой секретаря есть - всё, мне задницу будет чем прикрыть, а остальное - их проблемы.
Руководитель, игнорирующий одмина (особенно в вопросах безопасности), гораздо более не на своём месте )
> Руководитель, игнорирующий одмина (особенно в вопросах безопасности), гораздо более не
> на своём месте )(фыркаю) Попробуй это заявить, например, владельцу бизнеса.
Когда окажется с нулём на расчётном счёте из-за того, что игнорировал рекомендации админа - с особым удовольствием.
> Когда окажется с нулём на расчётном счёте из-за того, что игнорировал рекомендации
> админа…то админу придётся продавать почки. свою и родственников. чтобы расплатиться.
> (фыркаю) Попробуй это заявить, например, владельцу бизнеса.Не вижу проблем заявить. Бояться увольнения, что ли?
Дело не в MitM.
Теперь можно, к примеру при регистрации, генерировать пользователю надёжный сертификат, вместо его обычного пароля от всех сайтов.
> Дело не в MitM.
> Теперь можно, к примеру при регистрации, генерировать пользователю надёжный сертификат,
> вместо его обычного пароля от всех сайтов.кстате это очень не плохо! да!
...правда и без этой возможности можно использовать ключ храняшийся внутри localStore [без криптографии на стороне клиента]. это особо не уменьшит безопасность. а ключ менять можно после каждой успешной авторизации [для защиты от копирования].
впрочем криптография на стороне клиента (новый API) -- немножко всё-таки улучшит этот механизм. по краней мере точно не ухудшит :-)
> а ключ менять можно после каждой успешной авторизации [для защиты от копирования].У ВТБ24 спроси, у них опыт был, они пароли меняют, и даже хитрый пластик у уникальными циферками делают. Только несколько лет назад они забыли, что иногда сертификат на сайте обновлять нужно вовремя. В общем, похоже, некоторые пользователи попользовались не тем сайтом и интересные циферки вводили с "некоторым опережением". Так что одноразовый ключ не столь хорош, как кажется в первый момент. ИМХО, при искусном "разводе" одноразовый ключ особенно не поможет, он лишь создает ложную самоуверенность.
На самом деле очень полезная штука. Очевидным плюсом будет использование этих API при сабмите формы с паролем - улетает хеш, а не открытый пароль в сеть. Да можно написать свою js-реализацию, но согласитесь, проще будет заюзасть какую-нибудь crypto.sha1salt(...)
(да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеш, но он не будет знать пароль, который может быть используется пользователем для многих других сайтов)А с ключами.. Вы, имхо, слишком утрируете и вся криптография у вас сводится в принцип SSL. Если обменивание паблик-плючей происходит по другим каналам связи(флешка, например, из рук в руки как в банках), над которыми у злоумышленника нет никакого контроля/доступа, то разумеется, он тут вообще бессилен.
Т.е. эти API имеют довольно серьезную ценность, и как это раньше все не появилось ))
> (да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеш, но
> он не будет знать пароль, который может быть используется пользователем для
> многих других сайтов)А если так: Сайт хранит hash(salt+password), на флешке (или другом носителе) пользователь хранит salt сайта и вводит пароль сайта. Для авторизации сайт отправляет некий random_salt, через CryptoAPI получаем hash(random_salt+hash(salt+password)) и его-то мы и отправляем сайту. Таким образом, авторизация с перехватом хеша уже не состоится. Единственная проблема - первоначальный обмен этим самым salt.
> А с ключами.. Вы, имхо, слишком утрируете и вся криптография у вас
> сводится в принцип SSL. Если обменивание паблик-плючей происходит по другим каналам
> связи(флешка, например, из рук в руки как в банках), над которыми
> у злоумышленника нет никакого контроля/доступа, то разумеется, он тут вообще бессилен.Ну, алгоритм Диффи-Хеллмана на элиплических кривых с достаточной длины ключами еще считается достаточно надежной защитой от прослушивания канала для распределения ключей шифрования? А вот по поводу контроля - тут да, только другие каналы. Желательно, никому кроме легальных абонентов не подконтрольный (флешка, например, из рук в руки как в банках, а еще лучше аппаратные криптоключи).
> Т.е. эти API имеют довольно серьезную ценность, и как это раньше все
> не появилось ))Очевидно, не было в этом необходимости. Очевидно, теперь такая необходимость появилась. Дальше думайте, ищите причины и следствия.
> да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеши вот такие люди зачастую пишут не просто *про* «secure auth», а софт, где необходим secure auth… да, впрочем, и первое тоже плохо — другие-то читают. боженька, милый, убей их всех, пожалуйста. с любовью, arisu.
вы, наверное давно не сталкивались с _нормальной_ криптографией с использованием защищенных носителей, типа е-токены, и их применением в электронном документообороте на web-порталах. Так вот там сейчас полный ужос творений сумрачных гениев, каждый шлепает свой г-плагин, который работает только в IE. Отдельные товарищи используют Java applet'ы, которые работают в разных браузерах, но и ява не панацея от этого беспредела в свете последних дырок платформы.
Так вот web-api должен избавить всех от этого велосипедостроения на гусеницах. Что из этого выйдет - посмотрим.
> вы, наверное давно не сталкивались с _нормальной_ криптографией с использованием защищенных
> носителей, типа е-токены, и их применением в электронном документообороте на web-порталах....
> Отдельные товарищи используют Java
> applet'ы, которые работают в разных браузерах, но и ява не панацея
> от этого беспредела в свете последних дырок платформы.
> Так вот web-api должен избавить всех от этого велосипедостроения на гусеницах. Что
> из этого выйдет - посмотрим.Java Cryptography API (JCA) известна несколько лет и имеет промышленное применение. А что такое Web Cryptography API — вот это действительно пока ещё "велосипедостроение на гусеницах".
Просветляйтесь: http://docs.oracle.com/javase/6/docs/technotes/guides/securi...
Простите что указываю вам, но вы не прочитали комментарий.
> ява не панацея
> от этого беспредела в свете последних дырок платформыУпоминаний что JCA новинка и не было.
отлично оптимизировали все на клиента.
разгрузка сервера - клиент сам себя грузит