Я думаю, эта тема достойна отдельного треда в криптаче.
Добро пожаловать в авторизации тред.
Здесь мы рассмотрим, казалось бы, простую задачу - реализацию регистрации-авторизации клиента на сервере.
Но рассмотрим мы её, с точки зрения перехвата снифферами данных,
передающихся по открытому каналу, а также с точки зрения возможности реализации MITM-атак.
Дано:
1. Сервер с базой данных, и таблицей Users внутри.
Данные юзеров - попадают в строчки этой таблицы, при их регистрации.
Структура таблицы - вариативна, и предлагается здесь.
2. Клиент - юзер, который регистрируется, и который заходит в аккаунт.
3. Алгоритмы работы системы.
3.1. Регистрация.
3.2. Вход с данными.
3.3. Вход по кукам.
3.4. Восстановление доступа.
4. Взломщики:
4.1. Сниффер, перехватывающий данные в открытом канале, в том числе и куки, но не могущий подменять данные.
4.2. Митмщик, который стоит между сервером и клиентом. У него могут быть снифферы, и он может ещё и подменять данные.
4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.
Задача: Реализовать алгоритмы, чтобы взломщики соснулей.
Моё видение решения:
1. Чтобы соснул кулхацкер, надо хранить хэши паролей в базе, а не пароли, а данные хранимые в базе - шифровать.
Как шифровать, хз правда, но это интересно.
2. Чтобы соснул сниффер, надо юзать временные куки, которые меняются с каждым перелогином юзера,
а также менять их в случае попытки доступа с другого IP/UserAgent.
3. Чтобы соснул митмщик, надо реализовать криптосистему с открытым ключем, и сделать публичный ключ сервера прешаренным, вшить его в исходник скриптов на клиенте, а хэш исходников - опубликовать.
Но митмщик, может подделать и хэш, и выкачиваемый исходник - короче пиздос, хз что делать тут.
К HTTPS, доверия нет, потому что оно митмается, пик2.
Поэтому будем рассматривать, что-нибудь поверх HTTP, то есть работать будем в открытом канале.
Митмается также ssh (пик1), Diffie-Hellman Key Exchange (пик3), и RSA (пик4).
Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
>4. Взломщики:
>4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.
>Задача: Реализовать алгоритмы, чтобы взломщики соснулей.
>1. Чтобы соснул кулхацкер, надо хранить хэши паролей в базе, а не пароли, а данные хранимые в базе - шифровать.
Как шифровать, хз правда, но это интересно.
Так стоп. Если кулхацкер поломал серв, то он может сделать всё что захочет, не?
Хотя не, если там в базе хэши паролей, то пароль он не узнает из хэшей, если конечно он не умеет обращать хэш-функции.
Ну а данные всякие может взять, да.
Хотя, если они пошифрованы (Как? RSA-пабкеем клиента штоле?), то не возьмёт, ведь для их расшифровки нужен будет ключ дешифрования (RSA-привкей, клиента, допустим).
Но если кулхацкер взломал серв то он может вписать в базу любые данные.
Но может быть тупо слив базы, хостером, или владельцем сервера, который арендуешь, чтобы хостить свой говносайт,
или продажа копии базы - хацкеру. Тогда хацкер может получить read-only доступ к базе, и шастать по слитой ему копии базы, но менять нихуя не сможет в реальной базе,
и если в базе всё пошифровано, то хацкер соснёт хуйц.
>Митмается также
>Diffie-Hellman Key Exchange (пик3)
>Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
Нашёл пикрелейтед. Выскажу свои соображения.
Что надо чтобы этой хуйни не было?
Надо исключить подмену A, g, p.
Если a будет сгенерирован заранее, и если A будет прешаренным, то подменить его митмщик не сможет, правильно?
Да, если A будет прешаренным, и a статичным и секретным, на сервере, то митмщик не сможет получить K, так как надо a.
>4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.
Хакера может быть два вида, поэтому изменю этот пункт так.
>4.3. Кулхацкер, взломавший сервер, и имеющий копию базы данных извнутри него, и имеющий доступ к таблице Users и значениям внутри неё,
>могущий их извлекать и читать, но не могущий изменять значения в реальной базе.
И добавлю ещё один
>4.4. Кулхацкер, взломавший сервер, и имеющий доступ к основнйо базе данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё,
>могущий не только их извлекать и читать, ещё и могущий изменять значения в реальной базе.
Я думаю, что от 4.4 ничего не поможет, ведь хакер взломавший сервер, может делать что угодно, может удалить нафиг базу,
может написать ХУЙ на говносайте, может вставить маты внутрь значений таблицы с пользовалей.
Что делать против такого? Очевидно, что пароль и/или хэш пароля - ему сообщать нельзя.
Поэтому, как вариант, может использоваться некая авторизация с использованием доказательства с нулевым разглашением,
в алгоритме которой я ещё не разобрался полностью.
Но я понял одно, там можно доказать что юзер знает пароль, при этом не передавая сам пароль,
что собственно и требуется, в качестве защиты от хакера 4.4.
Пусть делает со взломанным сервером что угодно, возможно старый сервер снова поднимут в другом месте,
главное чтобы он пароль не спиздил, верно?
Проверка подписи - это вариант доказательства с нулевым разглашением.
При реге, юзер генерит приватник, и шлёт пабкей, подписанный приватником. Всё, рега сделана, пабкей - в базу.
При авторизации, сервер шлёт некий рандомный ID,
юзер подписывает приватником его, и шлёт его назад с подписью цифровой. Сервер проверяет подпись. Это и есть доказательство с нулевым разглашением, так как приватник не передаётся.
2. от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning)
3. от школохацкера поможет банальные приёмы типа автоапдейта софта после обнаружения уязвимостей. От хацкера с зеродеями не поможет нихуя, можно только уменьшить вероятность если юзать банальные принципы минимальных привилегий и т.п.
>от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning)
есть какие-либо варианты обойти это у какира?
Только владение секретным ключом с сервера либо подмена встроенного публичного ключа на клиенте.
>от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning)
Да, я тоже, думал-думал так, и пришёл к DH+AES-схеме, с публичными и pre-shared DH-public key значения (p, g, A), вшитых в клиента.
В итоге, заилил это вот всё: https://github.com/username1565/nanoboard/commit/b37d98bde5b675d53d21ab60082c0e820ea5e6cf
Описание - здесь: https://github.com/username1565/nanoboard/blob/b37d98bde5b675d53d21ab60082c0e820ea5e6cf/scripts/DHAES.txt