w
Который надо защищать чуть ли не отдельным компьютером с вводом пароля с листочка который сгорит через 30 сек
Size: a a a
2021 June 27
DZ
особенно, если речь идет о персухе
w
Ясно понятно
w
Спасибо за совет
w
Не буду делать сертификаты приложениям
w
Учитывая что это не моя забота
DZ
вот благодаря таким писакам как вы, данные людей рано или поздно попадают в открытый доступ
DZ
когда речь идет о безопасности пользовательских данных (любых) - такие советы - тьма и зло
DZ
а нести тупость в массы - двойное зло
М
ну это тот же вопрос о steteless, если только и сам ключ не хранить в бд
DZ
есть разные варианты, один из - хранить в БД зашифрованный приватный ключ мастер-паролем, который знает только пользователь
w
Ну получается он обратно шируем?
М
Вариант. Получается что шифруем шифр?
DZ
да
М
Вариант!
DZ
Не хочу больше трещать ни о чем. Читайте теорию, после чего буду отвечать на ваши вопросы)
w
Я вас тоже услышал...
DZ
а его самого можно тоже в encrypted поле хранить, т.е. если будет утерян ключ из .env - все секреты инвалидируются. Если свистнут БД без ключа - то не смогут получить encrypted ключи, потому что они за еще одним слоем кожуры. А если свистнут и то и то - приватники за мастер-паролем, но там уже брутфорс может помочь, если прям сильно понадобится
М
Ну тут хорошо бы систему аутентификации хорошую сделать, а то уже треш получиться (скорее всего пользователь для мастер-пароля возьмет что по проще, и не исключено что тот же пароль что и для самого аккаунта (а в таком случае можно и с помощью его hash-пароля шифровать секрет))
DZ
категорически нельзя - ты автоматом ломастеру укажешь длину пароля для перебора и ограничишь словарь