LINUX.ORG.RU
ФорумTalks

Сверхпростой протокол аутентификации

 , ,


0

5

Задача - взаимная аутентификация сервера и клиента по паролю (без имени), процедура должна реализовываться посредством текстового протокола (требования не обсуждаются, они «константа»). Алгоритм должен быть легко реализуем без всяких openssl/gnutls, максимум допустимо использовать какой-нибудь алгоритм построения хэш-суммы - клиентов (и возможно и серверы) предстоит писать на Java/C++/ObjC/Delphi/C#/Vala/Python.

Пока появилась такая идея - после подключения клиента, сервер отдает клиенту рандомное значение и отправляет сообщение вида:

type:auth
random:123456789

Клиент формирует ответ вида

type:auth
random:987654321
timestamp:124364477 (это GMT-time-in-millis)
checksum: MD5(<timestamp-указанный-выше>+":"+<рандом сервера == 123456789>+":"+<пароль>)

Сервер проверяет валидность таймстампа (в пределах допустимого отклонения), проверяет валидность контрольной суммы (таймстамп сказал клиент, рандом ранее сгенерирован, пароль известен). Если проверка нормальная, сервер сам аутентифицируется перед клиентом:

type:auth
timestamp:124365897
checksum: MD5(<таймстамп-из-сообщения>+":"+<рандом клиента == 987654321> + ":" + <пароль>)

В принципе, алгоритм кажется достаточно надёжным - пароль не передается ни в каком виде, на каждый сеанс вылетают свои случайные числа. Что скажет коллективный разум?

★★★★★

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

Ну это в общем то практически классический алгоритм - строгая аутентификация на основе хэш-функции.

no-dashi ★★★★★ ()

random

timestamp

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

checksum ваш не отличается ничем от сырого пароля md5(password), ведь зная, что оно генерируется в формате random + timestamp + password, первые два которые вы уже передаете в открытом виде, его точно так же легко можно подобрать.

именно таким образом происходит аутентификация при подключении jabber серверу, там тоже составляется сложный набор значений и проверка по md5 в итоге.

не парьтесь, не мудрите, делайте обычный md5(password + salt), а как дозреете до нормального шифрования, просто прикрутите поверх протокола. чо.

Spoofing ★★★★★ ()

на худой конец вы можете пробросить SSH-тоннель на один единственный порт этой программы, либо поднять VPN если у вас сеть. вон, сколько готовых решений ради вашего блага, если вы так не хотите в 2015 году использовать элементарное SSL шифрование.

Spoofing ★★★★★ ()

в принципе ты придумал уже существующий велосипед. Только замени деревянную раму MD5 на более современную, стальную: SHA1.

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

MD5 можно заменить на любую другую (например, SHA***). Насчет MitM - каким образом он здесь может сыграть? Если он не знает пароля (а предполагаем, что он его не знает), он не пройдет аутентификацию как клиент перед сервером, replay также невозможен, поскольку с каждой стороны есть Nonce - рандом, генерируемый сервером и используемый клиентом на шаге 2 и генерируемый клиентом и используемый сервером на шаге 3.

no-dashi ★★★★★ ()
Ответ на: комментарий от emulek

сам формат как-бэ выступает в роли «соли», {«random»:«timestamp»:«password»} и еще каких-нибудь закорючек приписать. осталось всем сотрудникам подписать бумашку о неразглашении и дело в шляпе. =-)

Spoofing ★★★★★ ()
Ответ на: комментарий от no-dashi

Когда трафик не шифруется, MitM может его прослушать и узнать все те секреты, ради которых ты, видимо, и прикручиваешь аутентификацию.

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

ведь зная, что оно генерируется в формате random + timestamp + password, первые два которые вы уже передаете в открытом виде, его точно так же легко можно подобрать.

Это уже просто проблема качества пароля (длина, сложность, алфавит).

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

и зойчем изначально все усложнять? сделайте сложный пароль, посолив по-вкусу. нинужно мудрить со всякими таймштампами, аптаймом системы и прочем %)

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

