А какие вообще варианты при RCE есть защитить ключ? Как ни крути он в памяти сервера. Если только это не суперизолированный закрытый отдельный сервер/железка, куда на вход приходит строка, а на выходе - шифр.
Да, валидный комментарий. Я скорее имел в виду, что если затрагивается симметричное, то и про ассиметричное можно/могут спросить. Но да, к паролям в бд это имеет примерно никакое отношение.
Абсолютно согласен, довольно тонкие материи. Но ФБ себе такое позволить может (хоть я и осуждаю). Скажу больше - даже когда пишут причину, там иногда такой листинг требований, что проще не регистрироваться вовсе. А потом почему-то клиенты не идут, рынок маленький - нужно больше вкинуть в маркетинг. Радует, что всё же это больше исключения среди хороших сервисов, чем правило.
Не раз на личном опыте видел что именно так и работает. Только не номер месяца, а кол-во последних символов просто увеличивалось на +1. Т.е. с "123" на "1233" и так далее :)
2) Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
3) > OpenID/Oauth могут точно так же стать единой точкой отказа.
it depends, как и обычно. Много "если". Но сойтись тут можно в одном - вынесенная аутентификация снижает риск падения связанных сервисов в случае отказа первой.
4) Хороший поинт, согласен.
5) > Приведите пример
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица.". А еще "мы хотим собрать статистику по паролям и их сложности, но это будет когда накопим данных, а не в моменте". или "засетапайте эти же пароли в 3rd party системе, чтобы они были идентичны, ну вы поняли - и чтобы пользователь смог под капотом ходить в эту систему по кредам".
Всё это конечно про коня в вакууме, однако ...
> Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например
Фильм очень добротный, с классными актёрами, советую к просмотру. Был рад увидеть его в списках «на посмотреть». Пятая точка до сих пор горит от всей этой темы.
Да, юзкейс теперь вполне себе понятен, спасибо за разъяснение. Единственная штука, это вот и правда а сколько такой же стоит рядом, как пользователю в вакууме, мне вот именно хочется увидеть «этот товар самый дешевый с самой низкой ценой среди всех». Понятно, что с технической точки зрения эт напряг, но как-то так. Еще раз спасибо!
Я если честно, не очень понял какой кейс применения для рядового пользователя, какая мотивация воспользоваться вашим сервесом? Какой смысл смотреть сколько стоил тот или иной товар? Чтобы что? Если не сложно, объясните :) Вот хочу я купить… скажем отвёртку. Захожу на али, и вижу что такая вот отвертка стоит самая дешевая 10 долларов допустим, у кого-то 11, а у кого-то и все 20. Как вы мне можете помочь купить эту отвертку дешевле? Подписаться на предмет и ждать понижения цены? Или еще есть какие-то кейсы
Такую политику ввели в Беларуси последние лет пять. И я считаю, это правильное решение, если есть контроль всё делается как задумано. У нас это работает.
Да. Просто, такой же выход, как и в популярных мморпг — шардирование с выбором шарда перед входом… Да, будут запоминаться левые боты в телеграме, но увы, всё таки это в первую очередь мессенжер
Да, вы правы. Имел ввиду 2048RSA vs 128 битный симметричного
Решать-то конечно не должен (за редким исключением, если он и есть овнер сервиса), однако понимать это полезно каждому разработчику.
Поздравляю, вы приняты в профессиональные формошлёпы! Конечно, главные принципы-то плюс минус везде похожие, где есть клиент-серверное взаимодействие.
А какие вообще варианты при RCE есть защитить ключ? Как ни крути он в памяти сервера. Если только это не суперизолированный закрытый отдельный сервер/железка, куда на вход приходит строка, а на выходе - шифр.
Да, валидный комментарий. Я скорее имел в виду, что если затрагивается симметричное, то и про ассиметричное можно/могут спросить. Но да, к паролям в бд это имеет примерно никакое отношение.
Абсолютно согласен, довольно тонкие материи. Но ФБ себе такое позволить может (хоть я и осуждаю). Скажу больше - даже когда пишут причину, там иногда такой листинг требований, что проще не регистрироваться вовсе. А потом почему-то клиенты не идут, рынок маленький - нужно больше вкинуть в маркетинг. Радует, что всё же это больше исключения среди хороших сервисов, чем правило.
Не раз на личном опыте видел что именно так и работает. Только не номер месяца, а кол-во последних символов просто увеличивалось на +1. Т.е. с "123" на "1233" и так далее :)
1) упс. исправил
2) Правильно ли я понял, что отличие только в том, что в PBKDF2 является HMAC, который есть алгоритм, который вызывает хэш-функцию и в него уже "вшита" соль (пароль) + есть возможность указать кол-во итераций?
3) > OpenID/Oauth могут точно так же стать единой точкой отказа.
it depends, как и обычно. Много "если". Но сойтись тут можно в одном - вынесенная аутентификация снижает риск падения связанных сервисов в случае отказа первой.
4) Хороший поинт, согласен.
5) > Приведите пример
"напишите нам такую систему чтобы наш саппорт мог посмотреть пароль пользователя и зайти под его кредами от его лица.". А еще "мы хотим собрать статистику по паролям и их сложности, но это будет когда накопим данных, а не в моменте". или "засетапайте эти же пароли в 3rd party системе, чтобы они были идентичны, ну вы поняли - и чтобы пользователь смог под капотом ходить в эту систему по кредам".
Всё это конечно про коня в вакууме, однако ...
> Прекрасное объяснение на енотах о разнице между id/authen/author в блоге ЛК, например
Статья огонь. Добавил в статью.
Спасибо за дополнения!
Подборка отличная, но ... Kotlin. Лямбда vs ссылка на функцию тут явно лишняя :) Не о тех лямбдах там речь. За материал спасибо
Было интересно почитать, спасибо за статью. Ох, сколько же сил было вкинуто, представляю. Уважение и пожелание удачи с новыми проектами.