LINUX.ORG.RU

2019 год и опять аутентификация...

 


3

2

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

Сейчас наиболее популярно делать так: работаем только по https, при аутентификации передаем в явном виде пароль пользователя и логин (привет, man-in-the-middle!), сервер вычисляет хэш пароля, сравнивает его с хэшем из БД согласно данному логину, и высылает токен аутентификации. Далее пользователь этот токен в куках или local storage сохраняет и при авторизации каждый раз высылает его серверу. Просрочил токен - проходи аутентификацию заново.

Основных недостатка здесь два: во-первых, хоть это и сложно, но возможно на прокси-https сделать man-in-the-middle; во-вторых, требуется SSL (т.е. генерь самоподписной сертификат или покупай «кошерный»).

Может быть, есть какой-нибудь нормальный человеческий способ аутентификации, надежный как для HTTPS, так и для незащищенного соединения?

Скажем, самый простой способ: при аутентификации у сервера запрашивается случайно сгенеренный ключ. Он используется как соль: к хэшу (я надеюсь, жабоскрипт умеет sha512?) пароля добавляется эта соль и вычисляется новый хэш. Данный хэш с логином пользователя отправляются серваку. Тот делает аналогичные вычисления и сравнивает с данными из БД. Т.е фактически аутентификация заключается в запросе ключа. Через какое-то время ключ «прокисает» и надо пройти заново процедуру. Авторизация заключается в регулярной отправке серверу пары логин-хэш. В данном случае можно вообще в local storage браузера хранить хэш пароля пользователя и вообще никогда больше не требовать ввода логина/пароля (покуда пользователь не нажмет logout, в результате чего хэш пароля из local storage будет удален).

Какие косяки могут быть в этом способе?

Ответ на: комментарий от maxcom

хранить plain text пароль пользователя, что само по себе является довольно сомнительной практикой

Вероятно имеется в виду хранение хэшей от паролей? Ок, если соль не статическая для каждой учетки, или есть другие варианты? Шифрованные пароли?

anonymous
()
Ответ на: комментарий от maxcom

Насколько я понимаю в твоем случае сервер должен хранить plain text пароль пользователя

Нет, конечно! Только sha512 пароля. Хранить пароли plain text'ом - вообще жесть!

MITM может не только пассивно слушать, но и подселить свой код который утянет пароль прямо из формы.

Ну это уж совсем крутой хакер должен быть...

OnlyAsk
() автор топика
Ответ на: комментарий от OnlyAsk

P.S. А если и справятся, то https для них тоже - не помеха. Все равно сертификат тоже будет самоподписанный...

OnlyAsk
() автор топика
Ответ на: комментарий от maxcom

Текст из ссылки:

HTTPS interception occurs in situations like the following:
A device has a root certificate installed that allow an intermediary to decrypt and inspect traffic.
An origin server provides its TLS private key to a third party (like a reverse proxy) that does TLS termination.
evgeny_aa ★★☆
()
Последнее исправление: evgeny_aa (всего исправлений: 2)
Ответ на: комментарий от OnlyAsk

Так если мы подменили js, то ничего не мешает пароль введённый plain text отправить на свои сервера (ведь js на клиенте он доступен до всяких преобразований). А дальше уже заходить обычным образом в интерфейс твоей штуки, как будто мы всегда знали пароль.

KivApple ★★★★★
()
Ответ на: комментарий от OnlyAsk

Что возможно в любом криво настроенном публичном WiFi.

KivApple ★★★★★
()
Ответ на: комментарий от OnlyAsk

Что мешает использовать сертификат от letsencrypt?

KivApple ★★★★★
()

Да хватит придумывать способы, веб-приматы! HTTP authentication? Мало. Digest Auth? Мало. Cookies? Мало. Нужно сложнее, сложнее, сложнее, а то тормозить не будет.

t184256 ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Что мешает юзать клиент-сайд сертификаты на вебсокетах?

trex6 ★★★★★
()

В данном случае можно вообще в local storage браузера хранить хэш пароля пользователя и вообще никогда больше не требовать ввода логина/пароля

Ну ты же понимаешь, что это дичь? Ибо любой сторонний скрипт имеет полный доступ к Localstorage

