| 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 [^] [^^] [^^^] [ответить]
| +/– |
 Руководитель, игнорирующий одмина (особенно в вопросах безопасности), гораздо более не на своём месте )
| | |
| |
| |
| |
| 10.29, arisu (ok), 00:05, 14/01/2013 [^] [^^] [^^^] [ответить] | +/– | 8230 то админу придётся продавать почки свою и родственников чтобы расплатит... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 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 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
отлично оптимизировали все на клиента.
разгрузка сервера - клиент сам себя грузит
| | |
|
