Я думаю, эта тема достойна отдельного треда в криптаче. Добро пожаловать в авторизации тред.
Здесь мы рассмотрим, казалось бы, простую задачу - реализацию регистрации-авторизации клиента на сервере. Но рассмотрим мы её, с точки зрения перехвата снифферами данных, передающихся по открытому каналу, а также с точки зрения возможности реализации 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). Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
>>46773 (OP) >4. Взломщики: >4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.
>Задача: Реализовать алгоритмы, чтобы взломщики соснулей.
>1. Чтобы соснул кулхацкер, надо хранить хэши паролей в базе, а не пароли, а данные хранимые в базе - шифровать. Как шифровать, хз правда, но это интересно.
Так стоп. Если кулхацкер поломал серв, то он может сделать всё что захочет, не?
>>46774 Хотя не, если там в базе хэши паролей, то пароль он не узнает из хэшей, если конечно он не умеет обращать хэш-функции. Ну а данные всякие может взять, да. Хотя, если они пошифрованы (Как? RSA-пабкеем клиента штоле?), то не возьмёт, ведь для их расшифровки нужен будет ключ дешифрования (RSA-привкей, клиента, допустим). Но если кулхацкер взломал серв то он может вписать в базу любые данные. Но может быть тупо слив базы, хостером, или владельцем сервера, который арендуешь, чтобы хостить свой говносайт, или продажа копии базы - хацкеру. Тогда хацкер может получить read-only доступ к базе, и шастать по слитой ему копии базы, но менять нихуя не сможет в реальной базе, и если в базе всё пошифровано, то хацкер соснёт хуйц.
>>46773 (OP) >Митмается также >Diffie-Hellman Key Exchange (пик3)
>Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
Нашёл пикрелейтед. Выскажу свои соображения. Что надо чтобы этой хуйни не было? Надо исключить подмену A, g, p. Если a будет сгенерирован заранее, и если A будет прешаренным, то подменить его митмщик не сможет, правильно?
>>46773 (OP) >4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.
Хакера может быть два вида, поэтому изменю этот пункт так.
>4.3. Кулхацкер, взломавший сервер, и имеющий копию базы данных извнутри него, и имеющий доступ к таблице Users и значениям внутри неё, >могущий их извлекать и читать, но не могущий изменять значения в реальной базе. И добавлю ещё один >4.4. Кулхацкер, взломавший сервер, и имеющий доступ к основнйо базе данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё, >могущий не только их извлекать и читать, ещё и могущий изменять значения в реальной базе.
Я думаю, что от 4.4 ничего не поможет, ведь хакер взломавший сервер, может делать что угодно, может удалить нафиг базу, может написать ХУЙ на говносайте, может вставить маты внутрь значений таблицы с пользовалей. Что делать против такого? Очевидно, что пароль и/или хэш пароля - ему сообщать нельзя. Поэтому, как вариант, может использоваться некая авторизация с использованием доказательства с нулевым разглашением, в алгоритме которой я ещё не разобрался полностью. Но я понял одно, там можно доказать что юзер знает пароль, при этом не передавая сам пароль, что собственно и требуется, в качестве защиты от хакера 4.4. Пусть делает со взломанным сервером что угодно, возможно старый сервер снова поднимут в другом месте, главное чтобы он пароль не спиздил, верно?
>>46784 Проверка подписи - это вариант доказательства с нулевым разглашением. При реге, юзер генерит приватник, и шлёт пабкей, подписанный приватником. Всё, рега сделана, пабкей - в базу. При авторизации, сервер шлёт некий рандомный ID, юзер подписывает приватником его, и шлёт его назад с подписью цифровой. Сервер проверяет подпись. Это и есть доказательство с нулевым разглашением, так как приватник не передаётся.
1. от сниффера помогает шифрование связкой симметричный шифр + асимметричный шифр (как в TLS или SSH). 2. от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning) 3. от школохацкера поможет банальные приёмы типа автоапдейта софта после обнаружения уязвимостей. От хацкера с зеродеями не поможет нихуя, можно только уменьшить вероятность если юзать банальные принципы минимальных привилегий и т.п.
>>47189 >от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning) Да, я тоже, думал-думал так, и пришёл к DH+AES-схеме, с публичными и pre-shared DH-public key значения (p, g, A), вшитых в клиента.