170 похожих чатов

Спасибо, ситуация начинает проясняться. Доки по ссылкам прочитал, но вопросы

ещё остались.

В оригинальной статье написано, что в случае попадания в кэш: "it uses a SHA256-based challenge-response mechanism while authenticating a client ... This is faster and allows secure authentication over an unencrypted channel." - звучит как серебряная пуля, быстро и безопасно даже в условиях unencrypted channel.

Однако, если кэша нет, то переходим к более медленному механизму, который предполагает сначала установить безопасное соединение (либо TLS, либо на основе RSA ключей).

Вопрос: в чём смысл этого кэша и почему его отсуствие требует перехода на "полную, но медленную авторизацию"?

Из документации: "On the server side, an in-memory cache enables faster reauthentication of users who have connected previously when they connect again." (https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html) - перевожу на русский: наличие in-memory cache позволяет провести быструю аутентификацию, а его отсутствие не позволяет. Хочу понять, что это за кэш такой?

Вот ещё фраза: "When the cache can be used, the server uses a challenge-response mechanism that does not use cleartext password transmission and does not require a secure connection." - иными словами, при наличия кэша мы можем использовать быстрый challenge-response mechanism, при котором пароль не посылается прсотым текстом (что хорошо) и нам даже не требуется secure connection! Делаю выводы, что отсуствие этого кэша каким-то образом мешает провести быстрый challenge-response mechanism и требует создания secure connection?

Я сначала думал, что in-memory cache - это мы взяли пользователей и хэши их паролей из таблицы mysql.user и положили в память, чтобы не читать каждый раз с диска. Но это, как говорится, не big deal, и это никак не должно было бы повлиять на то, используем ли мы fast challenge-response mechanism или долго и сложно поднимаем secure connection. Видимо, in-memory cache - это не про перекладывание данных из таблицы mysql.user с диска в память, а что тогда?

2 ответов

13 просмотров

Отвечу позже сегодня. Сейчас с телефона длинно отвечать неудобно

ну так вот, отвечаю на вопросы. Кэш есть всегда. Он кэширует пары (имя пользователя, хеш от пароля). Для полной аутентификации клиент должен прислать пароль серверу. Что в зависимости от разных условий, может быть либо дорого в плане round-trips до сервера, либо несекьюрно. Если для пользователя уже есть там запись, значит он уже присылал пароль во время работы сервера. И вместо отправки пароля (что напомню сложная процедура), клиент может отправить серверу посоленный хеш и тем самым подтвердить, что пароль он знает и он такой же, как в in-memory кэше

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта