Valami hasonlót csináltam anno én is, 3DES-sel:
-szerver generált egy random kódot, DB.ben lerakta a kliens IP-jéhez kapcsolva.
-Kliensen a jelszó mezőből MD5, ezt az MD5-öt meg a random értéket 3DES-sel titkosítottam a jelszó MD5 hash-ét használva kulcsként(!), onSubmit()-ra ennek a kimenete került a jelszó mezőbe (célzott mellékhatásként a böngészős jelszómentés használhatatlan lett, ahogy az elő volt írva).
A szerver megkapta hidden mezőben a random értéket meg ezt a des-elt kimenetet. A randomot megnézte, hogy jó helyről jött-e, és törölte a DB-ből. A következő lépésben az userid-hez tartozó, DB-ben tárolt jelszóhash-ből meg a randomból legenerálta ugyanúgy a des-elt kimenetet, ahogy a kliens - ha a kettő egyezett, akkor sikeres volt a bejelentkezés.
Jelszócsere során a régi hash lett a kulcs, amivel a régihash+random+újhash lett titkosítva és a szerverre felküldve. Ott userid alapján a régi hash rendelkezése állt, kicsomagol, randomot és régi hash-t ellenőriz, majd az új hash-t a db-be beír. Első jelszó meg mobilon ment a usernek.
A lényeg: a jelszó, illetve a hash önmagában sohasem ment át a dróton, és az adatfolyamból értelmes időn belül visszaállítani sem igazán lehetett.