valera-galera
()
Ответ на: комментарий от torvn77

Я хочу добавить устройство в схему двухфакторной авторизации. Яндекс присылает мне QR-код. Я сканирую его Я.Ключом, на что он пишет мне «Неверный формат».

И что мне теперь делать?

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Три варианта:

  1. Толи прошивка в устройстве устарела, толи Яндекс поторопился перейти на новую версию формата. Что делать: написать в саппорт яндекса, купить новое устройство или обновить описание формата в имеющиемся.
  2. Яндекс проигнорировал стандарт и написал отсебятину.
    Что делать: Найти сервис без самодуров.
  3. Вы купили устройство на радиорынке у человека который сам толком не понимает что и зачем продаёт. Что делать: вернуть устройство продавцу или полностью перешить через программатор флеша на нормальную прошивку.

П.С. Видимо имеет смысл в QR коде передавать версию формата и процесс аутентификации проводить человекочитаемыми сценариями чтобы человек мог сам вносить изменения в процесс аунтентификации для приведения его к актуальному виду. (Можно и через программатор, но им имхо лучше не злоупотреблять)

torvn77 ★★★★★
()
Ответ на: комментарий от t184256

Всё что ты перечислил - мусорное тормозное говно. Оно будет тормозить и работать как говно именно тогда, когда используешь этот мусор. Если же хочешь что-то адекватное и быстрое - это говно нужно выкинуть.

xiomar_georgios
()
Ответ на: комментарий от OnlyAsk

Мне нужно тупо проверить, что подключающийся к вебсокету (или отправляющий данные демону через POST-запрос) пользователь — валиден.

Без https это ничего не гарантирует.

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

Выкинь всё говно и шифруй руками. Это не сложно. Есть уже готовые api. Поличача и погнал. maс посчитал, прилепил, зашифровал - отправил.

Ключи у тебя уже безопасно отправляются, если прикрутишь tls. Вебсокет можешь пускать обычный. Далее можешь посылать на сервер ключи(сеансовые). Открытый ключ сервера к тебе пришел уже, надёжно.

От tls для твоего приложения ты всё равно не уйдёшь - хомячки/броузеры не оценят. Поэтому раз имеешь на халяву верификацию - используй.

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Ах да, забыл. Если есть доступ к акселерации aes - юзай его.

В будущем нам дадут нормальное udp, а не это плебейское говно нелепое. Там уже пилят что-то типа вебсокета для udp. Есть также варианты завести это поверх webrtc, но я не пробовал - мне лень с этим разбираться и его тащить.

xiomar_georgios
()
Ответ на: комментарий от t184256

Что ляпнуть? Ты хочешь побенчить своё говно и нормальные решения, которые предлагаю я, либо адекватные пацаны? Ты же уедешь сразу. Зачем начинаешь?

Если ты хочешь - я могу тебе объяснить почему твои предложения говно. Вдруг ты не понимаешь просто.

Я вообще не знаю - откуда вы взяли такую нелепую чушь, что какой-то мусорное хттп и прочая дристня древняя - это быстро? Это круто? Это тормозное бездарное говно. Его дизайнили идиоты - это нотариально заверенная инфа.

А теперь весь веб с ним борется. Ну не понимаешь ты зачем и что. Не сталкиваешься ты с проблемами - изучи тему. Весь интернет засран инфой на тему.

xiomar_georgios
()
Ответ на: комментарий от torvn77

1.Прошивка актуальна, так как не объявлена EOL. 3. Устройство было куплено в крупном магазине, есть гарантийный талон и прочее.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Я с ходу не понял что он про реальное устройство или программу и по этому вопрос, ты про этот яндекс ключь или про моё предложение спрашиваешь?

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от xiomar_georgios

Мне не о чем с тобой разговаривать, раз ты думаешь, что HTTP basic auth или TLS client certificate auth + какой-нибудь 0RTT могут слить по числу раундтрипов поганым формам + кукам.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от t184256

О боже, ещё бы ты мог со мною разговаривать. Ты наслушался где-то каких-то базвордов и решил, что написав их тебе кто-то поверит? Нет.

