Hogyan lehet megvalósítani hitelesítését a kliens alkalmazás

1. Ha RSA probléma van. Az ügyfél tudja a nyilvános kulcsot a szerver, akkor titkosítja az adatokat, és továbbítja azt a szerver. A támadó elfogja titkosított ügyfél kérelmét, és küldje el a szerver (és a szerver dekódolja azt nem probléma a privát kulcs). Természetesen a támadó nem tudja megfejteni a választ a szerver, de a szerver a támadó kérésére már végre valamilyen cselekvés, és nem kellene.
2. Nincsenek felhasználóneveket és jelszavakat. A kliens és szerver - ezt az alkalmazást a php.
3. Lásd. 1. igénypont

Rutoken Web nem értem, hogyan lehet segíteni.

Opcióként titkosított test, írja még 1 TTL mező, amely tárolja (timestamp) küld, hogy a szerver ellenőrzés, ha a TTL nem régebbi, mint egy bizonyos ideig, például 3 perc. Tehát, ha egy támadó összegyűlnek a már aláírt üzenetet nem tudja bombázni a szerver helyett küldeni a szerver, nem történik semmi.

Általánosságban elmondható, hogy tegye kemény korlátok.

Nyilvánvalóan nem értett ... Aztán ott van csak SSL, vagy valami ilyesmi.
Az ügyfelek és kiszolgálók kell cserélni nyilvános kulcsok megbízható csatornát. Következő Ügyfél a szervert. A szerver egy session kulcsot. titkosítja a nyilvános kulcsát, és azt megküldi a Megrendelő részére.
Az ügyfél megkapja a session kulcsot, és dekódolja azt saját privát kulcsával.
Továbbá minden információ titkosított ezzel közös kulccsal. mert A támadó nem ismeri a kulcsot, és az adatok nem helyettesíti, és nem olvassa.
Ha egy biztonságos cseréjét nyilvános kulcsokat és biztonságosan tárolja zárt, akkor minden rendben lesz.

FanKiLL. TTL nem opció. Nem vagyok benne biztos, hogy az időt a szerver és a kliens ugyanaz lesz), és hogy egy kérést a szerver, hogy emlékezzen az időt, és várja a következő kérést 3 perc - nem megoldás. Igen, a keret elég nehéz, de mi tárgyalunk különböző lehetőségeket a keresést a „feltételes tökéletes.” Ideális esetben szeretnék valami ilyesmi: a kliens és a szerver beállításokat menti (a fogantyúk telepítésekor) minden adat (billentyűk, vagy valami ilyesmi). És akkor a kliens küld egy kérést az adatokat az 1. és a szerver felismerte, hogy az ügyfél nem a támadó (ha a támadó pontosan ugyanazt a kérést, a szerver kell megtagadni tőle). Egy ilyen „tökéletes” végrehajtása jó lenne használni valamilyen állandóan változó kulcsot 2, ugyanazon ügyfél kérelmére titkosított formában különbözőek voltak. Jó lenne, nyakkendő egy ideig (például a kód attól függ, hogy az idő és a megváltozott minden 5 másodpercben), de nem vagyok benne biztos, hogy az lesz ugyanaz.

AstralMan. ha a csere nyitva megbízható csatornát kulcs, hogy nem kell. Használhatja szinkron titkosítást. akkor a session kulcs nem működik, a támadó nem kell dekódolni az adatokat, csak elküldi a titkosított adatokat a szerverre, és a szerver nem érti, hogy ez nem egy ügyfél, és végrehajtja bizonyos intézkedéseket.

> Ha az árfolyam a nyilvános kulcsok megbízható csatornát, akkor nem kell.
Csak egy kell, hogy képes legyen generit session kulcs, amely nem képes elfogni a behatolót.

> Használhatja szinkron titkosítást. akkor a session kulcs nem működik, a támadó nem feltétlenül
> Dekódolni az adatokat, csak elküldi a titkosított adatokat a szerver
Nos, ő küldte az adatokat a szerverre, akkor mi van? Olyan választ kap a szervertől, és mit fog tenni vele nem tudom a session kulcsot.

> És a szerver nem érti, hogy ez nem egy ügyfél, és végrehajtja bizonyos intézkedéseket.
Minden kérelmet lehet továbbítani a munkamenet azonosítót generit szerver az első alkalommal, amikor egy ügyfél.

Valójában próbál végrehajtani PGP.
Ha nem az ügyfél természetesen - felmerül a kérdés, hogy együtt küldik titkosított test, amire szükség van, hogy mi az azonosítóval a szerver tudja, melyik gombot kell használni a titkosítás feloldásához (felhasználói név vagy azonosító stb kötődik a session kulcs ..). Nem lesz kérő hírbe összes kulcs még nem megfejteni.

AstralMan. Azt is generálja a session kulcsot és titkosítja azt a kulcsot, aki ismeri a kliens és a szerver tudja. Ugyanazt a kulcsot ügyfél visszafejteni a session kulcsot. A támadó nem tudja visszafejteni. A szerverek válaszolni a támadó nem érdekli, akkor küldje el az adatokat, és a szerver tenni valamit (törölje a rekordot, köztük a modul, akkor küld katonákat Taganrog, stb.)

FanKiLL. Nos, az ügyfél lehet bemutatni a nyitott, mondván: „Én% clientUniqueName%», és az adatok továbbítása titkosítva.

Anonym Akkor marad a probléma, hogy a támadó bombázza a szerver küld% clientUniqueName% + egy szöveget, akkor hulladék szerver erőforrások próbál razshifrovat + világos, hogy az adatok valóban megfejteni pl ellenőrizze, hogy van egy olyan megszűnt területén ...

Azt hiszem, először is meg kell oldani a problémát azonosító, úgyhogy felesleges kérelmeket elutasították ebben a szakaszban, a második szakaszban a dekódolás. Amit leírt megoldja az egyik probléma a harmadik fél nem tudja olvasni / módosítani az adatokat.
Problémák maradnak:
1) A gyűjtemény már titkosított üzeneteket, és elküldjük őket a szerver (például, ha egy parancs, hogy add meg az adatbázis, a legjobb esetben csinálsz egy átvilágítás egy dupla és nem történik semmi, a legrosszabb lesz löncshús)
2) az erőforrások visszafejteni hagyott üzeneteket.

Anonym. akkor minden kérést kell egy egyedi számot, és kétszer is nem jött össze.
A kliens megmondja a szervernek akarom törölni az adatokat szerver tárolja a kérést, és elküldi az ügyfél kérésére azonosítója. A kliens elküldi az azonosító szerver. Szerver eltávolítja az adatokat, és írja meg az azonosítót. Ha a támadó küld újra a kérelmet, akkor a szerver ellenőrzi az azonosító nem csinál semmit, mert Én már teljesítették ezt a kérést.
Valami ilyesmi ... a többi lehetőség nem lát.