The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Консорциум W3C опубликовал черновик Web API для криптографических операций

09.01.2013 11:12

Консорциум W3C анонсировал доступность черновых вариантов web-стандарта с реализацией Web API для использования криптографических операций в web-приложениях:

  • Web Cryptography API - определяет JavaScript API для выполнения базовых криптографических операций на стороне web-приложений, таких как манипуляции с криптографическими хэшами, генерация и проверка цифровых подписей, кодирование и декодирования данных с использованием различных методов шифрования, формирование криптографически надёжных случайных чисел. В API также предусмотрены функции для генерации ключей и управления ими. Для размещения ключей предусмотрено как временное хранилище, действующее только в пределах текущего сеанса, так и постоянное хранилище. Доступ к ключам осуществляется на основе привязки к домену (same-origin). В качестве примеров применения Web Cryptography API называется обеспечение аутентификации, использование цифровых подписей, сохранение целостности данных, реализация шифрованных коммуникаций, отличных от SSL/TLS.
  • WebCrypto Key Discovery API - JavaScript API с реализацией дополнительных методов обнаружения уже подготовленных криптографических ключей, для их дальнейшего использования через Web Cryptography API.
  • Web Cryptography API Use Cases - обзор сценариев применения Web Cryptography API в Web, показывающих как решить при помощи данного API тех или иных практических задач. Например, использование Web Cryptography API для организации взаимодействия в online-банках, шифрования трафика, в видеосервисах, размещения зашифрованных документов в online-хранилищах и т.п.


  1. Главная ссылка к новости (http://www.w3.org/News/2013.ht...)
  2. OpenNews: Консорциум W3C планирует выпустить стандарт HTML 5.0 в конце 2014 года
  3. OpenNews: Проект по интеграции в HTML5 и браузеры DRM-слоя для защиты контента от копирования
  4. OpenNews: W3C, Adobe, Facebook, Google, HP, MS, Mozilla и Opera анонсировали совместный проект WebPlatform.org
  5. OpenNews: Консорциум W3C выпустил обновление HTML5 спецификаций и представил Filter Effects и File API
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/35788-w3c
Ключевые слова: w3c, web, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Xasd (ok), 13:01, 09/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    ну так-то хорошо конешно но это лишний уровень безопасности например, в случае... большой текст свёрнут, показать
     
     
  • 2.2, Нет ты не прав. (?), 13:09, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ к взаимодействия с ними, а выкачать или что-либо подобное сделать будет нельзя.
     
     
  • 3.3, Xasd (ok), 13:12, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ
    > к взаимодействия с ними, а выкачать или что-либо подобное сделать будет
    > нельзя.

    ды в чём не прав то? доступа к ключам не будет (а я и не говорил что он будет).

    но злоумышленний получит возможность выполнить любую операцию с этими ключами. тоесть это совершенно ни чем не отличается от ситуации как еслибы вообще не былобы этой системы с ключами.

    # P.S.: вы думаете что в банковских системах злоумышленнику главное это украть пароль? откуда такая наивность? злоумышленнику главное совершить операцию с деньгами! желательно в момент когда пользователь сам её совершает... а на пароль ему чхать вообще

     
     
  • 4.4, Может и я не прав (?), 13:17, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> Нет, ты не прав. Доступа к ключам не будет. Будет только АПИ
    >> к взаимодействия с ними, а выкачать или что-либо подобное сделать будет
    >> нельзя.
    > ды в чём не прав то? доступа к ключам не будет (а
    > я и не говорил что он будет).
    > но злоумышленний получит возможность выполнить любую операцию с этими ключами. тоесть это
    > совершенно ни чем не отличается от ситуации как еслибы вообще не
    > былобы этой системы с ключами.

    Ну.... беру часть своих слов обратно :) может что-нибудь придумают? Например:
    Ну например, ГУЙ будет извещать при любом взаимодействии с ключами. Например будет выводить мессадж что такой-то сайт пытается произвести какое-то действие с текущими ключами.
    Или может мы что-то не учитываем,не замечаем - иначе действительно MiTM всё портит

     
     
  • 5.5, Xasd (ok), 13:19, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ды нет. скорее всего всё оставят как есть. :) ..

    дело в том что если что-то стандартизировали -- то это вовсе не значит что это что-то полезное. :-) :-)

    может быть банкам некоторым нужно *ФОРМАЛЬНО* соблюсти ряд правил.. типа "аудентификация через криптографический сертификат!".. а уж то насколько всё это безопасно сделано (где узкое горлышко в безопасности?) -- банкам может быть совершенно не важно.

     
     
  • 6.6, лялялял (?), 13:25, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С другой стороны готовится https 2.0 или как его там зовут, может там будет шифрование получше что исключит на десятки лет возможность MiTM атак. Ещё уязвимость в центрах сертификации. В общем если так жить, то ничему доверять нельзя.
     
     
  • 7.8, Xasd (ok), 13:56, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ды я тож думаю что даже сейчас реализовать MitM-атаку -- ну просто нереально!

    поэтому и считаю что использование SSL (https) уже достаточно для безопасности :-) ..

    ..но вот видемо банки хотят именно использование клиентских сертификатов . наверно кому-то они там греют душу, чтоле. вот толку от этих сертификатов никакого не будет, зато *ПОКАЗУШНЫЙ* эффект безопасности наверно увеличится :-) .

     
  • 7.28, arisu (ok), 00:04, 14/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > С другой стороны готовится https 2.0 или как его там зовут, может
    > там будет шифрование получше что исключит на десятки лет возможность MiTM

    trustwave снисходительно улыбаются.

     
  • 5.10, YetAnotherOnanym (ok), 14:24, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > будет выводить мессадж

    А бухша потребует настроить так, чтобы эта штука не выскакивала, а если это будет невозможно - побежит к начальству жаловаться.

     
     
  • 6.16, жабабыдлокодер (ok), 17:00, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Одмин, который не в состоянии убедить бухшу, что так и должно быть, и начальник ИТ-отдела, который не в состоянии убедить начальство надавать бухше по башке - не на своем месте.
     
     
  • 7.17, YetAnotherOnanym (ok), 17:07, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хрен там, я идиотам мозги вправлять не нанимался. Моё дело объяснить, а если начальство предпочитает ради душевного комфорта жить с закрытыми глазами - на здоровье. Служебка с отметкой секретаря есть - всё, мне задницу будет чем прикрыть, а остальное - их проблемы.
     
  • 7.24, ФФ (ok), 09:49, 10/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Руководитель, игнорирующий одмина (особенно в вопросах безопасности), гораздо более не на своём месте )
     
     
  • 8.25, Аноним (-), 14:33, 10/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    фыркаю Попробуй это заявить, например, владельцу бизнеса ... текст свёрнут, показать
     
     
  • 9.26, YetAnotherOnanym (ok), 15:13, 10/01/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Когда окажется с нулём на расчётном счёте из-за того, что игнорировал рекомендац... текст свёрнут, показать
     
     
  • 10.29, arisu (ok), 00:05, 14/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    8230 то админу придётся продавать почки свою и родственников чтобы расплатит... текст свёрнут, показать
     
  • 9.27, ФФ (ok), 17:30, 10/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не вижу проблем заявить Бояться увольнения, что ли ... текст свёрнут, показать
     
  • 2.7, Аноним (-), 13:32, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не в MitM.
    Теперь можно, к примеру при регистрации, генерировать пользователю надёжный сертификат, вместо его обычного пароля от всех сайтов.
     
     
  • 3.9, Xasd (ok), 13:59, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Дело не в MitM.
    > Теперь можно, к примеру при регистрации, генерировать пользователю надёжный сертификат,
    > вместо его обычного пароля от всех сайтов.

    кстате это очень не плохо! да!

    ...правда и без этой возможности можно использовать ключ храняшийся внутри localStore [без криптографии на стороне клиента]. это особо не уменьшит безопасность. а ключ менять можно после каждой успешной авторизации [для защиты от копирования].

    впрочем криптография на стороне клиента (новый API) -- немножко всё-таки улучшит этот механизм. по краней мере точно не ухудшит :-)

     
     
  • 4.20, Аноним (-), 19:44, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а ключ менять можно после каждой успешной авторизации [для защиты от копирования].

    У ВТБ24 спроси, у них опыт был, они пароли меняют, и даже хитрый пластик у уникальными циферками делают. Только несколько лет назад они забыли, что иногда сертификат на сайте обновлять нужно вовремя. В общем, похоже, некоторые  пользователи попользовались  не тем сайтом и интересные циферки вводили с "некоторым опережением". Так что одноразовый ключ не столь хорош, как кажется в первый момент. ИМХО, при искусном "разводе" одноразовый ключ особенно не поможет, он лишь создает ложную самоуверенность.

     
  • 2.15, Йоу (?), 16:34, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На самом деле очень полезная штука. Очевидным плюсом будет использование этих API при сабмите формы с паролем - улетает хеш, а не открытый пароль в сеть. Да можно написать свою js-реализацию, но согласитесь, проще будет заюзасть какую-нибудь crypto.sha1salt(...)
    (да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеш, но он не будет знать пароль, который может быть используется пользователем для многих других сайтов)

    А с ключами.. Вы, имхо, слишком утрируете и вся криптография у вас сводится в принцип SSL. Если обменивание паблик-плючей происходит по другим каналам связи(флешка, например, из рук в руки как в банках), над которыми у злоумышленника нет никакого контроля/доступа, то разумеется, он тут вообще бессилен.

    Т.е. эти API имеют довольно серьезную ценность, и как это раньше все не появилось ))

     
     
  • 3.22, Аноним (-), 00:48, 10/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > (да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеш, но
    > он не будет знать пароль, который может быть используется пользователем для
    > многих других сайтов)

    А если так: Сайт хранит hash(salt+password), на флешке (или другом носителе) пользователь хранит salt сайта и вводит пароль сайта. Для авторизации сайт отправляет некий random_salt, через CryptoAPI получаем hash(random_salt+hash(salt+password)) и его-то мы и отправляем сайту. Таким образом, авторизация с перехватом хеша уже не состоится. Единственная проблема - первоначальный обмен этим самым salt.

    > А с ключами.. Вы, имхо, слишком утрируете и вся криптография у вас
    > сводится в принцип SSL. Если обменивание паблик-плючей происходит по другим каналам
    > связи(флешка, например, из рук в руки как в банках), над которыми
    > у злоумышленника нет никакого контроля/доступа, то разумеется, он тут вообще бессилен.

    Ну, алгоритм Диффи-Хеллмана на элиплических кривых с достаточной длины ключами еще считается достаточно надежной защитой от прослушивания канала для распределения ключей шифрования? А вот по поводу контроля - тут да, только другие каналы. Желательно, никому кроме легальных абонентов не подконтрольный (флешка, например, из рук в руки как в банках, а еще лучше аппаратные криптоключи).

    > Т.е. эти API имеют довольно серьезную ценность, и как это раньше все
    > не появилось ))

    Очевидно, не было в этом необходимости. Очевидно, теперь такая необходимость появилась. Дальше думайте, ищите причины и следствия.


     
  • 3.30, arisu (ok), 00:09, 14/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > да, злоумышленник узнает хеш и сможет авторизоваться отправив это же хеш

    и вот такие люди зачастую пишут не просто *про* «secure auth», а софт, где необходим secure auth… да, впрочем, и первое тоже плохо — другие-то читают. боженька, милый, убей их всех, пожалуйста. с любовью, arisu.

     
  • 2.18, name (??), 17:45, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +/
    вы, наверное давно не сталкивались с _нормальной_ криптографией с использованием защищенных носителей, типа е-токены, и их применением в электронном документообороте на web-порталах. Так вот там сейчас полный ужос творений сумрачных гениев, каждый шлепает свой г-плагин, который работает только в IE. Отдельные товарищи используют Java applet'ы, которые работают в разных браузерах, но и ява не панацея от этого беспредела в свете последних дырок платформы.
    Так вот web-api должен избавить всех от этого велосипедостроения на гусеницах. Что из этого выйдет - посмотрим.
     
     
  • 3.19, iZEN (ok), 19:12, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > вы, наверное давно не сталкивались с _нормальной_ криптографией с использованием защищенных
    > носителей, типа е-токены, и их применением в электронном документообороте на web-порталах.

    ...
    > Отдельные товарищи используют Java
    > applet'ы, которые работают в разных браузерах, но и ява не панацея
    > от этого беспредела в свете последних дырок платформы.
    > Так вот web-api должен избавить всех от этого велосипедостроения на гусеницах. Что
    > из этого выйдет - посмотрим.

    Java Cryptography API (JCA) известна несколько лет и имеет промышленное применение. А что такое Web Cryptography API — вот это действительно пока ещё "велосипедостроение на гусеницах".

    Просветляйтесь: http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoS

     
     
  • 4.21, Имя (?), 19:56, 09/01/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Простите что указываю вам, но вы не прочитали комментарий.
    > ява не панацея
    > от этого беспредела в свете последних дырок платформы

    Упоминаний что JCA новинка и не было.

     

  • 1.23, Аноним (-), 02:57, 10/01/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    отлично оптимизировали все на клиента.
    разгрузка сервера - клиент сам себя грузит
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру