Комментарии 17
Реклама детектед. Где в статье подробности того, как эта штука работает?
Особенно «радует» фраза: «Any FakePage can open securelogin://#provider=RealPage&state=TheirState and once the user accepts the request it will be sent for state=TheirState, so attacker’s login request will be successful.».
А что с ней не так?
Если я правильно понял эту фразу, то я могу создать фишинговую страницу, и спокойно перехватывать данные для входа, пользователь ведь будет думать, что защищен от взлома сильнее, чем при вводе логина/пароля. Биндинг IP адресов при этом не сильно поможет: не каждый пользователь станет читать алерт.
Все чудесно, но зачем опять новый формат и новый протокол? Чем не устроил JWT как формат токена? Да и OpenID-Connect был бы желателен...
PS а строка res.header('Access-Control-Allow-Origin', '*');
внутри мидлвари выглядит попросту страшно. Автору стоило бы назвать эту функцию SLProfileHandler, а не SLMiddleware, чтобы не пугать случайных прохожих.
И ни слова про то как это работает. Ну что за маркетинговая отписка то?
НЛО прилетело и опубликовало эту надпись здесь
За упоминание технологии спасибо, но все же статья на хабре без технических подробностей — это рекламный буллшит. Вот у меня сразу парочка вопросов:
1) если по одному паролю генерится всегда один и тот же ключ — где защита от прегенерации таких ключей и радужных таблиц. если каждый раз разный, то смысл генерировать по паролю?
2) какая предусмотрена защита от кражи токенов\ключей с локалхоста малварью? — конкретно к реализации вопрос, но все же
3) предусмотрена ли защита от запросов малвари с локалхоста, раз уж слушается http://127.0.0.1:?
Ответов на все это я в статье не нашел. Более того, в посте на медиуме я тоже этого не нашел. И взглянув на гитхаб беглым взглядом я тоже не нашел ответов, а читать код ну как-то не хочется…
1) если по одному паролю генерится всегда один и тот же ключ — где защита от прегенерации таких ключей и радужных таблиц. если каждый раз разный, то смысл генерировать по паролю?
2) какая предусмотрена защита от кражи токенов\ключей с локалхоста малварью? — конкретно к реализации вопрос, но все же
3) предусмотрена ли защита от запросов малвари с локалхоста, раз уж слушается http://127.0.0.1:?
Ответов на все это я в статье не нашел. Более того, в посте на медиуме я тоже этого не нашел. И взглянув на гитхаб беглым взглядом я тоже не нашел ответов, а читать код ну как-то не хочется…
upd: вот содержание этого документа стоило бы обсуждать на хабре
Windows 10
Edge: does not support custom protocol handlers like securelogin://. At all. They don't provide any roadmap. Use the Web version.
Но ведь из браузера можно вызвать стороннее UWP-приложение именно по зарегистрированному им протоколу. Или я что-то не допонял?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SecureLogin — забудьте о паролях