Главная Юзердоски Каталог Трекер NSFW Настройки

Криптоанархия

Ответить в тред Ответить в тред

Доска закрыта.

Check this out!
<<
Назад | Вниз | Каталог | Обновить | Автообновление | 11 6 7
Авторизации тред. Аноним 24/05/21 Пнд 11:22:45 46773 1
image.png 188Кб, 600x600
600x600
image.png 31Кб, 794x314
794x314
image.png 71Кб, 850x423
850x423
image.png 133Кб, 720x540
720x540
Перекат из программача /pr/ : https://2ch.hk/pr/res/2035184.html

Я думаю, эта тема достойна отдельного треда в криптаче.
Добро пожаловать в авторизации тред.

Здесь мы рассмотрим, казалось бы, простую задачу - реализацию регистрации-авторизации клиента на сервере.
Но рассмотрим мы её, с точки зрения перехвата снифферами данных,
передающихся по открытому каналу, а также с точки зрения возможности реализации 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).
Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.
Аноним 24/05/21 Пнд 11:38:05 46774 2
>>46773 (OP)
>4. Взломщики:
>4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.

>Задача: Реализовать алгоритмы, чтобы взломщики соснулей.

>1. Чтобы соснул кулхацкер, надо хранить хэши паролей в базе, а не пароли, а данные хранимые в базе - шифровать.
Как шифровать, хз правда, но это интересно.

Так стоп. Если кулхацкер поломал серв, то он может сделать всё что захочет, не?
Аноним 24/05/21 Пнд 11:42:35 46775 3
>>46774
Хотя не, если там в базе хэши паролей, то пароль он не узнает из хэшей, если конечно он не умеет обращать хэш-функции.
Ну а данные всякие может взять, да.
Хотя, если они пошифрованы (Как? RSA-пабкеем клиента штоле?), то не возьмёт, ведь для их расшифровки нужен будет ключ дешифрования (RSA-привкей, клиента, допустим).
Но если кулхацкер взломал серв то он может вписать в базу любые данные.
Но может быть тупо слив базы, хостером, или владельцем сервера, который арендуешь, чтобы хостить свой говносайт,
или продажа копии базы - хацкеру. Тогда хацкер может получить read-only доступ к базе, и шастать по слитой ему копии базы, но менять нихуя не сможет в реальной базе,
и если в базе всё пошифровано, то хацкер соснёт хуйц.
Аноним 24/05/21 Пнд 12:23:45 46776 4
image.png 156Кб, 592x445
592x445
>>46773 (OP)
>Митмается также
>Diffie-Hellman Key Exchange (пик3)

>Поэтому, алсо, это тред о митм-защищённых схемах и алгоритмах обмена ключей, в открытых каналах.

Нашёл пикрелейтед. Выскажу свои соображения.
Что надо чтобы этой хуйни не было?
Надо исключить подмену A, g, p.
Если a будет сгенерирован заранее, и если A будет прешаренным, то подменить его митмщик не сможет, правильно?
Аноним 24/05/21 Пнд 12:27:14 46777 5
image.png 15Кб, 400x220
400x220
>>46776
Да, если A будет прешаренным, и a статичным и секретным, на сервере, то митмщик не сможет получить K, так как надо a.
Аноним 26/05/21 Срд 16:43:43 46784 6
>>46773 (OP)
>4.3. Кулхацкер, взломавший сервер, базу данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё.

Хакера может быть два вида, поэтому изменю этот пункт так.

>4.3. Кулхацкер, взломавший сервер, и имеющий копию базы данных извнутри него, и имеющий доступ к таблице Users и значениям внутри неё,
>могущий их извлекать и читать, но не могущий изменять значения в реальной базе.
И добавлю ещё один
>4.4. Кулхацкер, взломавший сервер, и имеющий доступ к основнйо базе данных внутри него, и имеющий доступ к таблице Users и значениям внутри неё,
>могущий не только их извлекать и читать, ещё и могущий изменять значения в реальной базе.

Я думаю, что от 4.4 ничего не поможет, ведь хакер взломавший сервер, может делать что угодно, может удалить нафиг базу,
может написать ХУЙ на говносайте, может вставить маты внутрь значений таблицы с пользовалей.
Что делать против такого? Очевидно, что пароль и/или хэш пароля - ему сообщать нельзя.
Поэтому, как вариант, может использоваться некая авторизация с использованием доказательства с нулевым разглашением,
в алгоритме которой я ещё не разобрался полностью.
Но я понял одно, там можно доказать что юзер знает пароль, при этом не передавая сам пароль,
что собственно и требуется, в качестве защиты от хакера 4.4.
Пусть делает со взломанным сервером что угодно, возможно старый сервер снова поднимут в другом месте,
главное чтобы он пароль не спиздил, верно?
Аноним 21/07/21 Срд 02:54:04 47081 7
>>46784
Проверка подписи - это вариант доказательства с нулевым разглашением.
При реге, юзер генерит приватник, и шлёт пабкей, подписанный приватником. Всё, рега сделана, пабкей - в базу.
При авторизации, сервер шлёт некий рандомный ID,
юзер подписывает приватником его, и шлёт его назад с подписью цифровой. Сервер проверяет подпись. Это и есть доказательство с нулевым разглашением, так как приватник не передаётся.
Аноним 04/08/21 Срд 15:51:53 47189 8
1. от сниффера помогает шифрование связкой симметричный шифр + асимметричный шифр (как в TLS или SSH).
2. от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning)
3. от школохацкера поможет банальные приёмы типа автоапдейта софта после обнаружения уязвимостей. От хацкера с зеродеями не поможет нихуя, можно только уменьшить вероятность если юзать банальные принципы минимальных привилегий и т.п.
Аноним 09/08/21 Пнд 14:31:38 47200 9
>>47189
>от митма поможет вшивание паблик ключа в клиента (т.н. certificate pinning)
есть какие-либо варианты обойти это у какира?
Аноним 09/08/21 Пнд 20:50:15 47201 10
>>47200
Только владение секретным ключом с сервера либо подмена встроенного публичного ключа на клиенте.
Аноним 11/08/21 Срд 22:15:16 47220 11
>>47189
>от митма поможет вшивание паблик ключа в клиента (т.н. 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
Настройки X
Ответить в тред X
15000
Добавить файл/ctrl-v
Стикеры X
Избранное / Топ тредов