Ulrich Drepper-féle linuxos Unix crypt implementációkra váltott a DragonFly BSD

DragonFly BSD

Matthias Schmidt hívta fel a DragonFly BSD fejlesztők figyelmét egy oss-security szálra. Solar Designer tavaly novemberben jelezte Matthew Dillon-nak, hogy a DragonFly BSD-ben munkába állított crypt-sha256.c, crypt-sha512.c fájlokkal több probléma is van és az alapértelmezett, SHA-256-alapú jelszó hash-ek sokkal könnyebben feltörhetők, mint a régi MD5-alapú hashek. Dillon nem reagált nyilvánosan a figyelmeztetésre. Pár nappal ezelőtt Solar ismét kereste Dillon-t és azt javasolta neki, hogy mielőbb térjenek vissza a FreeBSD-s crypt-md5.c használatára. Mondandóját benchmarkokkal támasztotta alá. Dillon továbbra sem válaszolt. A projekt ahelyett, hogy visszaállt volna a FreeBSD-s MD5-crypt-re, az Ulrich Drepper-féle linuxos Unix crypt implementációkra (crypt-sha256.c, crypt-sha512.c) váltott.

( saxus | 2012. 01. 24., k – 06:05 )

"SHA-256-alapú jelszó hash-ek sokkal könnyebben feltörhetők, mint a régi MD5-alapú hashek"

Lemaradtam valamiről?

----------------
Lvl86 Troll

Semmi fontosról. Rossz (saját) implementációt használtak a hashelésre, jelszó nyújtás és többkörös hashelés nélkül csak simán képeztek egy hasht sózással, amit jóval gyorsabban lehet nyers erővel törni, mint a régi Poul-Henning Kamp-féle, FreeBSD-s MD5-alapú jelszó hashelés, amit még a 60 MHz-es Pentiumokra készített és már akkor 1000 körös hashelést használt. A végeredmény gyakorlatilag többmillió hash/másodperc lett, a FreeBSD-s párszázezer hash/másodperc mellett, azonos hardveren.

A kérdés inkább az, hogy Millon miért nem reagált korábban a megkeresésre. Jelszótörés és hashelés témában Solar Designer véleményét figyelmen kívül hagyni eléggé nagy butaság.

A DragonFly BSD-s SHA-256, SHA-512 crypt _implementációkkal_ volt gond. De hiszen be van linkelve.

http://gitweb.dragonflybsd.org/dragonfly.git/tree/3335347ccfb630d0db97b…

Ami most deprecated-* (deprecated-crypt-sha256.c, deprecated-crypt-sha512.c) volt a rossz, azt cserélték le a drepper féle cuccokra (jelenleg: crypt-sha256.c, crypt-sha512.c)

Ja, és alapértelmezetten SHA-512-re váltottak. A rossz implementációkkal SHA-256 volt a default.

--
trey @ gépház

Na most akkor megegyszer: ezek fuggvenyek, ismert kepletekkel dolgoznak, x bemenetre mindig y kimenetet kell adniuk.

Most ha elrontottak valamit es x bemenetre ez valami teljesen mas y2 kimenetet adott, akkor szimplan nem is lehetne SHA256 fuggvenynek nevezni.

Egyeb esetben meg nem tudom mit valtoztatna _csak_ az SHA256 algoritmus implementaciojanak csereje, ezert kerdeztem, hogy akkor most tulajdonkepp mi van.

----------------
Lvl86 Troll

+1000, ugyanezen merengek en is.

Szerk:
Na mar ertem: semmi koze ennek az SHA-2 hash fuggvenyhez. Csak egy ilyen nevu forrasban taroljak a jelszavak SHA-2 hashelesere szolgalo funkciot. A problema a hash semaban van. Tehat kb olyan mintha: hasznalunk egy brutal hash fuggvenyt, de 3 karakteres jelszavak vannak vagy minden salt egyezik stb..

( Replaced | 2012. 01. 24., k – 11:17 )

ezert volt az egyik AES-t magyarazo cikk elejen, hogy most irdd le, hogy ha most meg is erted hogyan mukodik, igerd meg hogy soha nem fogsz ez alapjan crypto kodot irni... ;)

--
NetBSD - Simplicity is prerequisite for reliability