форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Консорциум W3C представил спецификацию Web Cryptography API"	+/–
Сообщение от opennews (??) on 17-Сен-12, 15:59
Консорциум W3C анонсировал (http://www.w3.org/News/2012#entry-9564) первый черновой вариант web-стандарта Web Cryptography API (http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/), определяющего JavaScript API для выполнения базовых криптографических операций на стороне web-приложений, таких как манипуляции с криптографическими хэшами, генерация и проверка цифровых подписей, кодирование и декодирования данных с использованием различных методов шифрования, формирование криптографически надёжных случайных чисел. В API также предусмотрены функции для генерации ключей и управления ими. Для размещения ключей предусмотрено как временное хранилище, действующее только в пределах текущего сеанса, так и постоянное хранилище. Доступ к ключам осуществляется на основе привязки к домену (same-origin (http://ru.wikipedia.org/wiki/%D0%9F%D1%8...)).  В качестве примеров применения Web Cryptography API называется обеспечение аутентификации, использование цифровых подписей, сохранение целостности данных, реализация шифрованных коммуникаций, отличных от SSL/TLS. URL: http://www.w3.org/News/2012#entry-9564 Новость: http://www.opennet.me/opennews/art.shtml?num=34862
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Консорциум W3C представил спецификацию Web Cryptography API"	+2 +/–
Сообщение от Аноним (??) on 17-Сен-12, 15:59
Когда же кто-нить заменит этот JavaScript на что-нить поприличнее?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от The Doctor (ok) on 17-Сен-12, 16:01
	Например, http://www.dartlang.org/
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 17-Сен-12, 16:57
	Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	7. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от JL2001 (ok) on 17-Сен-12, 18:42
	> Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl > и эффективный доступ к нему из байткода (была бы пара примерно > как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления > нативные вычисления, а если есть желание - хоть интерпретатор Питона туда > засунь. есть же JVM и Java-аплеты - чем не устраивает ? хотя компиляция байткода в натив не очень очевидна
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 17-Сен-12, 18:46
	> есть же JVM и Java-аплеты — чем не устраивает ? как минимум — политикой распространения и тем, что это левая по отношению к браузеру фиготень.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	10. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от JL2001 (ok) on 17-Сен-12, 18:56
	>> есть же JVM и Java-аплеты — чем не устраивает ? > как минимум — политикой распространения и тем, что это левая по отношению > к браузеру фиготень. ну я бы сказал что движок жаваскрипта такая же левая хрень по отношению к браузеру а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной реализацией JVM начиная с 7 версии
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 17-Сен-12, 19:00
	> ну я бы сказал что движок жаваскрипта такая же левая хрень по > отношению к браузеру лучше не говори: можешь оконфузиться. > а жавамашины щас на любой вкус, OpenJDK вообще гпл-православная и является стандартной > реализацией JVM начиная с 7 версии и что? удачи тебе в написании кода для «чистой» JVM.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	40. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 14:35
	> ну я бы сказал что движок жаваскрипта такая же левая хрень по > отношению к браузеру Не совсем так: скрипт может содержаться прямо в HTMLке. Как кусок текста. А с явой так не катит. Не говоря о том что пока ее рантайм взлетит - можно кофе попить успеть.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	28. "Консорциум W3C представил спецификацию Web Cryptography API"	–1 +/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 09:46
	Не устраивает: 1) привязкой к Ораклу, который в последнее время(и не только) совсем невменяем 2) тормозностью и прожорливостью джавы и невозможностью от этого избавиться 3) тем, что далеко не всё хорошо ложится на jvm
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

