Egyszerhasználatos jelszavak BSD-n

Titkosítás, biztonság, privát szféra

Nemrég jelent meg egy podcast a bsdtalk-on, amiben rövid áttekintést adnak az egyszerhasználatos jelszavakról. Ilyen jelszavakat használhatunk olyan esetben, mikor idegen gépről jelentkezünk be, például könyvtárból, vagy akar kiosk-ról. Az alap telepítés részét képezik az összes BSD-ben (FreeBSD, DragonFly OPIE-t, NetBSD, OpenBSD S/Key-t használ). Ezek a jelszavak egy sorozatszám és egy seed alapján generálhatóak.

Engedélyezni őket a szerveren kell:

Net/Open: "skeyinit"
Free/Dfly: "opiepasswd -c"

Ezután a jelszavunkat kell megadnunk, majd egy titkos kódot, ami legjobb, ha egy egész mondat:

> skeyinit
Password:
[Adding replaced]

Enter secret password:
Your password must be at least 10 characters long.
Enter secret password:
Again secret password:

ID replaced skey is otp-md4 99 volu12345
Next login password: WONT TELL YOU THE PASS NOW

Persze nem ez jött ki valójában, de értelmes angol szavak keveréke volt. Ha szeretnénk még néhány jelszót generálni, akkor a következőt kell tegyük:

"skey -n 10 99 volu12345" FreeBSD-n pedig "opiekey -n 10 99 volu12345".

Így kapunk tíz jelszót, amit leírhatunk, hogy szükség esetén hasznát vehessük.

OpenBSD-n név:skey néven kell bejelentkeznünk, NetBSD-n mindig s/key login-t kapunk, de elfogadja a normál jelszavunkat is, FreeBSD-n pedig csak az OPIE bejelentkezést tudjuk ezután használni, de a /etc/opieaccess fájlban megadhatjuk azokat a címeket, ahonnan normál jelszóval is beenged minket.
Ha nem akarjuk leírni a jelszavakat, akkor PDA-n, vagy akár mobiltelefonon is generálhatjuk őket, mikor szükség van rájuk, megfelelő programokkal.

Kipróbálás előtt természetesen érdemes elolvasni az ide vonatkozó kézikönyveket.

( Replaced | 2007. 06. 14., cs – 18:01 )

Annyit tennek hozza, hogy ha valaki tudja, hogy hogyan megy ez mas rendszerek alatt, az ne tartsa magaban, hanem bokje ide. :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

Mintha úgy emlékeznék, hogy http://www.inner.net/opie

apt-get install libpam-opie opie-client opie-server

(egyszer nézegettem, de mintha lehúzták volna, ezért abbafejeztem. De az is lehet, hogy rosszul emlékszem, és csudajó.)

Ja, megvan. Ennek a cikknek a hatására nézegettem még 2003-ban.

--
trey @ gépház

( Elbandi v | 2007. 06. 14., cs – 21:04 )

pdara/mobilra van normalis keygen? mert 1 eve, nagyon buta programok voltak....

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( adarazs | 2007. 06. 14., cs – 21:28 )

Pár hete én is ezt az OPIE-t kezdtem nézegetni, de rájöttem, hogy arra, amire használni akarom, nekem nem jó.

Szerettem volna bizonságosabbá tenni a gépet a kívülről érkező Bruteforce támadásokkal szemben, tehát valami folyamatosan változó jelszót akartam( a rendes jelszón felül). Olyasmit, mint a SecureID, csak egy, a PDA-mon is futó kis program mondaná meg a jelszót.

El is kezdtem fejleszteni, kíváncsi vagyok, hogy mi a véleményetek róla biztonságtechnikai szempontból.

A jelszót egy PAM modul ellenőrzi az SSH oldalon és egy parancssorból futtatható másik program generálja.

A jelszó felépítése: Veszi az aktuális unix epoch időt és hozzárak a végére egy titkos jelszót, majd ezekből generál egy MD5 hash-t. Aztán (az egyelőre OPIE-ból nyúlt) 2048 szavas dictionary-ből generál egy 3x11bit információtartalmú jelszót (3 szó).

