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

Раскрыты данные о взломах инфраструктуры VeriSign в 2010 году, opennews (?), 03-Фев-12, (0) [смотреть все] +1 Вирусы давно уже в мировых масштабах перенапрвляют вендоюзеров на свои собственн, Анониматор (?), 10:53 , 03-Фев-12, (1) +3 // Вы мыслите очень мелко и в обратном направлении Перенаправить виндоюзеров в масш, skJ (?), 11:32 , 03-Фев-12, (2) +13 // Причем всех включает в себя не только пользователей, но и сервера, обменивающи, тоже Аноним (ok), 11:51 , 03-Фев-12, (3) +8 Великое складывается из малого , D.B.Ktyby (?), 12:01 , 03-Фев-12, (5) А знаешь, правительство США нажавшее на верисайн так может сделать на раз-два-тр, Аноним (-), 14:25 , 03-Фев-12, (9) // Точно также как правительство РФ может надавить на удостоверяющий центр в РФ, уд, Аноним (-), 17:46 , 03-Фев-12, (31) В Христиании -- есть Чтоб правительство ещё меньше давило , Andrey Mitrofanov (?), 18:30 , 03-Фев-12, (34) +2 Куда уж меньше-то - P S Очень давно читал о них Было интересно Смутно пред, the joker (ok), 20:05 , 03-Фев-12, (37) Может При этом если честно мне не так уж важно, какое именно правительство или , Аноним (-), 00:58 , 04-Фев-12, (53) Тут, как в известном анекдоте, есть один нюанс При условии, что сайт поддержи, Anonplus (?), 13:51 , 03-Фев-12, (7) // вирусу достаточно добавить свой CA в список системных и не будет , Анон (?), 20:10 , 03-Фев-12, (40) // Иди расскажи это комодохакеру, лихо выписавшему себе сертификат дигинотаром кля, Аноним (-), 02:23 , 04-Фев-12, (68) во-первых, как сказали выше, достаточно добавить 171 поддельный 187 сертифик, arisu (ok), 20:43 , 03-Фев-12, (47) // Самое жесткое - что в случае взлома верисайнов и подобных ничего добавлять как р, Аноним (-), 02:18 , 04-Фев-12, (67) Внезапно 1 Существуют не только вендоюзеры андройды, айосы, другие сервера , anonimous (?), 20:27 , 03-Фев-12, (45) интересно, на чём у них инфраструктура троль и какой очередной бсдссш винлват , ананим (?), 12:00 , 03-Фев-12, (4) –2 // эльф В прошлый раз помнится был виноват неизвестный 0day в винде, видимо позвол, Аноним (-), 14:28 , 03-Фев-12, (10) +4 потому что эта идея 171 сертификации 187 defective by design но до сих пор , arisu (ok), 13:15 , 03-Фев-12, (6) // Я честно говоря вообще не понимаю смысла в шифровании этого траффика Чего таког, Аноним (-), 14:29 , 03-Фев-12, (11) –2 // Ник пароль тоже в открытом виде передавать А никто не покоцает мой репозитор, MaMoHT (?), 15:12 , 03-Фев-12, (13) +5   // хеширование с солью никто не отменял Попробуйте sha512 соль пароль расшифрова, Иван Иванович Иванов (?), 15:24 , 03-Фев-12, (15)   Это понятно, но результат вашего предложения - реализация соственного протокола-, MaMoHT (?), 15:42 , 03-Фев-12, (18) +1   Это вы минус поставили, да Так вот я вас огорчу - вы сейчас какую-то хрень выдум, Иван Иванович Иванов (?), 15:55 , 03-Фев-12, (20) –2   Почему у Вас реализация какой-то хрени на js, которую по какому-то недоразумен, Andrey Mitrofanov (?), 16:19 , 03-Фев-12, (23)   Идея CA уже 500 раз доказала свою несостоятельность Полный контроль США за CA в, Иван Иванович Иванов (?), 16:32 , 03-Фев-12, (24) +1   Есть же не-сша центры Почему про них мало известно Провести акцию нормальные , playnet (ok), 16:54 , 03-Фев-12, (26) +1   Помнится был в Норвегии, который закрылся по известным причинам , Аноним (-), 19:28 , 03-Фев-12, (36)   Получил допустим Вася в не-США центре сертификат того что он - Вася Сертифициро, Аноним (-), 02:33 , 04-Фев-12, (69)   Вы со мной _спорите_ Я то же самое и написал -- получившая своё система CA , Andrey Mitrofanov (?), 17:16 , 03-Фев-12, (27)   hmac не слышали , evgeny_t (ok), 16:13 , 03-Фев-12, (22)   Я в курсе, а народ в теме нет , Иван Иванович Иванов (?), 16:34 , 03-Фев-12, (25)   Извините, и как вы себе это представляете Причём тут расшифровка К тому, что в, Кирилл (??), 17:29 , 03-Фев-12, (30)   Осталось придумать как передать пароль на сервер при регистрации через интернет , Аноним (-), 17:49 , 03-Фев-12, (32) +1   И как защитить хэш от перехвата, разница не велика войти в аккаунт под перехваче, Аноним (-), 18:06 , 03-Фев-12, (33)   Битва набирала Всё смешалось, кони, перехват сессий---, Andrey Mitrofanov (?), 18:53 , 03-Фев-12, (35) +2   Легко Самый примитивный вариант sever - client а ты это правда ты Вот те lon, Аноним (-), 02:11 , 04-Фев-12, (65) +1   Эта схема подразумевает генерацию после успешной проверки сессионного идентифика, Аноним (-), 12:26 , 04-Фев-12, (75)   Эта схема подразумевает что клиент и сервер где-то внутри себя знают пароль и мо, Аноним (-), 15:52 , 04-Фев-12, (78)   Перечитайте начало ветки, здесь обсуждается заявление что использование хэшей дл, Аноним (-), 21:05 , 04-Фев-12, (79)   вообще-то бОльшую при правильной реализации и тебе это изо всех сил пытались по, arisu (ok), 02:02 , 05-Фев-12, (81)   Это вы отказывайтесь понять, что без шифрования всех данных в сеансе связи, кром, Аноним (-), 11:28 , 05-Фев-12, (93)   а тебе тут пытались пояснить, что даже хэши надёжней, чем 171 шифрование 187 , arisu (ok), 12:43 , 05-Фев-12, (96)   Не вижу никакого смысла в шифровании моей активности по браузингу публичного реп, Аноним (-), 16:07 , 06-Фев-12, (107)   А как вы будете обеспечивать синхронность примеси Этот велосипед уже до Вас соз, Кирилл (??), 15:30 , 06-Фев-12, (99)   ну сказали же простейший есть и 171 более другие 187 варианты но я так по, arisu (ok), 15:35 , 06-Фев-12, (101)   Просто вы обмолвились об использовании рандомной примеси Вот и интересно, как в, Кирилл (??), 15:44 , 06-Фев-12, (104)   я O_O с тех пор, как я таки зарегистрировался, я анонимусом уже не пишу и в ди, arisu (ok), 15:56 , 06-Фев-12, (106)   Просто ты иногда похоже на меня мыслишь, наверное поэтому и путают Я бы даже ск, Аноним (-), 16:36 , 06-Фев-12, (109)   взаимно - видимо, надо к каждому посту disclaimer добавлять наподобие 171 я, arisu (ok), 16:53 , 06-Фев-12, (114)   Наверное именно поэтому методы аутентификации такого типа довольно стандартны дл, Аноним (-), 16:08 , 06-Фев-12, (108)   Ну это да, для авторизованых юзеров оно оправдано Но для гуестов которые пришли, Аноним (-), 01:27 , 04-Фев-12, (54)   Главное же, не путать аутентифткацию, про которую речь в связи с сертификатами, , Andrey Mitrofanov (?), 15:41 , 03-Фев-12, (17) // Анонимность браузинга публичного репа Факт моего конекта к нему виден по src ds, Аноним (-), 01:29 , 04-Фев-12, (55) Насчет публичный и всем доступен https github com plansЕсли бы гитхаб был п, тоже Аноним (ok), 16:04 , 03-Фев-12, (21) +2 // только непонятно, как отсюда вытекает 171 8230 потому давайте включим https , arisu (ok), 20:13 , 03-Фев-12, (41) Без HTTPS проснифить твои куки или пароль, если он будет в открытом виде переда, anonymous (??), 02:56 , 05-Фев-12, (82) +2 кэп что-то дофига вас развелось нынче а ты не думал, что я вполне, например, э, arisu (ok), 03:02 , 05-Фев-12, (83) Сделают от вашего имени троянский коммит в каком-нибудь проекте, который вам дов, Аноним (-), 11:35 , 05-Фев-12, (95) +1 бугога давай, я тебе дам пароль от аккаунта, а ты попробуешь сделать коммит, а , arisu (ok), 12:48 , 05-Фев-12, (97) Я бы ещё добавил, что имея возможность перехвата трафика, не представляет труда , Аноним (-), 11:32 , 05-Фев-12, (94) да наивно спрашивать, но всё таки тебе ничего не говорят слова 171 Diffie 8, arisu (ok), 12:56 , 05-Фев-12, (98) –1 Эти криведки никогда не слышали о подобных схемах Они только минусы умеют винти, Аноним (-), 16:44 , 06-Фев-12, (110) это костыль, в общем-то, а не полноценное решение потому я и сказал, что 171 , arisu (ok), 17:07 , 06-Фев-12, (117) Для точка-точка и передачей ключей курьером в запечатанном конверте вполне подхо, Кирилл (??), 17:20 , 06-Фев-12, (118) Механизм, конечно же есть, но он не массовый и с довольно муторной инфраструктур, Кирилл (??), 17:22 , 06-Фев-12, (119) Как же тогда публичные кодосвалки типа гиториуса работают до сих пор , Аноним (-), 01:29 , 04-Фев-12, (56) на самом деле гитхаб сделан для хомячков, так что я погорячился полагаю, авторы, arisu (ok), 20:10 , 03-Фев-12, (39) // Ну хоть какая-то польза научатся хорошей системой контроля версий пользоваться , Аноним (-), 01:30 , 04-Фев-12, (57) так приходят-то не потому, что https, а именно потому, что git а вот среди вари, arisu (ok), 01:33 , 04-Фев-12, (59) Ни разу не видел такого Скорее за удобные средства взаимодействия Хотя может о, Аноним (-), 01:58 , 04-Фев-12, (63) +1 ни одного, кстати, не нашёл какие-то непонятной ценности ошмётки неизвестно чег, arisu (ok), 02:08 , 04-Фев-12, (64) Да просто у некоторых и такого нет Вика у гитхаба кстати действительно угребищн, Аноним (-), 02:15 , 04-Фев-12, (66) пользуются и даже тем, что у гитхаба называется 171 багтрекер 187 тоже поль, arisu (ok), 02:34 , 04-Фев-12, (70) Можно я пользуясь случаем толкну long hateful rant Или несколко полезных сов, Аноним (-), 03:18 , 04-Фев-12, (72) Альтернатива , Аноним (-), 14:41 , 03-Фев-12, (12) +1 // чему , arisu (ok), 20:13 , 03-Фев-12, (42) Если считаешь её дефективной, значит есть с чем сравнивать , pavlinux (ok), 15:23 , 03-Фев-12, (14) +1 // значит, в ней есть известные дефекты fixed , Andrey Mitrofanov (?), 15:36 , 03-Фев-12, (16) +3 помимо того, что дефекты можно видеть и без сравнений, скажу ещё, что да, есть , arisu (ok), 20:14 , 03-Фев-12, (43) // Ариша - ответь на два вопроса 1 - пользуешь ли Вы он-лайн банкинг ,2 - и если д, Anonymouse (?), 20:51 , 03-Фев-12, (49) нет на всякий случай это не значит, что я не в курсе, что оно такое и как орга, arisu (ok), 21:44 , 03-Фев-12, (50) Скажи честно, что помешает митму при столь декоративной секурности этого протоко, Аноним (-), 01:32 , 04-Фев-12, (58) Категорические утверждения абсолютно неверны ц Как и в любом споре щита и меча, Michael Shigorin (ok), 00:07 , 05-Фев-12, (80) В случае криптографии факт взлома величина довольно-таки бинарная ваши данные и, Аноним (-), 16:47 , 06-Фев-12, (112) ну, не совсем так в принципе, иногда играет роль время, необходимое на дешифров, arisu (ok), 16:56 , 06-Фев-12, (115) Бывает и второй, и третьей, и сто пятидесятой свежести Это вопрос управления ри, Кирилл (??), 15:39 , 06-Фев-12, (103) В случае текущего механизма https оно вообще один сплошной большой риск , Аноним (-), 16:45 , 06-Фев-12, (111) Скажем, риск будет нарастать Но в инфраструктуру вложено слишком много средств , Кирилл (??), 17:25 , 06-Фев-12, (120) Поясните пожалуйста развернуто Ну и какие аналоги тогда должны использоваться , playnet (ok), 15:51 , 03-Фев-12, (19) // мнэ 8230 до сих пор кому-то надо пояснять, почему централизованые системы пус, arisu (ok), 20:17 , 03-Фев-12, (44) +1 Поясняю любой козел может кому угодно удостоверить что угодно в меру своей дуро, Аноним (-), 01:47 , 04-Фев-12, (61) Ну что, делаем ставки что еще подпишет себе ComodoHacker или кто-нибудь еще И бу, Аноним (-), 14:23 , 03-Фев-12, (8) Этого давно стоило ожидать Схема с УЦ довольно ущербная , Кирилл (??), 17:21 , 03-Фев-12, (28) // За сколько _лет_ до сообщений о Комодо начали этого ждать Вы Ваши посты на опен, Andrey Mitrofanov (?), 17:26 , 03-Фев-12, (29) // Изначально Со знакомства с SSL TLS-ом Другое дело, что я не склонен эту пробле, Кирилл (??), 15:33 , 06-Фев-12, (100) –1 А зачем конторе гарант доверия Она что, себе не доверяет , Аноним (-), 04:21 , 05-Фев-12, (86) // гарант нужен по логике ссл третьей стороне которая смотрит на сертификат, выд, arisu (ok), 04:27 , 05-Фев-12, (87) // Логика немножко странная, но приму во внимание И все-таки было бы неплохо ссыло, Аноним (-), 04:33 , 05-Фев-12, (88) // google i https, google i sslоно, кагбэ, всё на этом основано зайди у себя в , arisu (ok), 04:39 , 05-Фев-12, (89) Спасибо, поизучаю на досуге - , Аноним (-), 04:45 , 05-Фев-12, (90) Ну хорошо - тебе эта схема не нравится Я правильно понял Тогда предлагай что по, anonimouse (?), 05:13 , 05-Фев-12, (91) Не кольцо, а сеть В действительности эффективной массовой альтернативы нет , Кирилл (??), 15:35 , 06-Фев-12, (102) потому что её не сделали в принципе, даже 171 перекрёстные подписи 187 уже , arisu (ok), 15:45 , 06-Фев-12, (105) Можно для начала хотя-бы сохранять серт при первом визите сайта и смотреть не по, Аноним (-), 16:50 , 06-Фев-12, (113) оно, конечно, хорошо только слабо работоспособно проверено не только личным оп, arisu (ok), 17:00 , 06-Фев-12, (116) 1,4,6,8,28,86