Часть нити удалена модератором

	55. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 18:44
	> Руки надо затачивать у программеров Так идите и заточите. Всей планете, которая клепает сайтики и сайты. Как закончите - приходите.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Консорциум W3C представил спецификацию Web Cryptography API"	–1 +/–
	Сообщение от filosofem (ok) on 17-Сен-12, 19:18
	>Тоже вариант, но, честно говоря, хотелось бы просто байткод + стандартизация NaCl и эффективный доступ к нему из байткода (была бы пара примерно как Dalvik/NDK). Пиши на чем хочешь, если надо - дергай вычисления нативные вычисления, а если есть желание - хоть интерпретатор Питона туда засунь. Джава с NaCl, одно дебаг эвривэр решето, второе вообще непортабельное, а про его безопасность даже подумать страшно(или смешно). Эта дрянь уже была в моём уютном Вэбе и была вышвырнута поганой метлой. Ходить по тем же граблям еще раз? Спасибо не надо.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	27. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 09:44
	Может объясните, какимбоком вообще может быть уязвим NaCl? Или так, болезненные фантазии? А что до портабельности - вариант с LLVM у них допилен, если вы не в курсе. И да,там специальный LLVM, байткод которого портабелен.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	35. "Консорциум W3C представил спецификацию Web Cryptography API"	–1 +/–
	Сообщение от filosofem (ok) on 18-Сен-12, 11:08
	>Может объясните, какимбоком вообще может быть уязвим NaCl? Так же как ActiveX >И да,там специальный LLVM, байткод которого портабелен. Байткод и натив ― взаимоисключающие параграфы.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 13:15
	Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможно - нет способа сделать соотвествующий переход, плюс ограничивается набор приемлемых инструкций. Всё это верифицируется движком NaCl в браузере. По байткоду и нативу - поинтересуйтесь, как работают компиляторы - хоть llvm, хоть gсс - работа идёт со своим представлением, которое может быть сериализовано - получите байткод. Генерация кода для платформы - практичсеки последний шаг. Вот этот шаг в случае NaCl и делается на клиенте - получаете чистейший натив. Вообще похоже, что вы совершенно не в курсе о чем речь.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 18-Сен-12, 14:22
	> Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там > тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможно Достаточно знаком не столько с NaCl, сколько lowlevel кодингом, чтобы не писать, что "alignment инструкций" исключает выполнение данных =) Загрузить из инета блоб с машинными инструкциями, прогнать через фильтры и запустить в контексте системного процесса. Бу. Га. Га. Уверен, что в самом гугле немногие верят, что подобная практика когда-либо будет распространена в Вэбе. > Вот этот шаг в случае NaCl и делается на клиенте > - получаете чистейший натив. Подумаешь, небольшой такой шаг, скомпилировать, да? Нет. То что нужно компилировать, то по определению не натив. > Вообще похоже, что вы совершенно не в курсе о чем речь. Речь о копипасте из пиаристический статей? Я угадал?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	52. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 18:39
	А кроме бугага что-то предъявить можете? И гугловское описание читали, конечно? Кстати, в Хроме NaCl уже версий несколько как активне по умолчанию - что-то про взломы не слышно. Не удивляет это вас? Плевать, как называть преобразование llvm-байткода в исполняемую форму - важно что получаем нормальный шустрый код, который ничем не интерпретируется, туда не лезет сбор статистики JIT и тому подобное, и что куча обычного сишного кода в эту форму компилируется без малейших проблем. И нет, речь идет о технической статейке с описанием работы NaCl - там разжевано всё - дальше некуда. Но вы её либо не читали либо тупо игнорируете.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	54. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 18-Сен-12, 18:42
	> в Хроме NaCl уже версий несколько как активне по умолчанию — > что-то про взломы не слышно. Не удивляет это вас? а чего тут удивительного, что Джо — Неуловимый?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	62. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 18-Сен-12, 20:30
	>Плевать, как называть преобразование llvm-байткода в исполняемую форму - важно что получаем нормальный шустрый код, который ничем не интерпретируется, туда не лезет сбор статистики JIT и тому подобное, и что куча обычного сишного кода в эту форму компилируется без малейших проблем. Тут такая ситуация: Чем ближе код к машинному, тем больше вопросов по совместимости с железками, операционками и браузерами и по безопасности, очевидно. Дыбаг эвривэр одним словом. В Вэбе такой номер не проходит. С DOM-ом и системными вызовами он будет ровно с такой же скоростью работать или еще медленнее, чем интерпретатор браузера, а проблем всем создает на порядки больше, чем любой скриптовый язык. В браузере нужен именно интерпретатор, общедоступный, стандартизированный и проверенный. >И нет, речь идет о технической статейке с описанием работы NaCl - там разжевано всё - дальше некуда. Но вы её либо не читали либо тупо игнорируете. хз, к чему вы апеллируете, но в этом NaCl нет ничего нового. Они предсказуемо рассчитывают, на сегментацию, DEP, фильтры инструкций и т.п. Забавно, что всё это добро тоже железо- и OS-зависимое.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	49. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 18-Сен-12, 16:44
	> Всё это верифицируется движком NaCl в браузере. то же самое говорили и про жабу. скажи, пожалуйста: раз в жабе мало того, что машинного кода нет, так ещё и верификация во все поля — откуда там постоянно уязвимости берутся?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	53. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 18:42
	Да прочти спеку, она довольно занятна. Если коротко - угрозы a-la js (кривая обработка вызовов, доступных из песочницы) никуда не деваются. Но набор инструкций и их расположение ограничены. Чтобы подобное где-то ещё применялось я не читал.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	56. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 18-Сен-12, 18:44
	> Да прочти спеку, она довольно занятна. да при чём тут спеки-то? никакой верификатор не является на 100% надёжным. как и рантайм. ну, нагенерю я такое, что верификатор просто не сможет верно отследить, куда в конце концов попадает mov — это не так уж и сложно (хотя и не так просто). и всё, приехали.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	57. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 18:48
	> Э... Вы вообще с идеей NaCl знакомы, или от балды пишете? Там > тупо ограничивается alignment инструкций так, что в принципе исполнение данных невозможно Похоже, вы не знакомы с устройством процессоров и тем как выполняется код. Или проще говоря, вы являетесь АБСОЛЮТНЫМ ЛАМЕРОМ в этом вопросе, если вам так понятнее. > Всё это верифицируется движком NaCl в браузере. Он на activex похож прежде всего тем что он есть только в одном расово верном браузере, для начала. Гугл уже достал своими вебапликухами которые не работают нигде кроме хрома. Тоже мне, замена микрософта подоспела. Более наглая и шустрая.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	22. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:35
	> а если есть желание - хоть интерпретатор Питона туда засунь. Ну так напиши интерпритатор питона на JS. Извращаться - так уж по полной!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	29. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 09:47
	Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	41. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 14:38
	> Разницу в скорости выполнения такого изврата и практически обычного cpython не понимаете, да? На фоне питоня JS очень быстрый язык, так что разницу никто и не заметит :)
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

