MD5 -> SSHA512

Security-all

Sziasztok!

Egy régi pam auth-os mail szerverről kéne átmigrálni a usereket, egy új gépre.
Lehetséges az MD5 jelszavakat SSHA512-re alakítani?
Gugli nem igazán adott támpontot.

Köszönöm!

  • 7988 megtekintés

( andrej_ v | 2016. 01. 21., cs – 10:34 )

Kotelezo jelszovaltas. Ha a regi jelszavak maradnak csak ujabb kodolassal attol nem lesz neked jobb.

( uid_20470 | 2016. 01. 21., cs – 10:35 )

Nem lehetseges, az md5 eleve egy hash, nyilvan nem tudod visszaalakitani az eredeti tartalomra, es abbol sha-t csinalni.

A legjobb megoldas az lehet, ha a migracio utani elso authentikacioig engeded az md5-t, es annal az authentikacional pedig eltarolod az uj hasht. amikor minden user megvan, akkor letiltod az md5 reszt, es orulsz.

Persze javitsanak ki nalam okosabak, ha tevednek.

+1. a hashek alapvető tulajdonsága, hogy még ha képes vagy is preimaget készíteni, az nagyon nagy valószínűséggel több lehetséges preimageből lesz egy. ha az összes ilyen preimaget átalakítod egy másik hash-re, akkor nagyon nagy valószínűséggel mindegyik preimage-hez különböző hashet fogsz kapni. a gyakorlatban ez azt jelenti, hogy nem lehetsz biztos benne, hogy két lehetséges string közül melyik volt az user valódi jelszava ergo a második hash elkészítésével döntést hozol, hogy mi lehetett a múltban a jelszó (tudom, ez elég idióta megfogalmazás).

ebbe természetesen belezavar a saltolás, ugyanis a preimagek közül elegendő csak azokkal foglalkozni, amelyeknél az előre definiált salt szerepel a preimage-ben, de a topicnyitó valószínűleg gyakorlati megoldást akar, nem pedig elméleti értekezést.

btw nagy bajban lennénk, ha feasible módon md5-öt ily módon át lehetne alakítani sha512-re. pár év, és ez lehetséges lesz, úgyhogy ideje kidobni az md5-öt ahonnan csak lehet.

( uid_15480 v | 2016. 01. 22., p – 09:58 )

Ez így nem lesz jó. Az MD5 nem nyerhető vissza. Az egyetlen normális megoldás ha a régi jelszavakat kukázod, majd kötelező jelszóváltást iktatsz be.

Üdv. bnv

Ha az a probléma, hogy a gyenge jelszóhashről erősre akar váltani, akkor bármilyen plaintextes próbálkozás nekem minimum érdekesnek tűnik. Hogy ha már jelenleg erősnek számító jelszó hasht akar, akkor már a régi jelszavakat felejtse el, mert annyira már nem megbízhatóak.

igen. feljebb is elhangzott, hogy kozvetlen md5 -> akarmi konverzio nem letezik. attol meg hogy md5-ben van tarolva a jelszo azzal is azonosithat a kiszolgalo (dovecot-ban csinaltam ilyet), aztan majd konvertal igy vagy ugy. lasd cyberbird hozzaszolasa feljebb.
vagy: uj jelszo mindenkinek, valamint annak minden problemaja. attol is fugg persze, hogy hany hozzaferesrol van szo. mondjuk 100+ eseteben mar erdekes lejatszani egy nullarol uj jelszot cimu dolgot.

( Proci85 v | 2016. 01. 22., p – 11:03 )

Ha courier, van olyan lehetőség a configban, amit ha bekapcsolsz, plain text beírja a logba a csatlakozáshoz használt user nevet és jelszót!
Nyílván a harci művelet után opció off, log törlés.

( hokuszpk | 2016. 01. 23., szo – 19:35 )

ha az md5 hash megvan, a hashcatot egy jobb szotaral, raereszted.
ezutan fogsz egy -- vagy tobb -- eros videokartyat + ocl/cuda hashcat, es nekiallsz megtorni a maradekot. pop3 sniffeles is sokat segithet.
igy rovid idon belul a jelszavak ~75%-a meglesz.
a tobbi felhasznalot ertesited, hogy jelszot kell valtani.

eljatszottam ezt eloszor kb. 1200 userrel.

