В чем измеряется длина строк? В байтах? В символах кодировки

utf8?
Sqlite + SQLAlchemy

Вероятно в байтах

Что еще нафиг за "символы кодировки utf-8" ?

Питон строки в utf8? Тогда, вероятно, мне потребуется указать 256 байт чтобы вмещать безопасно 64 символа?

Чо? Питон? Строки? что за бессвязный набор слвов? В какой кодировке сохраняются строки в базе данных зависит от коннектора. По-умолчанию в случае питонячьего sqlite3 в UTF-8 да.

64 кодпоинта, не символа.

Если ты хочешь хранить юникодные строки строго определенной длины, почему бы тебе не указывать просто TEXT в базе данных и не делать валидацию длины на уровне приложения?

Я не знаю сколько это будет занимать памяти, если не критично, то с радостью буду использовать. Однако оптимизировать это было бы хорошо

WUT?

Нахрена?

Потому что это не пароль юзера аккаунта, где достаточно хеш. Это пароли юзера от других аккаунтов

Зачем RSA ?

Это все еще слабо объясняет зачем в этой схеме конкретно RSA. Опиши подробней схему использования хранящихся паролей.

в кодпоинтах

Чтобы при взломе сервера злоумышленник не смог получить доступ к паролям. Сейчас распишу использование: Пользователь регистрируется, генерируются public_key и private_key. Паблик сохраняется в бд в открытом виде и доступен всегда. Приватный ключ шифруется AES на основе пароля пользователя и хранится в бд в зашифрованном виде. Пользователь получает публичный ключ, шифрует на его основе пароль и передает зашифрованный пароль на сервер чтобы сервер его сохранил. Когда пользователь хочет получить какой-то из сохраненных паролей, он запрашивает зашифр_приватный_ключ, вводит свой пароль и расшифровывает его локально , далее получает с сервера зашифрованный пароль который хочет расшифровать и расшифровывает его. Думаю на время сессии программы сохранять расшифрованный приватный ключ и удалять локально после завершения сессии программы Своеобразный менеджер паролей

SQLite3 ничего не знает ни про какие кодпоинты

А кто генерирует пару ключей?

к сожалению сервер. Это одна из уязвимостей, не включая проверку пароля при авторизации

а как все сделать болеее прозрачно

Если у тебя и отправляет и получает пароли один и тот же пользователь, все еще не ясно зачем в этой схеме RSA. Какая-то переусложненная схема.

затем, чтобы не вводить пароль аккаунта для сохранения других паролей (шифрования), а использовать публичный ключ. Это выглядит прямо как у гугла - пароли в их менеджер можно сохранять моментально, а чтобы получить (прочитать пароль от ресурса) нужно ввести пароль аккаунта гугл

То есть любой владеющий публичным ключем может сохранить в твой менеджер все что угодно без каких либо последствий?

Нет, не может. За это обычная авторизация отвечает же. У меня хранится хеш пароля юзера, авторизация по jwt. Только авторизированный пользователь, владеющий доступ к текущему ресурсу (ресурс - таблица в бд имеющая ид, тайтл, овнер_ид, связь с таблице паролей)