Если трафик шифруется, надо нормальный ключ (+ реализовывать безопасный обмен ключами, и в итоге скатиться к сертификатам и TLS). Если этого не делать, всё опять же сводится к тривиальному брутфорсу ключа/пароля.

no-dashi ★★★★★ ()
Ответ на: комментарий от Spoofing

сам формат как-бэ выступает в роли «соли», {«random»:«timestamp»:«password»}

вот это-то и является уязвимым местом алгоритма.

можно просто добавить в протокол соль, которая известна и клиенту и серверу. Тогда бумажки о неразглашении не нужно, т.к. всем сотрудникам знать эту соль необязательно.

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

нинужно мудрить со всякими таймштампами, аптаймом системы и прочем

Таймстампы и рандомы - это чтобы replay не прокатил.

no-dashi ★★★★★ ()
Ответ на: комментарий от Relan

Когда трафик не шифруется, MitM может его прослушать и узнать все те секреты, ради которых ты, видимо, и прикручиваешь аутентификацию.

Ыыыы, там в соединении данных важнее чем когда звонила любовница и что надо купить в магазине в общем-то и не предвидится :-)

no-dashi ★★★★★ ()
Ответ на: комментарий от Spoofing

и зойчем изначально все усложнять? сделайте сложный пароль, посолив по-вкусу.

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

Это такой кастрированный текстовый вариант обычной аутентификации с закрытым и открытым ключом. В который зачем-то добавили timestamp, и убрали явный открытый ключ.

Пусть ТС ещё немного подумает, и придумает годный вариант. А потом его можно будет смело выкинуть, и использовать тоже самое из OpenSSL, как делают все нормальные люди.

emulek ()
Последнее исправление: emulek (всего исправлений: 1)

Основной минус такой конструкции — необходимость хранить пароли клиентов в открытом виде на сервере.

maxcom ★★★★★ ()
Ответ на: комментарий от no-dashi

в итоге скатиться к сертификатам и TLS

почему-бы сразу не сделать самоподписанный TLS?

реализовывать безопасный обмен ключами

в твоей схеме тоже надо как-то передавать пароль в открытом виде при регистрации.

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

Основной минус такой конструкции — необходимость хранить пароли клиентов в открытом виде на сервере.

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

на клиенте нужно хранить пароль клиента(в открытом виде), и хеши всех серверов.

И клиент и сервер должны меняться рандомной солью, которой создавать сеансовый хеш.

Ну короче OpenSSL, в текстовом виде и вместо ключей — пароли и хеши.

emulek ()
Ответ на: комментарий от no-dashi

Если трафик шифруется, надо нормальный ключ (+ реализовывать безопасный обмен ключами, и в итоге скатиться к сертификатам и TLS).

Вот о том и речь. Можно, правда, упростить эту схему, если клиент и сервер заранее обменялись публичными ключами.

Relan ★★★★★ ()

без имени

Т.е. пароль только один, или имя вычисляется иными способами.

MD5(<таймстамп-из-сообщения>+":«+<рандом клиента == 987654321> + »:" + <пароль>)

Похоже, у тебя получилась ослабленная реализация cram-md5. Думаю, взломщик может очень хорошо подготовиться к подбору пароля по наблюдению будущего сеанса связи.

DonkeyHot ★★★★★ ()

Man-in-the-middle?
Хреновый интернет, и выход за пределы допустимого отклонения ?

Kaschenko ()

Сделай самоподписный сертификат и не страдай фигнёй.

r_asian ★☆☆ ()

Твоюжмать, подписался на уведомления в толксах >_<

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

Вот у меня, например, есть такой embeded, и (мне) интересно что можно свелосипедить если понадобится. А тут целый тред капитанов с TLS наперевес...

Stil ★★★★★ ()

В общем, завелосипедил, забыдлокодил на жабе. Сервером работает телефон, клиентом консольное приложение (на той же жабе). Осталось консольного клиента переписать, дописать discovery - и Анонсирован Nuntius, транслятор уведомлений из Android в GNOME a.k.a. Nuntis можно выкидывать :-)

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

Будешь выкладывать в общий доступ? Если да, то кинь сюда ссылку, пожалуйста, или кастани.

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