felhasznalok harmada figyelmen kivul hagyta az ertesitot, harmada nem ertette mit akarunk, - csuklottam surun, mert usereken tul a még a supportos is anyazott, hogy mennyi telefonja lett hirtelen. - harmada vette az akadalyt.
pop3/imap eseten max akkor tudod kenyszeriteni a jelszovaltast, ha mindenki webmailt hasznal ; a regi auth mod letiltasanal megint a support szivott, user ugye csak azt latja, hogy a kliens nem tud belepni.

masodjara mar amit lehetett megtortem, joval kevesebb telefon/reklamacio is erkezett, es gyorsabban le is zartuk az egesz tortenetet.

( muszi v | 2016. 01. 25., h – 16:19 )

Nem volt tul sok idom foglalkozni vele, de ugy erzem, hogy a kovetkezo megoldas mukodhetne: lehetne irni egy PAM modult, ami az 

auth

szakaszban elmentene maganak a juzer altal megadott, plaintext jelszot (

pam_set_item()

), majd a 

password

szakaszban eloszedne es atadna a 

pam_unix.so

-nak. Valahogy igy: 

auth            optional        pam_save_password.so
auth            required        pam_unix.so

password        optional        pam_save_password.so
password        required        pam_unix.so shadow sha512 use_authtok

Amelyik juzer jelszavat meg akarod valtoztatni, annak beallitod, hogy lejart a jelszava, cserelnie kell (

chage

). Az auth szakaszban a pam_save_password elmenti a jelszot, a pam_unix latja, hogy jo ugyan a jelszo, de nemsokara lejar, meg kell valtoztatni, visszaad egy PAM_NEW_AUTHTOK_REQD hibakodot, es innentol bizonytalan a dolog: ilyenkor a program kotelessege meghivni a 

pam_chauthtok()

fuggvenyt, de kerdes, hogy egy levelezoprogram foglalkozik-e vele. Ha igen, akkor a password szakaszban a pam_save_password eloszedi az elmentett jelszot, a pam_unix pedig nem kerdez semmit, hanem beallitja azt a jelszot, amit az elozo modultol kapott.

Engem is erdekel a dolog, szerdan kiprobalom :-)

Nem igazan ertem, hogy mit szeretnel mondani.

Az volt a feladat, hogy az MD5 hash-t csereljuk le SHA512-re. Ezt ugy tervezem elerni, hogy amikor a PAM modulom megkapja a plaintext jelszot, csinaltat egy "jelszovaltast" a pam_unix modullal ugy, hogy a regi meg az uj jelszo ugyanaz. Mivel azonban a pam_unix jelszovaltaskor az uj jelszot mar SHA512-vel kodolva fogja tarolni, elertunk, amit szerettunk volna. Szerintem meg mindig egyszerubb a klienstol megkapni a plaintext jelszot, mint raszabaditani egy jelszotorot a jelszofile-ra.

Technikailag persze hogy lehetséges, de totál értelmetlennek tűnik nekem.

Adott egy csomagnyi, mára már nembiztonságos, hashel tárolt jelszó. Ha bármikor kikerültek a hash-ek, akkor a jelszavak már visszafejthetőek és hiába lesz belőlük akár SHA1024 vagy bármi. Pláne egy ilyen "konverziós" folyamat, ami igazából egy debug log alapján lementi valahova a cleartext jelszavakat, majd szép új hashben tárolja még borzasztóbban hangzik. Ráadásul az átállítási folyamat is rögtön magában foglalja a jelszavak kikerülésének lehetőségét és onnantól tetszőleges hash értelmetlen.

Adott egy csomagnyi, mára már nembiztonságos, hashel tárolt jelszó. Ha bármikor kikerültek a hash-ek, akkor a jelszavak már visszafejthetőek és hiába lesz belőlük akár SHA1024 vagy bármi.

Egyetertek, de ez legyen az OP problemaja :-)

Pláne egy ilyen "konverziós" folyamat, ami igazából egy debug log alapján lementi valahova a cleartext jelszavakat, majd szép új hashben tárolja még borzasztóbban hangzik. Ráadásul az átállítási folyamat is rögtön magában foglalja a jelszavak kikerülésének lehetőségét és onnantól tetszőleges hash értelmetlen.