Сообщения

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

	13. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+5 +/–
	Сообщение от MaMoHT (?), 03-Фев-12, 15:12
	Ник + пароль тоже в открытом виде передавать ? А никто не покоцает мой репозиторий? Наверное это по большой части все таки для целостности данных.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Иван Иванович Иванов (?), 03-Фев-12, 15:24
	хеширование с солью никто не отменял. Попробуйте sha512(соль + пароль) расшифровать - нобелевку получите
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+1 +/–
	Сообщение от MaMoHT (?), 03-Фев-12, 15:42
	Это понятно, но результат вашего предложения - реализация соственного протокола-велосипеда, гарантирующего целостность. Который надо отладить, и еще помимо прочего надо внедрить везде и всюду, дабы просто накручивать полезный функционал. И это вместо того, чтобы воспользоваться уже готовыми проверенными решениями, которые работают везде. Оно стоит того?
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	–2 +/–
	Сообщение от Иван Иванович Иванов (?), 03-Фев-12, 15:55
	Это вы минус поставили, да? Так вот я вас огорчу - вы сейчас какую-то хрень выдумали - на куче сайтов подобная схема реализована (на JavaScript, естественно) и работает как часы. Если не согласны или, хуже того не знаете, не надо ставить минусы. За умного сойдёте.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Andrey Mitrofanov (?), 03-Фев-12, 16:19
	>какую-то хрень выдумали - > на куче сайтов подобная схема реализована (на JavaScript, естественно) и работает > как часы. Почему у Вас реализация "какой-то хрени" на js, которую по какому-то недоразумению ещё не взломали/отэксплойтили, вызывет _больше _доверия, чем получившая своё система CA ? > Если не согласны или, хуже того не знаете, не надо ставить минусы. > За умного сойдёте. да ну, какой вэтом профит.....
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+1 +/–
	Сообщение от Иван Иванович Иванов (?), 03-Фев-12, 16:32
	Идея CA уже 500 раз доказала свою несостоятельность. Полный контроль США за CA в 501 раз доказывает её 1000% несостоятельность. При таком количестве CA, которые есть в современном браузере, говорить о доверии CA based SSL вообще невозможно. Собрались, понимаешь, спецы по безопасности. Ставьте минусы дальше.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+1 +/–
	Сообщение от playnet (ok), 03-Фев-12, 16:54
	> Идея CA уже 500 раз доказала свою несостоятельность. Полный контроль США за > CA в 501 раз доказывает её 1000% несостоятельность. При таком количестве > CA, которые есть в современном браузере, говорить о доверии CA based > SSL вообще невозможно. Есть же не-сша центры? Почему про них мало известно? Провести акцию "нормальные центры в массы".. Другое дело, центров как-то совсем уж много развелось. > Собрались, понимаешь, спецы по безопасности. Ставьте минусы дальше. Чего так переживаешь, это не хабр :) Набери хоть -100500, это ничего не изменит, сообщения не скроет, бан не получишь... Кто-то не согласен и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 03-Фев-12, 19:28
	>> Идея CA уже 500 раз доказала свою несостоятельность. Полный контроль США за >> CA в 501 раз доказывает её 1000% несостоятельность. При таком количестве >> CA, которые есть в современном браузере, говорить о доверии CA based >> SSL вообще невозможно. > Есть же не-сша центры? Почему про них мало известно? Провести акцию "нормальные > центры в массы".. Другое дело, центров как-то совсем уж много развелось. Помнится был в Норвегии, который закрылся по известным причинам...
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 04-Фев-12, 02:33
	> Есть же не-сша центры? Получил допустим Вася в не-США центре сертификат того что он - Вася. Сертифицированный. Правительство США (хакер, конкурент...) решили что хорошо бы прикинуться сайтом Васи, но так чтобы пользователи ничего не заподозрили. Берется CA в США или где там еще. И его силами подписывается серт на то что правительство сша - Вася. Мамой клянусь, и вон той ауторитей. Браузер при заходе на лже-Васин сайт видит: ага, сертификат. Подписан СШАшной ауторитей. Ауторитя доверяемая. Это - Вася. Вася хороший парень, это его сайт, все дела. Поскольку CA чуть более чем дохрена, вероятность взлома или нажима хотя-бы одного из всей оравы (что подставляет всю схему вообще) - понятно какая. Итого: совершенно левая сущность теперь выглядит сайтом Васи. Никаких варнингов по этому поводу браузер выдавать не будет. Опаньки!
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	27. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Andrey Mitrofanov (?), 03-Фев-12, 17:16
	> Идея CA уже 500 раз доказала свою несостоятельность Вы со мной _спорите_??? Я то же самое и написал -- "получившая своё система CA". Дискуссия не склалась.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	22. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от evgeny_t (ok), 03-Фев-12, 16:13
	hmac не слышали ?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	25. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Иван Иванович Иванов (?), 03-Фев-12, 16:34
	> hmac не слышали ? Я в курсе, а народ в теме нет.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Кирилл (??), 03-Фев-12, 17:29
	Извините, и как вы себе это представляете? Причём тут расшифровка? К тому, что вы собрались зашифровывать? Честно, совершенно не понятно.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	32. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+1 +/–
	Сообщение от Аноним (-), 03-Фев-12, 17:49
	> Попробуйте sha512(соль + пароль) расшифровать - нобелевку получите Осталось придумать как передать пароль на сервер при регистрации через интернет :)
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	33. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 03-Фев-12, 18:06
	>> Попробуйте sha512(соль + пароль) расшифровать - нобелевку получите > Осталось придумать как передать пароль на сервер при регистрации через интернет :) И как защитить хэш от перехвата, разница не велика войти в аккаунт под перехваченным паролем, сессионной cookie или хэшем от пароля.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+2 +/–
	Сообщение от Andrey Mitrofanov (?), 03-Фев-12, 18:53
	>сессионной cookie или хэшем от пароля. Битва набирала. Всё смешалось, кони, перехват сессий---
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+1 +/–
	Сообщение от Аноним (-), 04-Фев-12, 02:11
	> И как защитить хэш от перехвата, Легко. Самый примитивный вариант: sever -> client: а ты это правда ты? Вот те long_random_number, битов так 512. server: local_result = sha512 (password + long_random_number) client: response = sha512 (password + long_random_number) client -> server: это я! вот пруф: response. server: if (local_result != response) pls_fxxxoff("да ты самозванец?!"); Заметьте, в этой схеме нигде не передается ни пароль ни даже его хеш. Передается хэш от конкатенации пароля с рандомом. Рандом каждый раз разный чтобы предотвратить replay (вероятность выиграть в лотерею "1 из 2^512" вам не понравится). Это, если что, простейший вариант challenge-response авторизации, довольно баянное изобретение человечества.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	75. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 04-Фев-12, 12:26
	> Заметьте, в этой схеме нигде не передается ни пароль ни даже его Эта схема подразумевает генерацию после успешной проверки сессионного идентификатора, по которому пользователь сможет работать на сайте. Если не используем SSL, то никто не мешает перехватить данный идентификатор и притвориться этим пользователям не проходя вообще фазы аутентификации.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 04-Фев-12, 15:52
	> Эта схема подразумевает генерацию после успешной проверки сессионного идентификатора, Эта схема подразумевает что клиент и сервер где-то внутри себя знают пароль и могут сделать одинаковые вычисления и сравнить что вышло, не более того. Про HTTP или какие-то сессии я вообше тут не издал ни звука, то что у вас HTTP-оз головного мозга и поэтому вы в принципе не способны представить ничего кроме http и типичной организации сессии в нем - это уже на вашей совести. > по которому пользователь сможет работать на сайте. Если не используем SSL, На самом деле, в случае HTTP ключевой дыркой будет то что алгоритм не реализован в браузере или еще какой-то монументальной сущности которая не заменяется атакующим вотпрямщасеймомент. Т.е. алгоритм придется догружать откуда-то сбоку, например на JS, а это FAIL. Если пассивный сниффер будет полностью обломан таким протоколом, то вот активный может просто вгрузить юзеру _другой_ код, например не считающий sha512() а просто отсылающий пароль на немного другой сервер плэйнтекстом, как его юзер ввел. При том юзеру не очень видно что JS сделал ;) > то никто не мешает перехватить данный идентификатор и притвориться этим пользователям > не проходя вообще фазы аутентификации. Вообще, такой протокол очень даже может мешать таким потугам. Подумайте о том что в принципе так можно авторизовывать вообще все запросы юзера. Новый запрос - новый рандом от сервера - новый ответ - шлем нафиг, если вычисления не совпали. То что в рамках стандартного http и привычных вам механизмов это не совсем удобно - второй вопрос. Тем не менее, похожие по смыслу алгоритмы реально применяются для аутентификации по паролю без отсылки этого пароля и даже его хеша. Обеспечивается защита от "replay", т.е. если сервер кинул рандом, юзер ответил а некто подсмотрел это, в следующий раз авторизоваться на сервере подсмотревший не сможет, потому что сервер кинет другой рандом. А посчитать ответ не зная пароля - опаньки, потому что sha512(password+random1) ничего не говорит о том каким должен быть sha512(password+random2).
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 04-Фев-12, 21:05
	> того. Про HTTP или какие-то сессии я вообше тут не издал > ни звука, Перечитайте начало ветки, здесь обсуждается заявление что использование хэшей для проверки  паролей на github обеспечивает аналогичную безопасность, как при использовании SSL. > то что у вас HTTP-оз головного мозга и поэтому > вы в принципе не способны представить ничего кроме http и типичной > организации сессии в нем - это уже на вашей совести. Вы хам, не вижу смысла пояснять что-то  человеку не способному увидеть дальше своего носа и считающему, что другие тоже этого не могут видеть. Не нужно мерить знание других только по своему ограниченному кругозору.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от arisu (ok), 05-Фев-12, 02:02
	> Перечитайте начало ветки, здесь обсуждается заявление что использование хэшей для проверки >  паролей на github обеспечивает аналогичную безопасность, как при использовании SSL. вообще-то бОльшую при правильной реализации. и тебе это изо всех сил пытались пояснить, портянки текста писали. но ты встал в позу «миня абидели» (хотя на самом деле эта поза называется «яничивонипонял!») и делаешь вид, что д'Артаньян. ну, на здоровье, чем бы дитё ни тешилось.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 05-Фев-12, 11:28
	> вообще-то бОльшую при правильной реализации. и тебе это изо всех сил пытались Это вы отказывайтесь понять, что без шифрования всех данных в сеансе связи, кроме необходимости защиты паролей от перехвата возникает кучу сопутствующих факторов, которые могут свести всю вашу защиту по хэшам на нет. Примеры перехвата идентификаторов сессии с последующим входом в аккаунт через них я приводил.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от arisu (ok), 05-Фев-12, 12:43
	а тебе тут пытались пояснить, что даже хэши надёжней, чем «шифрование», которое скомпрометировано изначально. в том числе и потому, что не дают иллюзию защиты.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 06-Фев-12, 16:07
	> Это вы отказывайтесь понять, что без шифрования всех данных в сеансе связи, Не вижу никакого смысла в шифровании моей активности по браузингу публичного репа под гуестом. Кто угодно может браузить этот реп до усера, он публичный. Кто угодно на любом узле через который идет мой трафф может видеть куда я конекчусь и даже прикинуть что я делал за счет тайминг атак. Прятать надо то что следует прятать, а в данном случае от SSL только нехилый тормоза на установку SSL-соединения (+ еще несколько roundtrip times на установку SSL сессии, там же идет согласование используемого шифроавния, ключа, etc). > кроме необходимости защиты паролей от перехвата возникает кучу сопутствующих факторов, > которые могут свести всю вашу защиту по хэшам на нет. Примеры перехвата идентификаторов > сессии с последующим входом в аккаунт через них я приводил. Лечится и так: просто новая challenge-response авторизация на любое потенциально привилегированное действие неодоступное анонимусу и все, готово. Вроде бы все видно, но чувствительные операции требуют доказать что не верблюд, посчитав верный ответ на новый рандом. И хрен сломаешь вот так сходу при нормальной реализации.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Кирилл (??), 06-Фев-12, 15:30
	А как вы будете обеспечивать синхронность примеси? Этот велосипед уже до Вас создан и он совершенно не подходит для массовых коммуникаций на существующей инфраструктуре.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	101. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от arisu (ok), 06-Фев-12, 15:35
	ну сказали же: простейший; есть и «более другие» варианты. но я так понимаю, что поинтересоваться материалами про «безопасный обмен данными по недовереным каналам» — не барское дело.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Кирилл (??), 06-Фев-12, 15:44
	Просто вы обмолвились об использовании рандомной примеси. Вот и интересно, как вы будете извлекать из полученного сообщения полезную часть, если на концах эта самая "рандомность" никак не согласована. И речь идёт не о безопасном обмене, а о гарантированной идентификации. Для начала. Вам, как клиенту, нужно идентифицировать сервер, а серверу - клиента. Как это сделать? Без третьей стороны и без сложной инфраструктуры.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от arisu (ok), 06-Фев-12, 15:56
	> Просто вы обмолвились об использовании рандомной примеси. я? O_O с тех пор, как я таки зарегистрировался, я анонимусом уже не пишу. и в дискуссии про соль я так, мимокрокодил. в том числе и потому, что я таки немного в криптографии нахватался, но совершенно не готов разворачивать полномасштабный бой: это не моя область, слишком много надо будет времени затратить на обновление и добавление знаний, чтобы аргументировано оппонировать. и, кстати, вопрос был совсем другой: про «синхронность примеси», а не про уверенную идентификацию другой стороны. да, оно связано, но не одно и то же (если я верно понял вопрос). в принципе, если нет *ни одного* канала, который можно считать довереным, то проблема вряд ли разрешима, и в таком случае SSL со всеми своими сертификатами никак не поможет: с чего бы сертификаты считать более довереными, чем всё остальное? особенно учитывая факапы root authorities. в любом случае нужно сначала хоть по какому-то довереному каналу обменяться чем-то. а дальше уже тот же socialist millionaire protocol поможет, например.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 06-Фев-12, 16:36
	> я? O_O с тех пор, как я таки зарегистрировался, я анонимусом уже не пишу. Просто ты иногда похоже на меня мыслишь, наверное поэтому и путают. Я бы даже сказал, довольно часто. Ты зачастую умудряешься эпично и сурово откапитанить, избавив меня от такой необходимости. За это я тебе временами весьма благодарен, человек. И даже капитаню вместо тебя, когда тебе лениво :) > и в дискуссии про соль я так, мимокрокодил. в том числе и потому, что я таки > немного в криптографии нахватался, но совершенно не готов разворачивать > полномасштабный бой: это не моя область, слишком много надо будет времени затратить > на обновление и добавление знаний, чтобы аргументировано оппонировать. Собственно я тоже не криптограф-гуру, просто мне до некоторой степени интересна эта область + приходилось пару раз делать самопалы, а халявить я не привык и поэтому до того как за что-то хвататься, маны и факи я все-таки курю и думаю головой, а не иными частями тела. Поэтому очевидные профанации и дезу я не допущу. Предложенная схема - предельно упрощена для очевидности Капитаном, в реальных протоколах обычно все несколько сложнее. > и, кстати, вопрос был совсем другой: про «синхронность примеси», а не про > уверенную идентификацию другой стороны. да, оно связано, но не одно и > то же (если я верно понял вопрос). Я вообще не вижу проблем организовать синхронизированную примесь. А рандом - так тот вообще сервантом клиенту посылается. Если злодей его заменит, ответ не сойдется и сервер пошлет клиента нафиг. > в принципе, если нет *ни одного* канала, который можно считать довереным, то > проблема вряд ли разрешима, и в таком случае SSL со всеми > своими сертификатами никак не поможет: с чего бы сертификаты считать более > довереными, чем всё остальное? Ну вообще, если есть доверяемые инсталляции софта там и тут, можно сгенерить свои CA а остальные - выпнуть. Далее - динамический обмен ключами. Хотя и тут есть риск что одна из сторон хапнет поддельный CA-серт, но это детектабельно по левому фингерпринту. Хоть и потенциально не 100% безопасно. > особенно учитывая факапы root authorities. Вообще, идиотская затея - столько дятлов в рут ауторитях по дефолту и каждый может кому угодно что угодно подписать. ИМХО можно было как минимум запоминать параметры серта при первом визите сайта и если он изменился без внятной причинф, особенно изменилась ауторитя или фигнерпринт - однозначно ALARM. Почему столь простую и действенную затычку не сделали сразу - ?? (вроде бы очевидное решение). > в любом случае нужно сначала хоть по какому-то довереному каналу обменяться чем-то. а > дальше уже тот же socialist millionaire protocol поможет, например. А дальще поможет уже хоть простое шифрование с pre-shared key'ем. Отсюда кстати вытекает еще одна возможность по проверке пароля без его отсылки, только вместо хешей будет шифрование. Шифруем рандомный сеансовый кей паролем, шлем его. Пытаемся юзать оный для поднятия шифрованной сессии. Если не выходит - лох не знал пароля и не смог верно расшифровть сессионный кей, пусть идет нафиг :)
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от arisu (ok), 06-Фев-12, 16:53
	> Просто ты иногда похоже на меня мыслишь, наверное поэтому и путают. Я > бы даже сказал, довольно часто. Ты зачастую умудряешься эпично и сурово > откапитанить, избавив меня от такой необходимости. За это я тебе временами > весьма благодарен, человек. И даже капитаню вместо тебя, когда тебе лениво > :) взаимно. %-) > Предложенная схема > — предельно упрощена для очевидности Капитаном, в реальных протоколах обычно все > несколько сложнее. видимо, надо к каждому посту disclaimer добавлять. наподобие «я в курсе, что на самом деле Земля не шар». > Ну вообще, если есть доверяемые инсталляции софта так я о том же: должно быть хоть что-то, чему доверять таки можно — для начального обмена «секретом». а дальше уже и по обычным каналам не западло. > минимум запоминать параметры серта при первом визите сайта и если он > изменился без внятной причинф, особенно изменилась ауторитя или фигнерпринт — однозначно > ALARM. Почему столь простую и действенную затычку не сделали сразу — > ?? (вроде бы очевидное решение). а разве оно не так? впрочем, у меня все root authorities выпилены нафиг, поэтому меня про любой сертификат спрашивают. а вот claws mail, например, при смене гуглевого сертификата вполне себе заорал: «шеф, всё поменялось, всё поменялось, шеф, я в панике, чо делать будем?!» >> дальше уже тот же socialist millionaire protocol поможет, например. > А дальще поможет уже хоть простое шифрование с pre-shared key'ем. это чутка разное. «миллионер» позволяет убедиться, что на том конце таки вася лоханкин, а не лох васянкин, при этом не отсылая никуда «секрет» ни в каком виде. zero-knowledge proof. > вытекает еще одна возможность по проверке пароля без его отсылки да нафиг эта «проверка пароля» никому не упёрлась, тащемта. это нам может продемонстрировать, например, otr — который как раз и гарантирует, что *во время сеанса* левые не пройдут. плюс профаченье ключей не означает, что автоматически профачились все предыдущие сессии. не то, чтобы я рекомендовал именно otr применять, просто как пример реализации.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 06-Фев-12, 16:08
	> создан и он совершенно не подходит для массовых коммуникаций на существующей > инфраструктуре. Наверное именно поэтому методы аутентификации такого типа довольно стандартны для почтарей, например :)
	Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

	54. "Раскрыты данные о взломах инфраструктуры VeriSign в 2010..."	+/–
	Сообщение от Аноним (-), 04-Фев-12, 01:27
	> Ник + пароль тоже в открытом виде передавать ? А никто не > покоцает мой репозиторий? Ну это да, для авторизованых юзеров оно оправдано. Но для гуестов которые пришли на проект посмотреть это вообще ничего кроме тормозов не дает. Ну побраузил я гит репо. И на кой для этого SSL мне втюхивать? > Наверное это по большой части все таки для целостности данных. В SSL она довольно декоративная. Сколько там из 1500 торговцев доверием сломали и сколько и каких фэйковых сертификатов гуляет - да кто же его знает?!
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

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

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