что HTTP basic auth

Ты уже обделался. Причина - http - транспорт дерьма. Поэтому все твои потуги тут же умножаются на ноль.

TLS client certificate auth

Это говно, да и как-то быстро ты обделался и сменил базворды? А куда же делись прошлые базворды?

какой-нибудь 0RTT

Опять где-то услышал базворд и давай повторять? Какой 0rtt - иди показывай. Ты об этом не балаболил ранее.

могут слить по числу раундтрипов

О боже, эти потуги. Опять где-то услышал какой-то нелепый базворд и пошел повторять херню. Никакого 0rtt - нету. Тебя поимела пропаганда. Реальный 0rtt есть только в описанной мною схеме выше.

К тому же, сам по себе 0rtt ни о чём не говорит. И ничего не значит.

поганым формам + кукам.

А тут адепт совсем переобулся. Откуда адепт взять какие-то формы, куки и прочую дристню? Опять перечисление каких-то базвордов?

Именно ты болтал о том, что формы и куки круто, а все остальные придумывают какую-то новую тормозную херню.

А теперь вдруг ты погуглил, осознал что обделался и забыл методичку. Уже побежал за модными базвордами.

Но я тебе ещё кое что сообщу. Важно не то, что написано у тебя в методичке для домохозяек. Определяющим является то, насколько удобна и масштабируема схема той же аутентификации/транспорта и т.п.

xiomar_georgios
()
Ответ на: комментарий от OnlyAsk

Если бы я еще знал, что такое TLS…

aka ssl

И самое главное - как это в С реализовать!

Лучше возьми готовое - wss(на халяву у lets encrypt). И гоняй данные какие угодно. Если ты не понимаешь как запилить - моя схема тебе не подходит.

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

ТА я уже наслушался местных аналитегов и решил, что просто подниму веб-морду на https и буду wss использовать. Проверил - с самоподписными сертификатами нормально все работает. Разве что пользователю боязно будет впервые. Ничего, инструкцию напишу, что «надо, Федя, надо!»

OnlyAsk
() автор топика

man-in-the-middle

Вот поэтому есть двухфакторая аутентификация. Ну а так вообще, OTP изобрели ещё при товарище Сталине.

no-such-file ★★★★★
()
Ответ на: комментарий от xiomar_georgios

Не признал, ваше величество. Дристните, пожалуйста, с ресурса, спасибо.

t184256 ★★★★★
()
Ответ на: комментарий от OnlyAsk

роверил - с самоподписными сертификатами нормально все работает. Разве что пользователю боязно будет впервые. Ничего, инструкцию напишу, что «надо, Федя, надо!»

Не работает. Основная задача ssl не шифрование, а проверка подлинности сервера. Именно для обхода той самой mitm. Твой самоподписной серфитикат вообще не работает. Тебе остаётся только уповать на то, что при первой передачи у тебя не будет мужика по середине.

Поэтому не страдай хернёй. Тебе уже говорили где взять сертификаты нормальные на халяву. Идёшь и ставишь.

xiomar_georgios
()
Ответ на: комментарий от OnlyAsk

И да, осознай ещё одно. Первая твоя задача - передать бутстрап на клиент. В броузере есть только одна нормально рабочая схема - это https. Он тебе гарантирует, что код пришел именно от тебя и никто в ничего ничего не заинжектил.

Далее ты можешь делать что угодно. У тебя на клиенте уже есть код и данные. Они точно доставлены с твоего сервера и не изменены.

Но судя по всему ты не особо понимаешь что делать. Поэтому делать тебе ничего ненужно. И у тебя остаётся один вариант - wss. Конечно, есть ещё и второй вариант - реализовать всё руками. Но тогда тебе нужно разбираться в теме. Базовые направления я дал тебе выше.

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Чувак, знал бы ты, как реализованы у нас интерфейсы управления разными веселыми железячинами...

Какой там https? Там тупо пароль/логин в открытом виде по http шлется, а CGI вообще аутентификации никакой не содержат.

Вот я решил хоть немножко обезопасить.

OnlyAsk
() автор топика

требуется SSL (т.е. генерь самоподписной сертификат или покупай «кошерный»)