A programban be lehet állítani, hogy hány percig legyen érvényes egy jelszó. Jelenleg egyszerre 3 jelszó is érvényes, 3*128 másodpercig (így ha nincsenek teljesen szinkronban a gépeken az órák, még akkor is be lehet lépni).

Röviden ennyi. Szerintetek mik lehetnek a gyengeségei egy ilyen megoldásnak (elméleti szinten)? Nem néztem át az MD5hash-t, tehát nem tudom, hogy gyengítheti-e az az erősségét, hogyha a támadó tudja, hogy hogyan generálom a jelszavakat, csak az utána fűzött titkos kulcsot nem ismeri?

Az az elképzelésem, hogy így ha valaki fel akarja törni a gépet, akkor egy gyorsan változó rövid jelszót kell bruteforce-olnia, vagy egy akármilyen hosszút, amiből az MD5hash-t előállítom.

Van-e olyan lehetőség, hogy sok ideje van, mégis csak egy rövid jelszót kell kitalálnia?

Kíváncsian várom a véleményeket :)

Jó.
1/((2^(3*11))/3), hogy egy próba sikerül, ez azért elég nagy esély .

"Van-e olyan lehetőség, hogy sok ideje van, mégis csak egy rövid jelszót kell kitalálnia?"

Inkább azon gondolkozz, hogy 128 sec -enként hány állandó jelszót probálhat ki.
Előbb utóbb a jelszó lehet az amivel próbálkozik.

Próbáltam belőni pont így. Persze nem lenne nehéz 4 vagy több szavasakat generálni, csak azt már egyre kényelmetlenebb beírni. :)

Ez így majdnem 3 milliárd az 1-hez esély. Nem is emiatt aggódom, hanem a kerülőutak miatt, hogy vannak-e, egyelőre elméletileg.

A megvalósításban biztos lesz bug, bár igyekszem figyelni kódoláskor. Fallback-nek meg ott van az igazi unixos jelszó is SSH-hoz, hála a PAM-nak. :]

Rögtönzött számítás.
3 másodpercenként 1 jelszó próba.
3 jelszó ugye jó.
Egy nap 3600*24=86400 probálkozás.
42 állandó jelszóval probálkozva.

így ~1000 könnyebb mint lottót nyerni.

Ha arra gondolsz, hogy a támadó megmondhatja, hogy lehetőségek felét már kiprobálta -e. Szerintem nem. De tételt nem bizonyítok :)

szerk:

Ha arra gondolunsz, hogy a támadó ismeri bizonyos számú régebbi jelszavadat (idővel együtt), .. hmm, hmm
Ez javítja az esélyeit. Jó defender számára, ha amiröl készütt 33 bittes hash az jóval nagyobb.

de ne ugy szamold, hogy a maximalis lehetosegeket vegig is szamolja egy brute force
mert mennyi az eselye, hogy a legutolso probalt kombinaciora jon ki neki a megfelelo hash?

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

> Szerettem volna bizonságosabbá tenni a gépet a kívülről érkező Bruteforce támadásokkal szemben,

Ha nincs nyitva az ssh port (és nincs elindítva az ssh szerver), akkor az ssh-t nem lehet támadni. Se bruteforce-al, se sehogy.

Az ssh port kinyitására (ssh szerver elindítására) én inkább valamiféle http://en.wikipedia.org/wiki/Port_knocking implementáció után néznék, a PDA-n futó jelszógenerátor helyett. Mert a PDA-t el is lehet veszíteni, vagy egyszerűen csak otthon lehet felejteni, és akkor hogy jelentkezek be?

--
hup.user.js

A port knockingot azért nem akarom alkalmazni, mert külön szoftver kell hozzá és én ezt az SSH lehetőséget arra akarom, hogy akármelyik gépről be tudjak jelentkezni (a PDA segítségével).

Így nem is muszáj teljesen megbíznom az adott gépben. Ha esetleg egy keylogger futna rajta akkor sem végzetes a dolog, mert a jelszavam egy része hamar megváltozik.