Nem erted a mukodest: nem debug log alapjan talalja ki a jelszot (azt valaki mas javasolta), hanem miutan a pam_unix lellenorizte, hogy jo-e a jelszo, egy plusz modul szepen elmenti maganak a memoriaba (amit csak ez a session lathat). Mielott a jelszocsere fazisban a pam_unix kerne a regi es az uj jelszavakat, szepen beallitja a megfelelo valtozokat (PAM_OLDAUTHTOK es PAM_AUTHTOK), igy a pam_unix nem kerdez semmit, hanem beallitja az uj jelszot - ezuttal mar SHA512-vel kodolva.

Reszlet a PAM konfig file-bol: 

# Standard Unix authentication
auth		required	pam_unix.so nullok_secure

# Save PAM_AUTHTOK
auth		optional	pam_rehash.so


# Set PAM_OLDAUTHTOK and PAM_AUTHTOK
password	optional	pam_rehash.so

# Create shadow-based, MD5-encrypted passwords
password	required	pam_unix.so shadow sha512 use_first_pass use_authtok

Nálam ez is debugnak minősül, mert bőven a normális működés felett van. Menetközben pedig ott lesz a memóriában. :) Az tény, hogy jó eséllyel csak specifikusan erre készült lehallgatóval lehetne elkapni, de ha nem változik érdemben a jelszó, akkor is fölöslegesnek érzem a konverziót.

"Ráadásul az átállítási folyamat is rögtön magában foglalja a jelszavak kikerülésének lehetőségét"

Úgy látom nagy a para, de valahogy nem érzem át. Azért lehet ezt okosan csinálni. Saját rendszer? Netán a log egy távoli, akár belső hálós logszerveren van? Törlöd utána? 1-2 napig lesz így? Akkor?

Hány helyen is találkozunk sokak által kedvelt i-mscp (link) felülettel? Nézte már valaki, hogy plaintextben vannak a jelszavak a mail_user táblában? Hány cég is használ ilyet?

Ezek után a fenti 2 lehetséges, pár napos megoldás számomra nagyon eltörpül biztonsági kérdésben. Főleg, hogy a kialakítás _ideiglenes_.

ez félmegoldásnak tűnik. jelöljük P-vel az át-hashelendő passwordöt, hash_1() legyen a régi broken hash, hash_2() pedig az új, kívánt hash. salt_1 legyen a régi hashhez illő salt, salt_2 pedig az újhoz, salt_1 != salt_2. + jellel pedig jelöljük a password és a salt valamely kombinációját (jellemzően concatenation). Nem elég megnyugodni azért, mert hash_1(salt_1+P) != hash_2(salt_2+P), ugyanis ha az attacker megszerzi a hash_1(salt_1+P)-t, és egy sikeres preimage attack során jó jelöltet kap P-re, akkor önmagában a hash_2(salt_2+P) biztonsága egyedül a salt_2-n fog alapulni, de mi azt szeretnénk, hogy salt_2+P megismerhetetlensége okozzon neki fejtörést. Ily módon különböző kellene, hogy legyen a két hashben alkalmazott P. Minél nagyobb a különbség, annál több okunk van azt várni, hogy a hash_1(salt_1+P) ismeretében sem tud az attacker előrelépést tenni.

Kivettem az ellenorzest, igy mar mukodik :-) 

[root@test ~]# grep "proba" /etc/shadow
proba:$1$Sw6x8BbD$f9O9ZNKby5xA03q2oMZBF1:16827:0:99999:7:::

[root@test ~]# chage -d 1970-01-01 proba

[root@test ~]# grep "proba" /etc/shadow
proba:$1$Sw6x8BbD$f9O9ZNKby5xA03q2oMZBF1:0:0:99999:7:::

[muszi@test ~]$ login-test-pam
Username: proba
Password:
You are required to change your password immediately (root enforced)
login-test-pam: authenticated as user proba
Last login: Wed Jan 27 15:10:58 CET 2016 on pts/1

[root@test ~]# grep "proba" /etc/shadow
proba:$6$ANw/xd4A$3P.TCQ8zLDsEcg2q28XxN/OYEKim9WHtHoMgcTt0NofZKhDWW.J0fkX9X1a54pQJAWeUrAwd.yNM/8TreR1rK/:16827:0:99999:7:::