pfg21, прочитал.
Открытый ключ берётся из закрытого.
Закрытый ключ - это набор байт.
Всё, что делает pbkdf2 - это хеширует пароль так, чтобы этот хеш был достаточной длины для ключа.
Вот поглядите на реализацию: https://cs.opensource.google/go/x/crypto/+/refs/ta...
Проблема была в том, чтобы этот набор относительно рандомных байт заюзать в качестве данных, на основании которых заполняется приватный ключ.
Пытаюсь написать приложение, которое шифрует данные открытым ключом, полученным из приватного ключа, которым эти данные позже будут расшифровываться.
Открытый ключ будет жить в конфиге приложения.
Закрытый ключ не хочется вообще нигде хранить кроме памяти пользователя. Поэтому нужно генерить его из пароля.
Я ничего не предлагаю. Просто делюсь опытом.
Но исходя из вышеописанного я бы при авторизации всегда бы запрашивал у oauth-провайдера email и идентифицировал бы юзера уже по нему. Заодно и есть куда письмо послать в случае чего. В т.ч. в случае восстановления доступа к аккаунту.
Эти openid провайдеры (гугл, фейсбук, одноклассники и проч) любят по желанию задней пятки блокировать "приложение", к которому привязана аутентификация.
В результате ваши пользователи в один прекрасный день не смогут залогиниться.
А если зарегать новое "приложение", то эти же пользователи будут там проиходить под новыми айдишниками (ну внутри гугла, а в этом openid, т.е. для вас они будут выглядеть как новые пользователи).
Вот с тех самых пор, как фронт стал писать на этих ваших реактах, что сломало сайты для поисковиков, и фронтовики решили рендерить свой реакт и на сервере тоже.
А ещё с тех пор, когда знаний фронтовиков стало хватать для того, чтобы строить примитивный бекенд с каким-нить crud'ом.
А нормальный сложный бек никуда при этом не уходил.
Но нынче он не занимается отдачей html'ок. Он лишь отвечает фронту по апи.
то есть один обработчик у вас обрабатывает сам компонент, а второй обрабатывает другие компоненты, и "до" и "после" тут вообще не имеют никакого смысла, потому что логика этих обработчиков принадлежит разным объектам
Нет, обработчик "до" может проверять что-то во внешнем мире (например, объекты по ссылкам из нашей структуры данных).
Обрабочики отличаются друг от друга только двумя вещами:
1. Один вызывается до применения изменений на структуру данных, а другой после.
2. Первый может предотвратить изменение, а второй - нет.
А если сделать триггер на вставку before, в нём узнать id, засунуть его в переменную, а в запросе присвоить из этой переменной?
А что, вдруг так можно.
alejandro68, Всё, что вы написали, конечно верно, только не имеет отношения к данному вопросу.
Мой вопрос исключительно про нагрузку на CPU. И зависимость там от нагрузки к сожалению далеко не линейная. Я это демонстрирую замерами, которые привожу в запросе.
Пожалуйста, перед тем, как отвечать, ознакомьтесь с вопросом.
Открытый ключ берётся из закрытого.
Закрытый ключ - это набор байт.
Всё, что делает pbkdf2 - это хеширует пароль так, чтобы этот хеш был достаточной длины для ключа.
Вот поглядите на реализацию: https://cs.opensource.google/go/x/crypto/+/refs/ta...
Проблема была в том, чтобы этот набор относительно рандомных байт заюзать в качестве данных, на основании которых заполняется приватный ключ.