Ha elvesztem a PDA-t, akkor tényleg nem tudok bejelentkezni, ez a hátránya a dolognak. De a rajta lévő titkos jelszót is el lehet kódolni egy passphrase-zel, ha nagyon akarom. Jelenleg feltételezem, hogy ha ellopják, akkor nem tudják a unix jelszavam, ha meg megtudják akkor nem lopják el a PDA-m. :)

> én ezt az SSH lehetőséget arra akarom, hogy akármelyik gépről be tudjak jelentkezni

Akkor bekopogtató szoftvernek olyasmit kell választani, ami "akármelyik" gépen rendelkezésre áll. Mint mondjuk egy web böngésző. Pld. egy web böngészővel megnyithatsz a szervereden egy erre a célra kialakított web oldalt, aminek a hatására kinyílik az ssh port (elindul az ssh szerver). Ha meg egy másik web oldalt nézel meg, akkor bezáródik.

Keylogger ellen egyszerűbb számolás is jó lehet, amit fejben is el lehet végezni.

--
hup.user.js

Ez is egy járható út, de én szeretnék igazán hosszú kulcsot használni.

Mivel ez egy közös titok a szerver és a PDA-m között, tehát nem kell megjegyeznem, a támadó pedig a generálási algoritmus ismeretében is csak ott tart, hogy egy nagyon hosszú karaktersort kell kitalálnia ahhoz, hogy mindig tudja a jelszót.

Ha én írnám be, akkor nem lenne elég nagy ez a közös titok és ugyanott tartanék, ahol kezdetben: nem lennék védve a bruteforce ellen.

(Ezek itt elég paranoiás gondolatok, de vegyétek figyelembe, hogy egy biztonsági rendszer tervezésénél ez szükséges is. :)

Nekem egy fix hosszú adat kell egy tetszőleges hosszúból, erre pedig a hash algoritmusok a jók, a blowfish meg nem ilyen, szóval nem az ideális egy ilyen feladatra szerintem.

Gondolkodtam, hogy melyik hash algoritmust használjam, de mivel az md5-ben se találtak olyan hibát, ami az én felhasználásomhoz kapcsolódna (csak mindenféle MD5 ütközésekről olvastam) és kéznél volt egy implementációja C-ben, ezért azt használtam.

Jó, én értem, hogy az MD5-höz vannak ilyen collision generátorok (ezek szerint most már gyorsak is), de ezt inkább arra használják, hogy ha van egy file és annak egy MD5 sumja, akkor csinálhass egy másik file-t, aminek ugyanaz.

Az én esetemben ennek nincs jelentősége. Persze azért megfontolandó egy olyan, aminek nincs jelenleg ismert sebezhetősége, ki tudja, hogy hogyan lehet még felhasználni ezt a hibát. :)

meglehetősen szofisztikálatlan a részemről, de én eccerűen letiltottam a PAM-ot meg mindent, és csak GPG-kulccsal engedek belépést, az meg egyetlen júzeremnek van. máshonnan csak akkor lépek be ha viszem magammal pendrájvon, de ennyire nem szokott égető lenni a dolog.

ssh-agenttel kényelmes.

Ha megfelel az ssh által használt RSA/DSA kulcs is GPG helyett, akkor elég egyszerű beállítani, hogy ne kérjen jelszót, csak kulcsot (/etc/ssh/sshd_config):
PasswordAuthentication no
PubkeyAuthentication yes

A szülő hozzászólásra válaszolva: én nem érezném biztonságosnak, hogy másik gépen használjam a titkos kulcsom. Másolható, és utána már semmi védelem nincs, nem úgy, mint az OPIE-nál vagy az általam felvázolt megoldásban.

félreértesz, csak elméleti lehetőségként vázoltam fel a hurcibálást, ha muszáj lenne.

én inkább a notebookot szoktam magammal vinni, azon meg az asztali gépen van csak a kulcs.

nem mint az alapvető topikra alternatívaként hoztam fel, csak a bruteforce témakörben gondoltam megemlítem.

szerk: "máshonnan csak akkor lépek be ha viszem magammal pendrájvon, de ennyire nem szokott égető lenni a dolog."
magyarul soha, de ez akkor nem jött le.