The OpenNET Project / Index page

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

Консорциум W3C представил спецификацию Web Cryptography API

17.09.2012 14:35

Консорциум W3C анонсировал первый черновой вариант web-стандарта Web Cryptography API, определяющего JavaScript API для выполнения базовых криптографических операций на стороне web-приложений, таких как манипуляции с криптографическими хэшами, генерация и проверка цифровых подписей, кодирование и декодирования данных с использованием различных методов шифрования, формирование криптографически надёжных случайных чисел.

В API также предусмотрены функции для генерации ключей и управления ими. Для размещения ключей предусмотрено как временное хранилище, действующее только в пределах текущего сеанса, так и постоянное хранилище. Доступ к ключам осуществляется на основе привязки к домену (same-origin). В качестве примеров применения Web Cryptography API называется обеспечение аутентификации, использование цифровых подписей, сохранение целостности данных, реализация шифрованных коммуникаций, отличных от SSL/TLS.

  1. Главная ссылка к новости (http://www.w3.org/News/2012#en...)
  2. OpenNews: Adobe, Google и Microsoft профинансируют привлечение дополнительного персонала к работе W3C над HTML5
  3. OpenNews: Раскол между W3C и WHATWG может привести к развитию двух независимых стандартов HTML5
  4. OpenNews: Консорциум W3C представил WebDriver API для тестирования web-приложений с учётом поведения браузеров
  5. OpenNews: Консорциум W3C представил черновик стандарта "Do Not Track", основанного на разработках Mozilla
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/34862-w3c
Ключевые слова: w3c, crypt, javascript, api
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 15:59, 17/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Когда же кто-нить заменит этот JavaScript на что-нить поприличнее?
     
     
  • 2.2, The Doctor (ok), 16:01, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Например, http://www.dartlang.org/
     
     
  • 3.4, Crazy Alex (ok), 16:57, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь.
     
     
  • 4.7, JL2001 (ok), 18:42, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl
    > и эффективный доступ к нему из байткода (была бы пара примерно
    > как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления
    > нативные вычисления, а если есть желание - хоть интерпретатор Питона туда
    > засунь.

    есть же JVM и Java-аплеты - чем не устраивает ? хотя компиляция байткода в натив не очень очевидна

     
     
  • 5.8, arisu (ok), 18:46, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > есть же JVM и Java-аплеты — чем не устраивает ?

    как минимум — политикой распространения и тем, что это левая по отношению к браузеру фиготень.

     
     
  • 6.10, JL2001 (ok), 18:56, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> есть же JVM и Java-аплеты — чем не устраивает ?
    > как минимум — политикой распространения и тем, что это левая по отношению
    > к браузеру фиготень.

    ну я бы сказал что движок жаваскрипта такая же левая хрень по отношению к браузеру
    а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной реализацией JVM начиная с 7 версии

     
     
  • 7.11, arisu (ok), 19:00, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ну я бы сказал что движок жаваскрипта такая же левая хрень по
    > отношению к браузеру

    лучше не говори: можешь оконфузиться.

    > а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной
    > реализацией JVM начиная с 7 версии

    и что? удачи тебе в написании кода для «чистой» JVM.

     
  • 7.40, Аноним (-), 14:35, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > ну я бы сказал что движок жаваскрипта такая же левая хрень по
    > отношению к браузеру

    Не совсем так: скрипт может содержаться прямо в HTMLке. Как кусок текста. А с явой так не катит. Не говоря о том что пока ее рантайм взлетит - можно кофе попить успеть.

     
  • 5.28, Crazy Alex (ok), 09:46, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не устраивает:
    1) привязкой к Ораклу, который в последнее время(и не только) совсем невменяем
    2) тормозностью и прожорливостью джавы и невозможностью от этого избавиться
    3) тем, что далеко не всё хорошо ложится на jvm
     
     
     
    Часть нити удалена модератором

  • 7.55, Аноним (-), 18:44, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Руки надо затачивать у программеров

    Так идите и заточите. Всей планете, которая клепает сайтики и сайты. Как закончите - приходите.

     
  • 4.12, filosofem (ok), 19:18, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь.

    Джава с NaCl, одно дебаг эвривэр решето, второе вообще непортабельное, а про его безопасность даже подумать страшно(или смешно). Эта дрянь уже была в моём уютном Вэбе и была вышвырнута поганой метлой. Ходить по тем же граблям еще раз? Спасибо не надо.

     
     
  • 5.27, Crazy Alex (ok), 09:44, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Может объясните, какимбоком вообще может быть уязвим NaCl? Или так, болезненные фантазии? А что до портабельности - вариант с LLVM у них допилен, если вы не в курсе. И да,там специальный LLVM, байткод которого портабелен.
     
     
  • 6.35, filosofem (ok), 11:08, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Может объясните, какимбоком вообще может быть уязвим NaCl?

    Так же как ActiveX

    >И да,там специальный LLVM, байткод которого портабелен.

    Байткод и натив ― взаимоисключающие параграфы.

     
     
  • 7.37, Crazy Alex (ok), 13:15, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможно - нет способа сделать соотвествующий переход, плюс ограничивается набор приемлемых инструкций. Всё это верифицируется движком NaCl в браузере.

    По байткоду и нативу - поинтересуйтесь, как работают компиляторы - хоть llvm, хоть gсс - работа идёт со своим представлением, которое может быть сериализовано - получите байткод. Генерация кода для платформы - практичсеки последний шаг. Вот этот шаг в случае NaCl и делается на клиенте - получаете чистейший натив.

    Вообще похоже, что вы совершенно не в курсе о чем речь.

     
     
  • 8.39, filosofem (ok), 14:22, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно знаком не столько с NaCl, сколько lowlevel кодингом, чтобы не писать,... текст свёрнут, показать
     
     
  • 9.52, Crazy Alex (ok), 18:39, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А кроме бугага что-то предъявить можете И гугловское описание читали, конечно ... текст свёрнут, показать
     
     
  • 10.54, arisu (ok), 18:42, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а чего тут удивительного, что Джо 8212 Неуловимый ... текст свёрнут, показать
     
  • 10.62, filosofem (ok), 20:30, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Тут такая ситуация Чем ближе код к машинному, тем больше вопросов по совместимо... текст свёрнут, показать
     
  • 8.49, arisu (ok), 16:44, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    то же самое говорили и про жабу скажи, пожалуйста раз в жабе мало того, что ма... текст свёрнут, показать
     
     
  • 9.53, Crazy Alex (ok), 18:42, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да прочти спеку, она довольно занятна Если коротко - угрозы a-la js кривая обр... текст свёрнут, показать
     
     
  • 10.56, arisu (ok), 18:44, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    да при чём тут спеки-то никакой верификатор не является на 100 надёжным как и... текст свёрнут, показать
     
  • 8.57, Аноним (-), 18:48, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, вы не знакомы с устройством процессоров и тем как выполняется код Или п... текст свёрнут, показать
     
  • 4.22, Аноним (-), 08:35, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а если есть желание - хоть интерпретатор Питона туда засунь.

    Ну так напиши интерпритатор питона на JS. Извращаться - так уж по полной!

     
     
  • 5.29, Crazy Alex (ok), 09:47, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да?
     
     
  • 6.41, Аноним (-), 14:38, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да?

    На фоне питоня JS очень быстрый язык, так что разницу никто и не заметит :)

     

  • 1.3, Crazy Alex (ok), 16:54, 17/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Ну да. Вместо того чтобы дать достаточно быструю числодробилку (на базе NaCl, к примеру) они на каждый чих будут клепать специфические интерфейсы? "Гениальная" идея - прибить софт к алгоритмике, доступной в браузере.
     
     
  • 2.5, Аноним (-), 17:44, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы потом каждый пыонер тащил в систему свою криптографию с блекджеком и шлюхами? Спасибо не надо.
     
     
  • 3.30, Crazy Alex (ok), 09:48, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Угу, лучше чтобы браузер определял, какие алгоритмы возможны. Как же.
     
     
  • 4.36, Аноним (-), 11:42, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1) По твоему лучше если злоумышленник, подменив удаленный сервер, заменит код NaCl на свой зонд со всеми вытекающими?

    2) Пионерские XOR в качестве криптографии не нужны.

    3) Драфт описывает интерфейсы, а не реализацию браузеров. Браузер вполне может не реализовывать криптоалгоритмы самостоятельно, а перенаправлять запросы javascript специализированному криптопровайдеру, который может выполняться даже в отдельном процессе.


     
     
  • 5.38, Crazy Alex (ok), 13:22, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1) Злоумышленник с тем же успехом может и клиентские вызовы к API на что угодно заменить

    2) кто всерьёз к безопасности относится - у того будут нормальные алгоритмы. А кто абы как - у того и без XOR будет дыра на дыре. А вот что будут какие-нибудь эллиптические кривые или понимание формата ключей OpenSSH вбито в  браузеры - сильно сомневаюсь. Скорее всего ограничатся стандартным набором - AES/RSA.

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

     
     
  • 6.45, Аноним (-), 15:38, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1) Подменив эти API приватного ключа то он все равно не получит.

    2 и 3) Вы вообще документ читали нет? "As the API is meant to be extensible in order to keep up with future developments within cryptography and to provide flexibility, there are no strictly required algorithms. Thus users of this API should check to see what algorithms are currently recommended and supported by implementations."

     
     
  • 7.59, Crazy Alex (ok), 18:49, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А какой смысл прятать свой приватный ключ от кода, сгруженного с сервера, на котором и живут твои данные?

    И то что оно meant - это одно. А потом окажется, что какой-нибудь IE не реализует эллиптические кривые - и всё, кури бамбук.

     
  • 6.58, Аноним (-), 18:48, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > 1) Злоумышленник с тем же успехом может и клиентские вызовы к API
    > на что угодно заменить

    Сильно сложнее - для этого юзеру надо всю ОС расхакать вдоль и поперек.

     

  • 1.9, XoRe (ok), 18:50, 17/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, чем не устроил стандартный браузерный функционал SSL/TLS ключей?
     
     
  • 2.21, Аноним (-), 08:20, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ты в курсе вообще что такое криптография, мальчик?
     
     
  • 3.23, Аноним (-), 08:41, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да, вот я в курсе и поэтому не особо понимаю а что помешает атакующему заменять... большой текст свёрнут, показать
     

  • 1.13, Аноним (-), 19:18, 17/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие, флеши, локальные сервера, достало.
     
     
  • 2.24, Аноним (-), 08:44, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие,
    > флеши, локальные сервера, достало.

    Дык HTML5. И да, доступ к локальным процессам - упаси боже! Как самый максимум - локальные индексированные/скульные бд и доступ к файлам которые юзер выбрал. И то сцыкотно. А то получится очередное сито типа Java, где каждый месяц затыкают дыры вида "атакующий может вылезти за пределы песочницы".

     
     
  • 3.31, Crazy Alex (ok), 09:53, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да просто надо выставить стандартный API - к примеру D-BUS интерфейс тот же (на отдельной шине, доступной для недоверенных процессов). На винде хз - но тоже что-то аналогичное должно быть, по идее. И пусть веб-приложение пуляет и слушает события, если в системе есть что-то, что умеет с этим взаимодействовать - флаг в руки. Это явно будет прямее, чем, к примеру, нынешняя хромовская сообщалка о письмах в gmail.
     
     
  • 4.32, Аноним (-), 10:22, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Да просто надо выставить стандартный API - к примеру D-BUS интерфейс...

    Вооот, нормальный вариант.

    > Дык HTML5. И да, доступ к локальным процессам - упаси боже!

    Дык не может он. Упаси боже напрямую, а если нормальный интерфейс сделать то вполне нормально, ничего особо страшного, и так куча апи есть в каждом из которых может быть дыра, зато полезно, у меня вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ делать, а как? единственное что приходит на ум это писать http сервер который будет ставится на локальный комп, работать с ним и отвечать по http, но блин изврат же, через сетевой все гонять, порты открывать, на файеры нарываться..

     
     
  • 5.42, Аноним (-), 14:40, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ
    > делать, а как?

    А потом начнется - "кто угодно может сделать что угодно, ремотно".

     
     
  • 6.51, Аноним (-), 17:15, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О ремотно речи нет, "драйвер", точнее ПО которое будет работать с железкой и отдавать нужное в браузер, надо ставить точно так же как и остальное, разрешения на копирование, установку, запуск, админские права и т.п, более того можно предусмотреть предупреждения в самом браузере, тогда будет даже лучше чем сейчас т.к. сейчас насколько я понимаю с локальным сервером можно общаться без каких либо предупреждений, вопрос не в том что это нельзя сделать сейчас, делается без хаков, но через ж, вопрос в единообразии, удобстве и дополнительном контроле) так почему бы и нет?
     
     
  • 7.60, Аноним (-), 18:50, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > в единообразии, удобстве и дополнительном контроле) так почему бы и нет?

    Потому что мы уже видим к чему это привело в Java. А два раза на одни и те же грабли может наступить только бледнолицый брат :)


     
     
  • 8.64, Аноним (-), 23:05, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да ну, сравнили мне тоже с жабой ... текст свёрнут, показать
     
  • 5.50, arisu (ok), 16:47, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ
    > делать, а как?

    доблестные китайские комсомольцы. сначала изобретают себе препятствия, а потом героически их преодолевают.

     

  • 1.14, Аноним (-), 19:25, 17/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так это и есть одна из заменяющий явааплеты технологий. Хотя пусть и разграниченный, но доступ к приватным ключам НАПРЯМУЮ из БРАУЗЕРА... - страшно!
     
     
  • 2.15, filosofem (ok), 19:35, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?
    Никогда не пользовались SSL сертификатом в браузере?

     
     
  • 3.16, Аноним (-), 20:14, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Он о том, что любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат ключи.
     
     
  • 4.17, filosofem (ok), 20:37, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Он о том, что любой джиттер можно шваркнуть, получив доступ к области
    > памяти, где лежат ключи.

    С таким же успехом как сейчас получить доступ к сертификатам, кэшу или сохраненным паролям, напр.:
    любой джиттер можно шваркнуть и читать вводимые пароли.
    любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат персональные сертификаты.

     
  • 4.26, Аноним (-), 08:47, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Он о том, что любой джиттер можно шваркнуть, получив доступ к области
    > памяти, где лежат ключи.

    Скорее, я бы пекся о том что нет никаких методов отличать скрипты друг от друга и поэтому если некий скрипт якобы "шифрует пароли в форме" - без глубокого анализа человеком фиг поймешь: натурально ли он это делает или же это Вася Пупкин отгрузил свой скрипт и пароль сейчас полетит на его сервер коллекционирования аккаунтов :)

     
  • 3.25, Аноним (-), 08:45, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?

    Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта. Который например шлет его на другой сервер с другим ключом шифрования. Просто потому что браузер грузит все что попросили и никакой защиты от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин а вовсе не вон тот сайт - никак и не узнаешь особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин может в свой скрипт прописать что угодно.


     
     
  • 4.34, filosofem (ok), 11:01, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее?
    > Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта.
    > Который например шлет его на другой сервер с другим ключом шифрования.
    > Просто потому что браузер грузит все что попросили и никакой защиты
    > от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин
    > а вовсе не вон тот сайт - никак и не узнаешь
    > особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин
    > может в свой скрипт прописать что угодно.

    Шлёт на другой сервер и чЁ?
    Если не смотреть на сертификат того сайта, который запросил аутентификацию, или не обращать внимания на предупреждения, что часть трафика не шифруется, то...
    всё равно далеко не однофигственно. Закрытый ключ Вася не увидит и трафик между юзером и сервером тоже.

     
     
  • 5.43, Аноним (-), 14:50, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, утек пароль Миссия не выполнена Во первых, да, никто на сертификаты каждый... большой текст свёрнут, показать
     
     
  • 6.44, filosofem (ok), 15:18, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну, утек пароль. Миссия не выполнена.

    Пароль, какой пароль? Не, не слышал. У нас секретный ключ.

    >В третьих, грузить код можно и с посторонних сайтов и еще много откуда через всякие инъекции и прочая. Атакующий может скроить вполне легитимно выглядящий запрос к некоему сайту не вызывающий вопросов у браузера, валидный со всех точек зрения. А что ему помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко.

    1. Перед использованием персонального сертификата, проверяется сертификат того, кто его запросил и выводит соответствующий запрос с информацией о регистраторе и регистранте.
    2. (Что более важно) Ну пошлет браузер запрос на сайт Пупкина. Пупкин узнает сколько и куда юзер денег хотел перевести. Не приятно конечно, но что дальше? Напоминаю авторизация транзакций у нас не по паролю и не по кукам, а по открытому ключу.

    >Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный.

    см. п.1

    >Ну да, ну да, все стремные моменты отрабатывает SSL (который в этом плане похож на щит из картона и деревянную саблю). А зачем эта дребедень на JS нужна если ее надежность == надежности SSL?

    Если это будет в JS, то надежность == надежности gpg. Никто не заставляет использовать инфраструктуру SSL/TLS. Ну и про картонный щит не надо утрировать тоже.

     
     
  • 7.61, Аноним (-), 19:28, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и славненько, правда вот никто не гарантирует что им пользуется именно правил... большой текст свёрнут, показать
     
     
  • 8.63, filosofem (ok), 21:32, 18/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Все не читал, но в целом претензию понял Эдакое подобие CSRF, только с полным к... текст свёрнут, показать
     
  • 2.20, Аноним (-), 22:30, 17/09/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не нашел, где там доступ к приватным ключам напрямую из браузера, ткните пальцем пжалуйста.

    Interface Key не содержит атрибутов содержащую секретную последовательность байтов ключа, только общее описание ключа.

    Атрибут extractable интерфейса Key указывает возможно ли делать export ключа или нет.

     

  • 1.33, Sw00p aka Jerom (?), 10:40, 18/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Холиварщики!!!!!! - читайте основы криптографии открытого ключа, и драфт по крипто API, и не фиг тут разводить холивар про скрипты
     

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



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

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