Алгоритм аутентификации
Есть challenge-responce. Плюс – пофиг на MitM, минус – если аутентификация по паролю (узкое поле значений), то можно пассивно перехватить аутентификацию и ее брутать. Минус номер 2 – проверяется знание общего секрета, то есть если злоумышленник украдет базу с хэшами паролей, то он сможет аутентифицироваться хэшем без знания пароля, то есть придется менять все пароли, что не очень реально.
Есть SSL. Плюс – на брут пофиг, минус – уязвима к MitM.
Есть ли алгоритм, который сочетает оба преимущества – и безразличность к MitM (без предварительной передачи чего-либо по надежному каналу), и отсутствие недостатков challenge-responce?
Если между общающимися сторонами нет хотя бы аутентифицированного канала (не знаю, что вы понимаете под "надёжным"), то установить защищённое соединение невозможно. Если аутентифицированный канал есть (каждая из сторон уверена, что получает сообщения именно от нужного адресата), то дальше всё стандартно (хинт: асимметричная криптография).
Там не всё так просто. Сервер обычно шлёт соль, а клиент должен конкатенировать её со своим паролем и выслать ему хэш. Т.о. каждый хэш шлётся лишь один раз. Чтобы сломать систему, надо восстановить пароль по хэшу, хранящемуся в базе данных, но тут всё упирается в стойкость самих паролей (сильные пароли не ломаются, а от слабых не спасёт ничего).
Почему узявима? Проверяйте отпечаток сертификата в браузере (при принятии его в категорию исключений, например, в firefox), отслеживайте смену сертификата (Certificate Patrol для firefox), и всё будет нормально (в рамках того, насколько вообще можно доверять аутентификацию браузеру; конечно, это не ssh и не gpg).
Каким образом противник, получивший базу хэшей, сможет аутентифицироваться с помощью хэша, к которому в этой же базе нет хэшированного соответствия? Иными словами, в базе хранится S = H(P), который крадёт взломщик. Этот же S он передаёт в процессе аутентификации. Система вычисляет H(S) = H(H(P)), которому пытается найти соответствие в базе, не находит его и отказывает в доступе.
/Библиотека/Словарь/НадежныйКанал[link1]
Просто.
Если в базе хранится хэш пароля hash2(pass), то передается hash1(client_nonce, server_nonce, hash2(pass)) и сравниваются результаты. Очевидно, что имея hash2(pass), можно аутентифицироваться на сервере, для этого нужно только поменять клиент так, чтобы можно было использовать хэш вместо пароля. Пример здесь.[link2] (Емае! 7 лет уже!). Так что пароль из хэша восстанавливать не обязательно. Единственные недостатки – надо модифицировать клиент и нельзя проверить пароль на других сервисах с другой схемой аутентификации, не расшифровав.
имелся в виду защищенный от подмены
Речь об абстрактных протоколах. Корневые сертификаты в браузере – это и есть защищенный от подмены канал.
Из исходного описания это не следует. Мы обсуждаем конкретную уязвимую реализацию? Хэширование пользовательского ввода должно выполняться на стороне сервера, а не клиентом. Если клиент передаёт H(R, H(P)), где R — некоторые случайные данные, в базе можно хранить H(H(P)), что устраняет возможность атаки при компрометации БД.
Очень интересно, как получить из H(H§) H(R, H§)?
И как передать пароль через challenge-responce? Ты точно ничего не путаешь?
То есть алиса передает H(pass) в плейнтексте, перехватив который, атакующий сможет выдать себя за алису? Оригинально!
Ах, надёжного канала-то у нас нет...
Вернемся к теме...
Что, криптографы перевелись?
Что можете сказать о SRP[link3]? Насколько я пока что понял, оффлайновый брут по перехваченому трафику проходит, единственное преимущество над challenge-responce – кража БД не дает возможности аутентифицироваться без подбора пароля.
unknown, хоть ты что-то скажи.
ТС выдаёт два немного сомнительных утверждения, по крайней мере без дополнительных пояснений. Он их принимает в качестве правильных критериев для поиска некоего протокола. И что тут сказать?
Телепатия подсказывает, что возможно он имел ввиду что-то другое и хотел чего-то другого. SSL неуязвим и к бруту, и к MITM (при всей примитивности такой постановки вопроса) — если есть надёжный канал сверки отпечатков ключей. Протоколы с паролями нужны только для удобства пользователей, которые не хотят хранить ключи и возиться с ними. Создавать такие протоколы и обосновывать их стойкость несколько сложнее.
По вашей терминологии кстати аутентифицированый :)
А что сомнительного и какие пояснения нужны? Что посказала телепатия?
Парольная аутентификация – это условия задачи.
Кстати да, так правильнее :)
С этого и следовало бы начать. Что всё остальное не подходит не потому, что плохо, а потому что требуются именно
Что для этогог нужен именно пароль и никак иначе. Что только телепатией и можно понять. Просто странно сравнили как-то.
Первоначальное установление доверия (наобходимое для последующего ухода от MITM) выходит за рамки формальной криптографической задачи.
Нет. Кое-какие практические уловки есть — "амплификация" доверия через серию "дружеских" вопросов (известные друзьям секреты, так частично сделано в OTR через протокол соцмиллионера). Другая практическая уловка — защита от "машины — но не человека — посредине" путём совместного быстрого разгадывания каптч (что позволяет установить канал, возможно свободный от массового применения MITM, но недоверяемый, т.к. непонятно с кем), приватные пересечения множеств (создание групп по интересам — но это теоретические наработки и далеко от вашего вопроса).
Если интересно, это обсуждалось в /comment35582[link4] и /comment35589[link5].
Я ему сразу написал:Это и есть ответ. Видимо, ТС настолько ослеплён чувством собственного превосодства над жалкими людишками с этого форума, что даже не вдумывается в то, что ему отвечают.
А причем тут защищенное соединение к аутентификации? Challenge-responce он, например, не нужен.
ТСу хотелось бы увидеть конкретный протокол. Если он во что-то не вдумывается, то потому, что вместо конкретного ответа получает линк на простыни теоретических рассуждений. Которые с ходу понять тяжело, а вгрызаться – неизвестно, окупится ли это.
Ну это вполне приемлемый уровень телепатии :)
Конкретный протокол, на хорошем уровне — это простыни теоретических рассуждений в несколько статей в уважаемых рецензируемых журналах, написанных учёным-криптографом, профессионально занимающимся областью и посвятившим свою жизнь криптографии. Все остальные "протоколы" — это "про
токолы", т.е. наколенные поделки в стиле шифрпанков, которые не очень тянут на уровень того, чтобы их здесь обсуждать (к примеру, есть всякие темы, типа обфускации вместо криптографии, которые здесь заведомо никто обсуждать не намерен).Единственный способ установить надёжный канал между сторонами (не важно, будут ли сообщения только подписаны, или зашифрованы, или и зашифрованы и подписаны — для остальных случаев это в принципе невозможно) — использовать асимметричную криптографию, где доверие распространяется некриптографическими средствами (сеть доверия, сверка отпечатков ключей и т.д.). Если вы изобретёте что-то иное, то сразу совершите переворот во всей криптографии. Прежде чем говорить о новых протоколах, вам стоило бы понять как и почему так устроены уже существующие протоколы, которые писали вполне не глупые люди.
Конкретный протокол можно обьяснить и на более простом уровне. Естественно, обычно придется кому-то на слово поверить, что он надежный, что поделаешь :)
Да что тебя заклинило? Речь идет об аутентификации. Для тебя процитирую пост выше
Так вот я и спрашиваю, есть ли готовые протоколы, удовлетворяющие нужным характеристикам.
Есть протокол аутентификации посредством расшаренного общего секрета (на симметричной криптографии). Для масштабирования применяются такие разновидности, как Kerberos. Он позволяет достичь масштабирования (чтобы число симметричных ключей не росло в зависимости от числа пользователей сети экспоненциально, чтобы не хранить пару для "каждый с каждым"), но ценой доверия к инфраструктуре центральных серверов и существования опасности их взлома.
Сформулируйте чуть подробнее, какие невзаимоисключающие характеристики нужны ещё.
Что не нужен? Аутентифицированный канал? А первоначальный пароль в базу как попадает? Через libastral?
Ну может так, TC хочет ссылки на доверяемый протокол, где:
Телепатия подсказывает опять же, что ТС видимо считает, что для установления аутентификации пользователю достаточно проверить сам сервер просто по IP-адресу, безо всяких сертификатов что-ли? И этого достаточно, чтобы начать аутентификацию уже с первого раза? Тогда не получиться п.2 (кроме недоумения в скобках).
Пусть ТС вопрос изложит связно (как принято в критериях проектирования протоколов — может даже сам вопрос отпадёт), что из него клещами-то вытаскивать к взаимному недоумению сторон?
Быдло-кун опять выходит на связь
Кто-то кого-то сильно недопонимает. Нет криптографии в протоколе — даже MITM'ить не надо, сразу сходу: resend-атаки, необнаружимые перехват и подмена сообщений (как со стороны сервера, так и клиента) внутри протокола, атакующий может выдавать себя как за сервер, так и за клиента... и всё тому прочее — полное раздолье для атакующего. Видимо, весь этот длинный список уязвимостей "выводится за рамки угрозы", и при этом ведутся пламенные речи про защиту от какого-то мифического MITM'ера. До MITM вам ещё дорасти надо.