3. "Консорциум W3C представил спецификацию Web Cryptography API"	–3 +/–
Сообщение от Crazy Alex (ok) on 17-Сен-12, 16:54
Ну да. Вместо того чтобы дать достаточно быструю числодробилку (на базе NaCl, к примеру) они на каждый чих будут клепать специфические интерфейсы? "Гениальная" идея - прибить софт к алгоритмике, доступной в браузере.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Консорциум W3C представил спецификацию Web Cryptography API"	+1 +/–
	Сообщение от Аноним (??) on 17-Сен-12, 17:44
	Чтобы потом каждый пыонер тащил в систему свою криптографию с блекджеком и шлюхами? Спасибо не надо.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	30. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 09:48
	Угу, лучше чтобы браузер определял, какие алгоритмы возможны. Как же.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	36. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 11:42
	1) По твоему лучше если злоумышленник, подменив удаленный сервер, заменит код NaCl на свой зонд со всеми вытекающими? 2) Пионерские XOR в качестве криптографии не нужны. 3) Драфт описывает интерфейсы, а не реализацию браузеров. Браузер вполне может не реализовывать криптоалгоритмы самостоятельно, а перенаправлять запросы javascript специализированному криптопровайдеру, который может выполняться даже в отдельном процессе.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	38. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 13:22
	1) Злоумышленник с тем же успехом может и клиентские вызовы к API на что угодно заменить 2) кто всерьёз к безопасности относится - у того будут нормальные алгоритмы. А кто абы как - у того и без XOR будет дыра на дыре. А вот что будут какие-нибудь эллиптические кривые или понимание формата ключей OpenSSH вбито в  браузеры - сильно сомневаюсь. Скорее всего ограничатся стандартным набором - AES/RSA. 3) Драфт прибивает к браузеру конкретную область сложных вычислений вместо того чтобы дать общий механизм для них. Если б они только абстрактное защищенное хранилище определили, где браузер бы сам пароли у пользователя спрашивал и т.п. - были бы молодцы. А они тупо ограничивают доступную алгоритмику.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	45. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 15:38
	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."
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	59. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 18:49
	А какой смысл прятать свой приватный ключ от кода, сгруженного с сервера, на котором и живут твои данные? И то что оно meant - это одно. А потом окажется, что какой-нибудь IE не реализует эллиптические кривые - и всё, кури бамбук.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	58. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 18:48
	> 1) Злоумышленник с тем же успехом может и клиентские вызовы к API > на что угодно заменить Сильно сложнее - для этого юзеру надо всю ОС расхакать вдоль и поперек.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

9. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
Сообщение от XoRe (ok) on 17-Сен-12, 18:50
Интересно, чем не устроил стандартный браузерный функционал SSL/TLS ключей?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:20
	Ты в курсе вообще что такое криптография, мальчик?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	23. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:41
	> Ты в курсе вообще что такое криптография, мальчик? Да, вот я в курсе и поэтому не особо понимаю: а что помешает атакующему заменять скрипты? Проблема в том что код грузится ремотно. Всегда. А значит атакующий обладает приличными шансами его подменить. Ну и толку с такой криптографии? У например gpg или иных подобных есть коронное преимущество: бинарь скачан заранее. А то что атакующему вот прям ща приспичило атаковать - совсем не обязывает меня пойти и сгрузить именно его затрояненый бинарник, вот прям ща и без какой либо аутентификации производителя бинарника. А вот JS - он как раз об этом самом: кто угодно может вгружать какие угодно скрипты. А вот этим скрипты совсем не обязаны оперировать криптографией именно так как я ожидаю. Например, скрипт шифрования сообщений может при отправке просто отправить до кучи не шифрованную или шифрованную ключом атакующего копию налево. И поди там еще разберись что тебя надурили...
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

13. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
Сообщение от Аноним (??) on 17-Сен-12, 19:18
Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие, флеши, локальные сервера, достало.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:44
	> Лучше бы доступ к локальным процессам стандартизовали, сколько можно, актывыксы всякие, > флеши, локальные сервера, достало. Дык HTML5. И да, доступ к локальным процессам - упаси боже! Как самый максимум - локальные индексированные/скульные бд и доступ к файлам которые юзер выбрал. И то сцыкотно. А то получится очередное сито типа Java, где каждый месяц затыкают дыры вида "атакующий может вылезти за пределы песочницы".
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	31. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Crazy Alex (ok) on 18-Сен-12, 09:53
	Да просто надо выставить стандартный API - к примеру D-BUS интерфейс тот же (на отдельной шине, доступной для недоверенных процессов). На винде хз - но тоже что-то аналогичное должно быть, по идее. И пусть веб-приложение пуляет и слушает события, если в системе есть что-то, что умеет с этим взаимодействовать - флаг в руки. Это явно будет прямее, чем, к примеру, нынешняя хромовская сообщалка о письмах в gmail.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	32. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 10:22
	> Да просто надо выставить стандартный API - к примеру D-BUS интерфейс... Вооот, нормальный вариант. > Дык HTML5. И да, доступ к локальным процессам - упаси боже! Дык не может он. Упаси боже напрямую, а если нормальный интерфейс сделать то вполне нормально, ничего особо страшного, и так куча апи есть в каждом из которых может быть дыра, зато полезно, у меня вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ делать, а как? единственное что приходит на ум это писать http сервер который будет ставится на локальный комп, работать с ним и отвечать по http, но блин изврат же, через сетевой все гонять, порты открывать, на файеры нарываться..
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	42. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 14:40
	> вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ > делать, а как? А потом начнется - "кто угодно может сделать что угодно, ремотно".
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	51. "Консорциум W3C представил спецификацию Web Cryptography API"	+2 +/–
	Сообщение от Аноним (??) on 18-Сен-12, 17:15
	О ремотно речи нет, "драйвер", точнее ПО которое будет работать с железкой и отдавать нужное в браузер, надо ставить точно так же как и остальное, разрешения на копирование, установку, запуск, админские права и т.п, более того можно предусмотреть предупреждения в самом браузере, тогда будет даже лучше чем сейчас т.к. сейчас насколько я понимаю с локальным сервером можно общаться без каких либо предупреждений, вопрос не в том что это нельзя сделать сейчас, делается без хаков, но через ж, вопрос в единообразии, удобстве и дополнительном контроле) так почему бы и нет?
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	60. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 18:50
	> в единообразии, удобстве и дополнительном контроле) так почему бы и нет? Потому что мы уже видим к чему это привело в Java. А два раза на одни и те же грабли может наступить только бледнолицый брат :)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	64. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 23:05
	Да ну, сравнили мне тоже с жабой)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	50. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от arisu (ok) on 18-Сен-12, 16:47
	> вот сейчас железка (usb считыватель) особый лежит, надо к нему доступ > делать, а как? доблестные китайские комсомольцы. сначала изобретают себе препятствия, а потом героически их преодолевают.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

14. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
Сообщение от Аноним (??) on 17-Сен-12, 19:25
Так это и есть одна из заменяющий явааплеты технологий. Хотя пусть и разграниченный, но доступ к приватным ключам НАПРЯМУЮ из БРАУЗЕРА... - страшно!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 17-Сен-12, 19:35
	Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее? Никогда не пользовались SSL сертификатом в браузере?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Консорциум W3C представил спецификацию Web Cryptography API"	+3 +/–
	Сообщение от Аноним (??) on 17-Сен-12, 20:14
	Он о том, что любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат ключи.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 17-Сен-12, 20:37
	> Он о том, что любой джиттер можно шваркнуть, получив доступ к области > памяти, где лежат ключи. С таким же успехом как сейчас получить доступ к сертификатам, кэшу или сохраненным паролям, напр.: любой джиттер можно шваркнуть и читать вводимые пароли. любой джиттер можно шваркнуть, получив доступ к области памяти, где лежат персональные сертификаты.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	26. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:47
	> Он о том, что любой джиттер можно шваркнуть, получив доступ к области > памяти, где лежат ключи. Скорее, я бы пекся о том что нет никаких методов отличать скрипты друг от друга и поэтому если некий скрипт якобы "шифрует пароли в форме" - без глубокого анализа человеком фиг поймешь: натурально ли он это делает или же это Вася Пупкин отгрузил свой скрипт и пароль сейчас полетит на его сервер коллекционирования аккаунтов :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	25. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 08:45
	> Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее? Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта. Который например шлет его на другой сервер с другим ключом шифрования. Просто потому что браузер грузит все что попросили и никакой защиты от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин а вовсе не вон тот сайт - никак и не узнаешь особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин может в свой скрипт прописать что угодно.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	34. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 18-Сен-12, 11:01
	>> Думаете вводить пароль в форму и гонять его плэйнтекстом конечно безопаснее? > Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта. > Который например шлет его на другой сервер с другим ключом шифрования. > Просто потому что браузер грузит все что попросили и никакой защиты > от подмены - нет. Поэтому то что скрипт отгрузил Вася Пупкин > а вовсе не вон тот сайт - никак и не узнаешь > особо. Ну а дальше вся криптография идет лесом. Потому что Пупкин > может в свой скрипт прописать что угодно. Шлёт на другой сервер и чЁ? Если не смотреть на сертификат того сайта, который запросил аутентификацию, или не обращать внимания на предупреждения, что часть трафика не шифруется, то... всё равно далеко не однофигственно. Закрытый ключ Вася не увидит и трафик между юзером и сервером тоже.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	43. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 14:50
	> Шлёт на другой сервер и чЁ? Ну, утек пароль. Миссия не выполнена. > Если не смотреть на сертификат того сайта, который запросил аутентификацию, Во первых, да, никто на сертификаты каждый раз не смотрит. А я нанимался наизусть заучивать параметры сертификатов всех сайтов? Во вторых, в случае с сертификатами SSL кто угодно может подписать что угодно, достаточно одному сломаться - и в обломе оказываются вообще ВСЕ. В общем SSL и сертификаты в том виде каком оно сейчас проблему не решают. Доказано comodohacker'ом. В третьих, грузить код можно и с посторонних сайтов и еще много откуда через всякие инъекции и прочая. Атакующий может скроить вполне легитимно выглядящий запрос к некоему сайту не вызывающий вопросов у браузера, валидный со всех точек зрения. А что ему помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко. > или не обращать внимания на предупреждения, что часть трафика не шифруется, то... Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный. А вот то что это может быть какой-то иной сайт и серт - кто ж там с лупой будет высматривать то это? Да и при юзеже SSL траффик уже зашифрован. Смысл то шифровать еше раз? > всё равно далеко не однофигственно. Закрытый ключ Вася не увидит и трафик > между юзером и сервером тоже. Ну да, ну да, все стремные моменты отрабатывает SSL (который в этом плане похож на щит из картона и деревянную саблю). А зачем эта дребедень на JS нужна если ее надежность == надежности SSL?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	44. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 18-Сен-12, 15:18
	>Ну, утек пароль. Миссия не выполнена. Пароль, какой пароль? Не, не слышал. У нас секретный ключ. >В третьих, грузить код можно и с посторонних сайтов и еще много откуда через всякие инъекции и прочая. Атакующий может скроить вполне легитимно выглядящий запрос к некоему сайту не вызывающий вопросов у браузера, валидный со всех точек зрения. А что ему помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко. 1. Перед использованием персонального сертификата, проверяется сертификат того, кто его запросил и выводит соответствующий запрос с информацией о регистраторе и регистранте. 2. (Что более важно) Ну пошлет браузер запрос на сайт Пупкина. Пупкин узнает сколько и куда юзер денег хотел перевести. Не приятно конечно, но что дальше? Напоминаю авторизация транзакций у нас не по паролю и не по кукам, а по открытому ключу. >Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный. см. п.1 >Ну да, ну да, все стремные моменты отрабатывает SSL (который в этом плане похож на щит из картона и деревянную саблю). А зачем эта дребедень на JS нужна если ее надежность == надежности SSL? Если это будет в JS, то надежность == надежности gpg. Никто не заставляет использовать инфраструктуру SSL/TLS. Ну и про картонный щит не надо утрировать тоже.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	61. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 18-Сен-12, 19:28
	> Пароль, какой пароль? Не, не слышал. У нас секретный ключ. Ну и славненько, правда вот никто не гарантирует что им пользуется именно правильный скрипт. А чужой скрипт может реализовывать какую угодно нецелевую логику. Если я юзая gpg или почтарь локально еще могу быть более-менее уверен что он не поюзает ключ нецелевым образом и прочая, то скрипт всегда грузится снаружи. И хотя визуально он может быть похож на легитимный нет никаких гарантий что будет сделано именно то что заявлено. Например, он может выступить MITM-ом, гоняя данные кому-то левому. Ключ? Окей, он проавторизует МОИМ ключом какого-то левого ПУПКИНА. Далее Пупкин сможет куролесить от моего лица без каких либо препятствий. А пи...ли прилетят мне. Потому что ключ - мой. А я чем виноват? Не могу же я читать все скрипты которые грузит браузер? Он их тоннами на каждый пук грузит на каждом сайте. Так что этот код априори недоверяем "сам по себе". >> помешает то? Браузеру пофиг - слать запрос на сайт банка или на сайт Пупкин и Ко. > 1. Перед использованием персонального сертификата, проверяется сертификат того, кто его > запросил и выводит соответствующий запрос с информацией о регистраторе и регистранте. Кто выводит? Куда выводит? Посмотреть инфо о сертификате конечно можно, но кто ж это инфо запоминать будет? Ну я б еще понял если б предложили расширение для SSL когда запоминается начальный сертификат и потом если он поменялся - предупреждение. Но ведь как обычно - всем пофигу. > 2. (Что более важно) Ну пошлет браузер запрос на сайт Пупкина. Пупкин > узнает сколько и куда юзер денег хотел перевести. Не приятно конечно, > но что дальше? Напоминаю авторизация транзакций у нас не по паролю > и не по кукам, а по открытому ключу. А еще пупкиновый скрипт сможет проавторизоваться моим ключом и немного поправить параметры транзакции в процессе. Ну а что ему помешает то? Например, не 100 рублей и Васе, а 10 000 и Пете. В случае хоть того же SSL и браузера такому развитию событий мешает хотя-бы то что я не переустанавливаю браузер по свистку хаксора и к тому же браузер должен поставляться в пакете. Пакет должен быть с валидной цифровой подписью майнтайнеров дистра. Это сильно затрудняет подпихивание мне левого кода использующего криптографию в произвольный момент времени по желанию хаксора. Но в вебе скрипты грузят на каждый пук. Это нормально. Это незаметно. Веб просто так работает. Откуда вытекает что вгрузиться может что попало и без особого одобрения. И без проверки кто вообще писал этот код и по какому поводу он грузится. По поводу довольно странно пытаться доверять этому НЕДОВЕРЯЕМОМУ коду шариться в моих ключах, например. А какие гарантии что это не хаксоровский код и что он ключ поюзает с благими намерениями вообще? А не для того чтобы миллион на свой счет перекинуть или хотя-бы спамануть от моего лица? >>Допустим шифруется. А хоть и другим сертом. И? Браузер вякать не будет, если серт валидный. > см. п.1 Смотрю. Но так и не понимаю: мне предлагается самому запоминать параметры сертов? Кроме того, надежность такой схемы ограничена сугубо SSL и вся возня с JS - достаточно декоративная. > надежности SSL? > Если это будет в JS, то надежность == надежности gpg. Агащаз. Я GPG не перекачиваю по сто раз на дню по свистку хаксора. А вот JS очень даже могу. В этом у JS и даже у "JS дергающего GPG" есть лютейший недостаток. Он всегда может сделать не то что задекларированно. Измениться код может в любой момент. Надежной механики как-то это ограничить или проконтролировать понятным для юзера методом - тупо нет. Поэтому если мой ключ юзанет некий Пупкин по каким-то левым нуждам - я это никак особо не отловлю в большинстве случаев. И надеяться на такую "криптографию" как-то неохота. > Никто не заставляет использовать инфраструктуру SSL/TLS. Так если ее не использовать - нет вообще совсем никакой защиты от вгрузки кем попало совершенно левого JS кода под видом легитимного. SSL/TLS пытаются хотя-бы имитировать бурную деятельность. В том виде как оно сделано сейчас - не очень успешно, ибо комодохакер уже показал чему равна надежность всего этого. Но если им не пользоваться - ну вгрузил мне хаксор скрипт. > Ну и про картонный щит не надо утрировать тоже. Грубо говоря: ComodoHacker's JS: мамой клянусь, я все честно зашифровал! Я - скрипт вон того банка! И параметры транзакции - верные! А поди заметь что это не настоящий банк скрипт отгрузил, ага. Если на пакет с gpg майнтайнеры цифровую подпись лепят и я могу проверить что gpg отгружен ими а не кем-то еще, то вот JS может вгружаться кем попало и претендовать на то что он - нечто иное.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	63. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от filosofem (ok) on 18-Сен-12, 21:32
	Все не читал, но в целом претензию понял. Эдакое подобие CSRF, только с полным контролем трафика между клиентом и сервером (либо DNS, используемого юзером) и элементами социнженерии(потому что ну не будет адекватный браузер дёргать ключ из хранилища скриптом, без явной манипуляции юзера, это же очевидно, а юзеры даже больные на голову не включают автологины на банковских сайтах), да не исключено, хотя и затруднительно реально провернуть из-за same origin policy =) Но опять же, как было сказано, даже в таком грустном случае хаксор не прослушивает трафик и не получает ключ. И это уже не киддис Вася, кстати, а агент Малдер какой-то. И никакого >Однофигственно. В данном случае ничто не помешает хаксору вгрузить свой вариант скрипта. нет. Много чего помешает. По поводу невозможности или отсутствию практики проверки скриптов. Это как раз одна из проблем, которую может и должен решить крипто-API.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	20. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
	Сообщение от Аноним (??) on 17-Сен-12, 22:30
	Не нашел, где там доступ к приватным ключам напрямую из браузера, ткните пальцем пжалуйста. Interface Key не содержит атрибутов содержащую секретную последовательность байтов ключа, только общее описание ключа. Атрибут extractable интерфейса Key указывает возможно ли делать export ключа или нет.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

33. "Консорциум W3C представил спецификацию Web Cryptography API"	+/–
Сообщение от Sw00p aka Jerom on 18-Сен-12, 10:40
Холиварщики!!!!!! - читайте основы криптографии открытого ключа, и драфт по крипто API, и не фиг тут разводить холивар про скрипты
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема