Як реалізувати авторизацію клієнтської програми

1. При використанні RSA є проблема. Клієнт знає публічний ключ сервера, шифрує їм дані і передає на сервер. Зловмисник перехоплює зашифровані запит клієнта і може відправити його серверу (а сервер його без проблем розшифрує своїм приватним ключем). Звичайно ж зловмисник не зможе розшифрувати відповідь сервера, але сервер на запит зловмисника вже виконає якусь дію, а не мав би.
2. Немає ніяких логінів і паролів. Клієнт і сервер - це додатки на php.
3. Див. П.1

Рутокен Web взагалі не розумію як може мені допомогти.

Як варіант в зашифрованому тілі, ввести ще 1 поле TTL в якій буде зберігатися (timestamp) відправки, на сервері перевіряємо якщо TTL не старші певного часу наприклад 3 хвилини. Так якщо зловмисник збере вже підписані повідомлення він не зможе ними бомбити сервер, вірніше відіславши на сервері нічого не станеться.

А взагалі ви поставили жорсткі рамки.

Мабуть не так зрозумів ... Тоді тут тільки SSL або щось подібне.
Клієнт з Сервером повинні обмінятися відкритими ключами по довіреній каналу. Далі Клієнт звертається до Сервера. Сервер генерує сесійний ключ. зашифровує його відкритим ключем Клієнта і відправляє його.
Клієнт отримує сесійний ключ і розшифровує його своїм закритим ключем.
Далі вся інформація шифрується цим сесійним ключем. Оскільки зловмисник не знатиме цей ключ то і дані він не підмінить і не прочитає.
Якщо забезпечити безпечний обмін відкритими ключами і надійно зберігати закриті, то все буде ОК.

FanKiLL. TTL не варіант. Я не впевнений, що час на сервері і клієнті буде збігатися) А робити +1 запит до сервера, щоб той запам'ятав час і очікував наступний запит 3 хвилини - це не варіант. Так, рамки досить жорсткі, але ми ж обговорюємо різні варіанти в пошуках «умовно ідеального». В ідеалі мені хотілося б якось так: на клієнті і сервері в налаштуваннях зберігаємо (ручками при установці) якісь дані (ключі або щось подібне). І щоб після цього клієнт міг відправити 1 запит з даними, а сервер зрозумів, що це клієнт, а не зловмисник (якщо зловмисник відправить точно такий же запит, сервер повинен йому відмовити). Для такої «ідеальної» реалізації було б ефективно використати якийсь постійно змінюється ключ, щоб 2 однакових запиту клієнта в зашифрованому вигляді були різними. Непогано було б зав'язатися на час (скажімо, шифр залежить від часу і змінюється раз в 5 секунд), але я не впевнений, що час буде збігатися.

AstralMan. якщо обмінюватися відкритими ключами по довіреній каналу, то вони зовсім не потрібні. Можна використовувати синхронне шифрування. Сесійна ключ тут не допоможе, зловмиснику не обов'язково розшифровувати дані, він просто відправить зашифровані дані сервера, а сервер вже не зрозуміє, що це не клієнт і виконає якусь дію.

> Якщо обмінюватися відкритими ключами по довіреній каналу, то вони зовсім не потрібні.
Якраз-то потрібні, щоб можна було генерувати сесійний ключ який не зможе перехопити зловмисник.

> Можна використовувати синхронне шифрування. Сесійна ключ тут не допоможе, зловмиснику не обов'язково
> Розшифровувати дані, він просто відправить зашифровані дані сервера
Ну відправив він дані сервера, і що? Отримає відповідь від сервера, а що він з ним буде робити не знаю сесійного ключа.

> А сервер вже не зрозуміє, що це не клієнт і виконає якусь дію.
У кожному запиті можна передавати ID сесії який генерувати Сервер при першому зверненні Клієнта.

По суті ви намагаєтеся імплементувати PGP.
Якщо у вас не один клієнт звичайно - Постає питання, що посилати разом із зашифрованим тілом, потрібен якийсь ідентифікатор щоб сервер знав який ключ йому застосувати для розшифровки (ім'я користувача або id і т. Д. До якого прив'язаний сесійний ключ). Ви ж не будете в for розшифрувати застосовуючи всі ключі поки не розшифруєте.

AstralMan. Я зможу згенерувати сесійний ключ і зашифрувати його ключем, який знає клієнт і знає сервер. Цим же ключем клієнт розшифрує сесійний ключ. Зловмисник розшифрувати його не зможе. Відповідь сервера зловмисника не цікавить, він відправить дані, а сервер щось зробить (видалить запис, включить модуль, вишле солдат в Марганець, etc.).

FanKiLL. ну клієнт може представитися в відкриту, мовляв «я% clientUniqueName%», а дані відправити шифровані.

Anonym Тоді залишається проблема, зловмисник бомбить сервер відсилаю% clientUniqueName% + какой то текст, ви витрачаєте серверні ресурси намагаючись разшіфровать + зрозуміти чи дійсно дані розшифрувати наприклад перевірка чи є какао-то поле ...

Мені здається треба спочатку вирішити проблему ідентифікації, щоб непотрібні запити відкидалися на цьому етапі, другий етап розшифровка. Те що ви описали вирішує одну проблему третя особа не може прочитати / змінити дані.
Залишаються проблеми:
1) Збір вже зашифрованих повідомлень і повторна відправка їх на сервер (наприклад якщо це команда додати що то в базу, в кращому випадку ви зробите перевірку на дубль і нічого не станеться, в гіршому будете заспамленності)
2) Витрата ресурсів на дешифрування лівих повідомлень.

Anonym. тоді кожному запиту треба привласнювати унікальний номер і двічі його відпрацьовується.
Клієнт говорить Серверу я хочу видалити дані, Сервер зберігає запит і відправляємо Клієнт ID запиту. Клієнт пересилає це ID Серверу. Сервер видаляємо дані і записує ID. Якщо зловмисник передає цей запит ще раз, то Сервер перевіривши цей ID нічого не зробить тому вже виконав цей запит.
Якось так ... інших варіантів поки не бачу.