Автор сам свои слайды видел? Откуда на последнем слайде у клиента TGS_s, если KDC клиенту только TGS_c передает? Мог бы хоть демо какое-нибудь придумать на докерах, если стандарт открытый
я вас не понял вы сами сказали что керберос для того чтоб логин и пароль ни каким случаем не передается а на видео точнее 14:12 говорит клиент передает свой логин и пароль на KDC в зашифрованном формате как так?
а если там же сказать, что пароль передается в зашифрованном виде, то получается, что один и тот же логин и пароль должны передаваться на КДЦ в одном виде, если хеш и метод шитья не передаются на КДЦ, как будет расшифровываться эта информация для уточнения?
Клиент не передает свой пароль в зашифрованном формате. Хэш пароля используется в качестве ключа криптографической функции, а аргументом этой функции является текущее время. Это несколько другое))
Майкрософт ничего тут не придумал, керберос гораздо старше их продуктов и выдержал проверку временем. Мути здесь никакой нет. Это совершенно логичная схема, которая прекрасно работает, прекрасно масштабируется, и с точки зрения безопасности дает точные гарантии и имеет хорошо известные слабости, которые компенсируются дизайном окружающей среды.
Нужно уточнять, что сам протокол Керберос действительно создан чтобы не светить паролями, но передача например от фронта в бэк веб-сервисов все еще уязвима, тем не менее TLS без проблем это нейтрализует. Не стоит путать аутентификацию (это как раз задача Kerberos на основании реквизитов) и авторизацию (это всякие там политики AD по аналогии с PAM в линукс, всякие там разрешения к чему-либо). Не хватает еще важной темы - credential cache, которой пренебрегают треш-модули Oracle для Java. И не раскрыта тема расширений S4U2Proxy и S4U2Self
