Hash szerver vagy kliens oldalon?

Udv!

A legujabb neptunos "botrany" kapcsan kezdtunk el gondolkodni:

- a neptun pocsek, de azert csak hash-ben tarol jelszavakat (ez azota kideult, hogy igy is van)
- ha igy van, es kizarjuk a fake oldalakat, hogyan szerezhette mar meg valaki betoressel a jelszavakat?
- hm... ha szerver oldalon van a hash, akkor ha ott van egy res, hiaba van titkositas, elerhetoek plain text-ben a dolgok

Mint az kiderult, a neptun valoban szerver oldalon intezi el a hash-t.

Ennek kapcsan gondoltam megkerdezni az itteni kozonseget, hogy milyen ervek / ellenervek vannak a kliens / szerver oldali hash-eles mellett/ellen. Ki hogyan csinalna, miert? Feltetelezzuk, hogy a csatorna titkositott.

( hrgy84 | 2009. 02. 24., k – 07:58 )

Titkositott a csatorna vagy sem, szerintem egy olyan dolognal, ahol fontos az utazo adat minel erosebb eltitkolasa, szerintem kliensoldalon jobb hashelni, hiszen az elkuldott hash-bol egyertelmuen nem allithato helyre az elkuldott jelszo. Nyilvan a kliens gepen lehet keylogger vagy akarmi egyeb is, de hat az ellen a szerveroldali hash sem ved.

Ugy altalaba pedig en a szerveroldali hash-t favorizalom, mert azt egyszerubb implementalni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"kliensoldalon jobb hashelni"

Mar csak azert is, mert akkor a jelszo mar senkit sem erdekel, hiszen a szerver a hash-el is beenged - ugyanazzal, ami tarolva van a szerveren.

Nem veletlenul leteznek am azok a bonyolult authentikacios protokollok, mint pl. a kerberos. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Oke, publikus webszerveren kivancsi vagyok, hogy valositasz meg egy kerberos authentikacios rendszert. Itt az volt az elv, hogy a) a vonal titkositott b) az _atutuazo_ adat vedelme kritikus, azaz a lehallgatastol felunk jobban.

Kulonben ha meg a jelszot megszerzik menet kozben, akkor tokmindegy, hol authentikalsz, mert a szerver a jelszoval be fog engedni. A hash-t viszont meg kulon is el lehet alcazni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Oke, publikus webszerveren kivancsi vagyok, hogy valositasz meg egy kerberos authentikacios rendszert."

Mondjuk ezzel.

"Itt az volt az elv, hogy a) a vonal titkositott b) az _atutuazo_ adat vedelme kritikus, azaz a lehallgatastol felunk jobban."

Akkor ez egy hibas elv.

"A hash-t viszont meg kulon is el lehet alcazni."

Micsinalni?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Elnezest, lehet felreertheto voltam. Nem csak a lehallgatasra gondoltam, hanem ugy altalaban melyiknek milyen elonye, hatranya van. Persze ha a kliensgepen feltelepul valami, vagy a user megeszik egy fake oldalt, akkor ez van, az ellen nem sokat lehet tenni, de ezt leszamitva lehet erdekes, hogy milyen rendszer eseteben milyen megoldas javasolt.

( hunludvig v | 2009. 02. 24., k – 10:14 )

Ahogy server hashnel elkuldod a jelszot, ugy kuldod kliens oldalinal a hash-t. Tehat ha a jelszo lekaphato, akkor annak a hashe is. Ha kliens oldalon megy a hasheles, akkor pedig egy preparalt klienssel elkuldheto a megszerzett hash es ugyanott tartasz, csak a jelszavad nem tudja. FIXME

Igen, ez igaz, de mondjuk ez gondolom megkerulheto oly modon, hogy eloszor a szerver mindig kuld valami random szot, amit a jelszohoz kokatenalva csinaljak meg a hash-t mondjuk kliens oldalon. Visszafele pedig elkuldik azt a szot is es a hash-t is. Ha megtortent egy sikeres bejelentkezes, akkor azt a szot eldobja mondjuk.

Igazabol egy kicsit talan az erdekelne, hogy milyen ennek a state of the art modja.

Anno csináltam ilyet: a szerver a login-oldalon elküldött az adott IP-hez letárolt egyszer használatos random értéket, a kliensen ebből, meg a jelszó hash-ből generált egy JS aegy belépési "tokent", amit a kliens felküldött, a random értékkel és az usernévvel együtt. A szerveren a random érték alapján ugyanezt az algoritmust végigcsinálva, majd a két "tokent" összenézve eldőlt, hogy a kliensen a megadott user jelszava lett-e megadva (vagy valami más, aminek a hash-e azonos).

Volt még benne egy-két okosság (Session-sütitől kezdve sms-ben kiküldött első jelszóig, meg trükkös jelszócseréig), de ezeket most már nekem is újra végig kellene agyalnom, mert dokumentáció, netán forráskód nincs róla a kezemben :-(

( eax | 2009. 02. 24., k – 10:25 )

"Ki hogyan csinalna, miert?"

Kliensoldali x509 cert-el, ami smartcard-on tarolodik.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!