letsencrypt

slowpony ★★★★★
()
Ответ на: комментарий от evgeny_aa

P.S. Ради интереса можно посмотреть, насколько сильно амазон заморочился с аутентификацией. Но и логин и пароль чего-то в открытую отправляют. Вот дураки наивные.

Ну всякое бывает, и базы утекают, потом провинившегося админа можно хоть четвертовать, но ведь уже поздно.

vodz ★★★★★
()
Ответ на: комментарий от xiomar_georgios

Он тебе гарантирует, что код пришел именно от тебя и никто в ничего ничего не заинжектил.

Это только если у вас окружение доверенное.

vodz ★★★★★
()
Ответ на: комментарий от OnlyAsk

Вот я решил хоть немножко обезопасить.

Ну вот. Берёшь lets encrypt бахаешь сертификаты и прикручиваешь к своему http и ws. Всё просто.

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Что такое «окружение»? Что ты под ним понимаешь?

Это термин из безопасности информации. Означает, что все ваши танцы с https-ами смешны, если ваш браузер будет делать неизвестные действия, ну например, копировать всё гуглу.

vodz ★★★★★
()
Ответ на: комментарий от vodz

Это термин из безопасности информации. Означает, что все ваши танцы с https-ами смешны, если ваш браузер будет делать неизвестные действия, ну например, копировать всё гуглу.

Это бесполезный термин имеющий мало смысла. Если у кого-то есть физический доступ(либо его аналог) к машине, то всё бесполезно. Ты ничего с этим не сделаешь.

А рассуждать можно долго. А что если броузер сливает? А что если ОС? А что если драва? А что если железо? Мы заранее предполагаем то, что всё это доверенное.

Единственное, что там имеет смысл латать - это броузерные расширения. Но даже здесь ты обречён. А хомячки орут «подлый гугол мешает нашим расширениям».

xiomar_georgios
()
Ответ на: комментарий от xiomar_georgios

Это бесполезный термин имеющий мало смысла. Если у кого-то есть физический доступ(либо его аналог) к машине, то всё бесполезно. Ты ничего с этим не сделаешь.

Нет там ничего бесполезного. Особенно с точки зрения безопасников. Если им засертифицировали, что ключ уплыть не может, то если он уплыл - они не при чём. Если о собственной безопасности беспокоишься, то самый правильный девайс не только тот который ключ не отдаёт, но и на своём железном экранчике показывает, что именно он сейчас подписывает.

А что если броузер сливает?

А я вам что написал?

А что если ОС? А что если драва?

Картинку сливает? Ну это тоже плохо, но другая угроза.

vodz ★★★★★
()
Ответ на: комментарий от vodz

Нет там ничего бесполезного. Особенно с точки зрения безопасников. Если им засертифицировали, что ключ уплыть не может, то если он уплыл - они не при чём.

Всё что перечислил - бесполезно. Оно просто не работает в общем случае и никому в контексте веб не интересно. А если же говорить о контексте маня-окружений, то всё это так же шито белыми нитками. Удачи там зааудитить броузер.

Если о собственной безопасности беспокоишься, то самый правильный девайс не только тот который ключ не отдаёт, но и на своём железном экранчике показывает, что именно он сейчас подписывает.

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

А я вам что написал?

Я повторил и продолжил.

Картинку сливает? Ну это тоже плохо, но другая угроза.

В смысле картинку? ОС может смотреть и менять всё что угодно. По-сути всё что умеет броузер - умеет и ОС, потому как она может управлять броузером.

В рамках твоих рассуждений - она может сливать всё, что идёт на твой девайс.

xiomar_georgios
()
Ответ на: комментарий от vodz

Кривые костыли от неособо сведомых надежности не прибавляют в любом случае.

evgeny_aa ★★☆
()
Ответ на: комментарий от xiomar_georgios

В рамках твоих рассуждений - она может сливать всё, что идёт на твой девайс.

То что идёт на/из уже шифровано, а для изоляции шифрования уже даже не надо отдельный железный криптомодуль, вон уже не только работает, но уже CVE появляются, почитайте, чтобы от прогресса не отставать.

vodz ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.