( asch | 2013. 02. 20., sze – 14:51 )

Csatlakozom az előttem szólóhoz abban, hogy a titkosítás témakör nehéz, biztosat állítani szakismeret nélkül lehetetlen. És én sem vagyok szakértő.

Viszont annyit érdemes lenne végiggondolni, hogy mi ellen véd ez a megoldás?
* egyedi algoritmus, tehát a támadó nem tudja, hol kezdje a támadást -> Security by obscurity, olvas utána, hogy szerinted érdemes-e vagy nem
* A jelszó plaintext közlekedik, tehát ellopható. Emiatt egyszer használatos legyen a jelszó, így ha ellopják is, akkor sem tudnak belépni vele. Ezzel az a baj, hogy "Man in the Middle" támadás ellen nem véd, a felépülő kapcsolatba bárki belekontárkodhat
* A jelszó titkosított és hitelesített csatornán közlekedik, de a helyi (kliens) gépen lévő keylogger ellen védeni kell. Ha a helyi gép kompromittálódott, akkor a helyi gépen futó jelszó generáló algoritmus is kompromittálódhatott, tehát megint csak oda a biztonság.
* A helyi (kliens) gép biztonságosnak tekinthető, és ezen fut a jelszó generálás, illetve az authentikált és titkosított kapcsolat. Ebben az esetben miért ne lenne elég egy "sima" ssh privát kulcs alapú kliens authentikáció? Mitől jobb a jelszó generálás?
* Külön kütyün fut a jelszó generálás, a kliens gép pedig authentikált (a szerver authentikálja magát publikus/privát kulccsal) és titkosított csatornán lép be. De a kliens gép nem számít megbízhatónak, ezért kell a külön kütyü a jelszógeneráláshoz. Ebben az esetben viszont a szerver authentikációja nem lesz megbízható, mert az authentikációt végző gép maga nem megbízható.

Akárhogy is nézzük minden végiggondolásnak az a vége, hogy amennyiben a kliens (titkosítást és authentikációt végző) gép nem megbízható, akkor a kommunikáció sem lesz az. Ha viszont megbízható, akkor a kulcs alapú authentikációnál nem nagyon van jobb. Ezért elméleti szempontból felesleges az ilyen token-szerű jelszó generálás. Persze ettől még egy kicsit nehezítheti a támadó dolgát a gyakorlatban.