subject: Аутентификация поинтов через несекьюрное соединение
29.10.2024 09:50
shaos (spnet, 2)
Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
https://datatracker.ietf.org/doc/html/rfc2104
RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
https://datatracker.ietf.org/doc/html/rfc2286
RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
https://datatracker.ietf.org/doc/html/rfc2857
Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
URL/u/point2/koi7/B64AUTH/B64STRING
для больших сообщений можно задействовать метод POST:
URL/u/point2/koi7/B64AUTH
TEXT
причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
Обсуждаем? :)
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 09:59
shaos (spnet, 2) => Arm3cWBCsoq0BQgVzVzW
Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром:
/u/point2/utf8
/u/point2/koi7
/u/point2/koi8r
/u/point2/cp866
/u/point2/cp1251
При получении узел будет сам переконвечивать это в UTF-8 (если пришёл не UTF-8)
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 10:43
Andrew Lobanov (tavern,1) => Arm3cWBCsoq0BQgVzVzW
shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)
Да чего тут обсуждать? Нормальное расширение -- делай.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 11:47
revoltech (spnet, 4) => Ccg6QiJbsxfRZqgIz9cZ
shaos> Да - в /x/features поддерживаемые кодировки можно перечислить таким макаром
Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.
По передаче паролей — ума не приложу, как люди с паролями по plain http раньше жили. Конечно, времена поменялись, но зачем городить огород с хэшами? Не проще ли сделать что-то типа HOTP/TOTP и использовать одноразовый код в качестве authstring, если уж так приспичило? Но опять же, это вопрос реализации, в стандарт это тоже тащить не стоит, имхо.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 17:23
shaos (spnet, 2) => F1EFAgrOtuvIGUtIcqka
Ну это типа кастомное расширение
HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:10
shaos (spnet, 2) => F1EFAgrOtuvIGUtIcqka
> Вот это в стандарт точно тащить не надо. Кому в 2024 году нужно что-то, кроме UTF-8? А всякие кои и 1251 за пределами постсовка и раньше никому не нужны были.
cp1252 ещё можно добавить т.к. оно ещё вполне в ходу :)
https://en.wikipedia.org/wiki/Windows-1252
"It is the most-used single-byte character encoding in the world. Although almost all websites now use the multi-byte character encoding UTF-8, as of July 2024 1.2%[4] of websites declared ISO 8859-1 which is treated as Windows-1252 by all modern browsers (as demanded by the HTML5 standard[5]), plus 0.3% declared Windows-1252 directly,[4][6] for a total of 1.5%. Some countries or languages show a higher usage than the global average, in 2024 Brazil according to website use, use is at 3.4%,[7] and in Germany at 2.7%.[8][9] (these are the sums of ISO-8859-1 and CP-1252 declarations)."
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:19
revoltech (spnet, 4) => rPvWvHAmPwdKqKBewPGx
shaos> HOTP потяжелее наверное - и там ведь ещё больший «огород с хешами» ?
Нет, не больший. И преимущество оного в том, что можно в случае с TOTP вынести этот нюанс в какой-нибудь Aegis/Authy/гугловский аутентификатор, а в случае с HOTP — вообще в отдельный аппаратный ключ. И не нагружать бедный ретроклиент.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:32
shaos (spnet, 2) => pQPFMIsmMWz9hD1CJ2tr
Ну вот - аппаратный ключ городить ещё
А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:42
revoltech (spnet, 4) => ovuX4IWmnmBrxtLuEE2r
shaos> А на сторонние аутентификаторы совсем не хочется завязываться - всё должно работать даже в случае тотального отключения глобальных сервисов...
Сторонний аутентификатор, работающий так же, как и всё вышеперечисленное, пишется максимум за полчаса на любом мейнстримном ЯП.
https://www.rfc-editor.org/rfc/rfc6238
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:48
shaos (spnet, 2) => 3fBFYzAzhcsvWg4eMTF2
Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
В моём случае зареюзать не получится т.к. оно зависит от контента
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:52
shaos (spnet, 2) => 3tnV5YLvGxinw8z0CEMG
" All the communications SHOULD take place over a secure channel, e.g.,
Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
IPsec connections [RFC4301]."
Это show stopper...
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:56
revoltech (spnet, 4) => 3tnV5YLvGxinw8z0CEMG
shaos> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.
Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 18:58
revoltech (spnet, 4) => wmluHn0saf7EebryINbP
shaos> " All the communications SHOULD take place over a secure channel, e.g.,
shaos> Secure Socket Layer/Transport Layer Security (SSL/TLS) [RFC5246] or
shaos> IPsec connections [RFC4301]."
shaos>
shaos> Это show stopper...
Это should, а не must, а на самом деле пофигу вообще. Между клиентом и сервером только начальная регистрация ключа должна быть секьюрной.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 20:45
shaos (spnet, 2) => Ey3fF61EJm2UxfSTvoBr
should = must
Американцы не любят слово must
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 20:50
shaos (spnet, 2) => 3hzbA9rBCPIlGfioSiVZ
т.е. ты предлагаешь вводить код ручками при каждой посылке? Нет спасибо :)
В моём варианте всё считается автоматически - нажал на Send и оно ушло…
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 20:58
Andrew Lobanov (tavern,1) => 3hzbA9rBCPIlGfioSiVZ
shaos>> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
revoltech> Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.
revoltech> Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.
Ты шутишь сейчас? Лигитимный пользователь может подряд сколько угодно сообщений подряд отправлять. А /u/push вообще не для пользователей, а для других узлов сети. В том же цезии я не отправляю по одному сообщению, а отвечаю сразу на всё, что нового прилетело, а потом они пачкой по одному улетают. Зачем ломать клиенты?
Или ты предполагаешь, что клиент, отправив сообщение, будет ждать 30 секунд перед отправкой следующего? Нафиг такой клиент нужен тогда?
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 22:39
shaos (spnet, 2) => wT4majKSbAi77KmnSRD6
А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
29.10.2024 23:52
shaos (spnet, 2) => B56GhDDcVMy37WDJ6mAS
В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль
Тоже надо сделать свой вариант :)
Кстати зачем там echoarea если имя эти есть в каждом сообщении?…
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 09:50
Andrew Lobanov (tavern,1) => B56GhDDcVMy37WDJ6mAS
shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…
По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 09:50
Andrew Lobanov (tavern,1) => AcIXYpDTtIeWvmNexZlF
shaos> В новой спеке написано «строка авторизации узла» что по видимому намекает на специальный пароль
shaos> Тоже надо сделать свой вариант :)
shaos> Кстати зачем там echoarea если имя эти есть в каждом сообщении?…
Для обратной совместимости. Пуши к нам тоже из ii приехали, вроде.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 10:07
doesnm (ping,55) => B56GhDDcVMy37WDJ6mAS
shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…
Емнип он совпадает с паролем к sysop.php
+++ Никто не знает, как правильно. Так зачем же выдумывать правила?
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 15:53
shaos (spnet, 2) => l3ygMBW7tL60mzzayrtY
> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
Может тогда как-то почётче это в стандарте про push проговорить?
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 16:02
ahamai (blackcat, 2) => tIlaQAfOqYfF0z8OSlXZ
у меня вроде вообще не было стандарта на push, я его и не поддерживал, но в push-нодах всегда был отдельный пароль
push-ноды для меня были как партизанские станции, которые раскидываешь по бесплатным php-хостингам и с ними живёшь. на серьёзных станциях он не был предусмотрен, потому что серьёзные станции только фетчат и на них нельзя что-то вливать
--------------------------------------------------------------------------------
subject: Re: Аутентификация поинтов через несекьюрное соединение
30.10.2024 16:32
Andrew Lobanov (tavern,1) => tIlaQAfOqYfF0z8OSlXZ
>> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
shaos> Может тогда как-то почётче это в стандарте про push проговорить?
Хорошо. Принимается.
+++ Caesium/0.4 RC1
--------------------------------------------------------------------------------