Недостатки обмена данными с контрольной суммой в качестве подписи

[SiZE]

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

 

[WMix]

Неоправданная сложность исходя из того что это всеравно не работает

 

[SiZE]

Неоправданная сложность исходя из того что это всеравно не работает

О какой сложности речь? Там делов на полторы строчки =) Я про общение клиент сервер, типа как апи робокассы.

 

[флоппик]

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

 

[AnrDaemon]

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

 

[WMix]

Кто начинает коммуникацию? В платежных системах сервер информирует о новой трансакции, а клиент проверяет. Если просто сложил хеш, то не проверен является ли запрос настоящим ( от правильного сервера ), те гораздо правильней, на мой взгляд, переспросить сервер чем опираться на хеш.

 

[MiksIr]

Такая схема в том числе используется как подпись для оформления заказа. Дабы нельзя было, например, поставить меньшую сумму.

Переспрашивать сервер - тоже не панацея, ибо может быть MITM атака.

Подпись - вполне работоспособная схема. Назвыается это HMAC

 

[WMix]

MITM организовать сложнее. а если есть сертификат удаленного сервера, кажись невозможно, но в принципе согласен простая подпись работает