РегистрацияАлгоритм аутентификации
Есть challenge-responce. Плюс – пофиг на MitM, минус – если аутентификация по паролю (узкое поле значений), то можно пассивно перехватить аутентификацию и ее брутать. Минус номер 2 – проверяется знание общего секрета, то есть если злоумышленник украдет базу с хэшами паролей, то он сможет аутентифицироваться хэшем без знания пароля, то есть придется менять все пароли, что не очень реально.
Есть SSL. Плюс – на брут пофиг, минус – уязвима к MitM.
Есть ли алгоритм, который сочетает оба преимущества – и безразличность к MitM (без предварительной передачи чего-либо по надежному каналу), и отсутствие недостатков challenge-responce?
Там не всё так просто. Сервер обычно шлёт соль, а клиент должен конкатенировать её со своим паролем и выслать ему хэш. Т.о. каждый хэш шлётся лишь один раз. Чтобы сломать систему, надо восстановить пароль по хэшу, хранящемуся в базе данных, но тут всё упирается в стойкость самих паролей (сильные пароли не ломаются, а от слабых не спасёт ничего).
Почему узявима? Проверяйте отпечаток сертификата в браузере (при принятии его в категорию исключений, например, в firefox), отслеживайте смену сертификата (Certificate Patrol для firefox), и всё будет нормально (в рамках того, насколько вообще можно доверять аутентификацию браузеру; конечно, это не ssh и не gpg).
комментариев: 11558 документов: 1036 редакций: 4118
Каким образом противник, получивший базу хэшей, сможет аутентифицироваться с помощью хэша, к которому в этой же базе нет хэшированного соответствия? Иными словами, в базе хранится S = H(P), который крадёт взломщик. Этот же S он передаёт в процессе аутентификации. Система вычисляет H(S) = H(H(P)), которому пытается найти соответствие в базе, не находит его и отказывает в доступе.
/Библиотека/Словарь/НадежныйКанал
Просто.
Если в базе хранится хэш пароля hash2(pass), то передается hash1(client_nonce, server_nonce, hash2(pass)) и сравниваются результаты. Очевидно, что имея hash2(pass), можно аутентифицироваться на сервере, для этого нужно только поменять клиент так, чтобы можно было использовать хэш вместо пароля. Пример здесь. (Емае! 7 лет уже!). Так что пароль из хэша восстанавливать не обязательно. Единственные недостатки – надо модифицировать клиент и нельзя проверить пароль на других сервисах с другой схемой аутентификации, не расшифровав.
имелся в виду защищенный от подмены
Речь об абстрактных протоколах. Корневые сертификаты в браузере – это и есть защищенный от подмены канал.
комментариев: 11558 документов: 1036 редакций: 4118
Из исходного описания это не следует. Мы обсуждаем конкретную уязвимую реализацию? Хэширование пользовательского ввода должно выполняться на стороне сервера, а не клиентом. Если клиент передаёт H(R, H(P)), где R — некоторые случайные данные, в базе можно хранить H(H(P)), что устраняет возможность атаки при компрометации БД.
Очень интересно, как получить из H(H§) H(R, H§)?
И как передать пароль через challenge-responce? Ты точно ничего не путаешь?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 11558 документов: 1036 редакций: 4118
Что можете сказать о SRP? Насколько я пока что понял, оффлайновый брут по перехваченому трафику проходит, единственное преимущество над challenge-responce – кража БД не дает возможности аутентифицироваться без подбора пароля.
комментариев: 9796 документов: 488 редакций: 5664
ТС выдаёт два немного сомнительных утверждения, по крайней мере без дополнительных пояснений. Он их принимает в качестве правильных критериев для поиска некоего протокола. И что тут сказать?
Телепатия подсказывает, что возможно он имел ввиду что-то другое и хотел чего-то другого. SSL неуязвим и к бруту, и к MITM (при всей примитивности такой постановки вопроса) — если есть надёжный канал сверки отпечатков ключей. Протоколы с паролями нужны только для удобства пользователей, которые не хотят хранить ключи и возиться с ними. Создавать такие протоколы и обосновывать их стойкость несколько сложнее.
По вашей терминологии кстати аутентифицированый :)
А что сомнительного и какие пояснения нужны? Что посказала телепатия?
Парольная аутентификация – это условия задачи.
комментариев: 9796 документов: 488 редакций: 5664
Кстати да, так правильнее :)
С этого и следовало бы начать. Что всё остальное не подходит не потому, что плохо, а потому что требуются именно
Что для этогог нужен именно пароль и никак иначе. Что только телепатией и можно понять. Просто странно сравнили как-то.
Первоначальное установление доверия (наобходимое для последующего ухода от MITM) выходит за рамки формальной криптографической задачи.
Нет. Кое-какие практические уловки есть — "амплификация" доверия через серию "дружеских" вопросов (известные друзьям секреты, так частично сделано в OTR через протокол соцмиллионера). Другая практическая уловка — защита от "машины — но не человека — посредине" путём совместного быстрого разгадывания каптч (что позволяет установить канал, возможно свободный от массового применения MITM, но недоверяемый, т.к. непонятно с кем), приватные пересечения множеств (создание групп по интересам — но это теоретические наработки и далеко от вашего вопроса).
Я ему сразу написал:Это и есть ответ. Видимо, ТС настолько ослеплён чувством собственного превосодства над жалкими людишками с этого форума, что даже не вдумывается в то, что ему отвечают.