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

у шнайера ничего такого нет?

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

Нет защиты от MitM. MD5 ненадёжна.

random

timestamp

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

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

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

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

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

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

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

ведь зная, что оно генерируется в формате random + timestamp + password

в принципе можно ещё соль добавить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что скажет коллективный разум?

Можешь ещё завернуть это в протокол Диффи-Хеллмана.

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

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

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

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

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

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

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

без имени

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

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

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

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

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

Хотя если у тебя там embeded

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

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

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

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