Drupal password hashing megoldás átnézése, konfigurálása

[ghost]

Bele kéne nézni a Drupal-ba, hogy milyen hash function-t használ, és letárgyalni, hogy nekünk az úgy jó e. Nyilván nem gondolok arra, hogy md5 vagy sha1 vagy hasonlók lennének benne, de jobb, ha kézben van tartva, hogy hogyan védi le a rendszer a jelszavakat.

• [x] - #25 - meg kell várni, hogy eldőljön lesz e egyáltalán jelszavas beléptetés -> lesz
• [ ] - #30 - meg kell várni, hogy lesz e argon2 a tárhelyen vagy csak bcrypt

[Endyl]

stackoverflow szerint egyedileg sózott, többszöri SHA512 hashként van tárolva a jelszó. Ha nagyon akarunk, akkor lehet saját megoldást is készíteni. Én személy szerint nem óhajtok ebbe belenyúlni.

[ghost]

Hát engem pont ez aggaszt, hogy valami egyedi megoldással álltak elő.

https://github.com/riverrun/comeonin/wiki/Choosing-the-password-hashing-algorithm Az argon-hoz kell külön lib-et telepíteni, szóval az valszeg nem lesz shared hosting-nál. A bcrypt és a pbkdf2 szerintem elérhető lesz. Engem jobban megnyugtatna, ha ezek közül lenne valamelyik a Drupal egyedi megoldása helyett, amit valszeg amatőrök terveztek, de majd ránézek, hogy pontosan miről van szó.

[Endyl]

Úgy látom tervezik lecserélni amúgy, hogy a beépített php-s password_hash()-t használják. Ott idéznek egy ilyet is:

There's minor disagreement among cryptographers about which password hashing functions will remain strong against hash cracking in the coming years. Of all the acceptable options, PBKDF2 is certainly the weakest one, and SHA512Crypt is very similar to PBKDF2-SHA512 for practical purposes.

Drupal supports a minimum of PHP 5.5, which means they could just as easily migrate to password_hash() and password_verify(), since those functions are guaranteed to exist. If PHP adopts Argon2i in a future version, Drupal will automatically support it as soon as it becomes the default, with no further code changes necessary.

Nekem ebből az jön le, hogy PBKDF2-szerű a módszerük, csak szívnak mindig az algoritmus frissítéssel, mert nem kész megoldást használnak.

---

Update 1: rossz volt az első link.

[ghost]

@Endyl Nekem is ez jött le a sha512-ből meg abból, hogy egyedi. Majd ránézek, tulképp assignolhatom magamhoz, de kelleni fog majd Pepita segítsége, hogy megnézze mi elérhető a Dotroll-nál a bcrypt, pbkdf2, argon2 hármasból. Az utóbbihoz kell külön csomagot telepíteni: https://framework.zend.com/blog/2017-08-17-php72-argon2-hash-password.html abból gondolom, hogy az nem opció, de esetleg rá lehet kérdezni Dotroll-nál, meg arra is, hogy várható e, hogy telepítik.

[ghost]

Felszórtam rá a help wanted-et, hátha megjelenik rá @Pepita73 :-) Addig megkeresem, hogy a bcrypt-hez meg a másikhoz mi kell, vagy hogyan lehet detektálni, hogy megvan e. Tulképp a legegyszerűbb detection, ha kipróbáljuk, hogy működik e, ahelyett, hogy extension listát néznénk meg ilyesmik.

[ghost]

No elvileg password_hash függvény, amivel ezeket használni kell: http://php.net/manual/en/function.password-hash.php a hash tartalmazza a használt algoritmust, a körök számát és a saltot is, úgyhogy egyben van minden info az ellenőrzéshez. Valamivel növelheti a biztonságot, ha szétszórjuk ezt az infot, de most ez lényegtelen.

A bcrypt-et, a PASSWORD_BCRYPT-el lehet elérni, az argont meg az PASSWORD_ARGON2I -vel, szóval érdemes megnézni mindkettőt. Gondolom valami hibát dob majd, ha nincs telepítve az argon a Dotrollnál.

Ennyit kellene megnézni (remélem jól írtam):

$results = [
    'bcrypt' => @password_hash("bla", PASSWORD_BCRYPT),
    'argon2' => @password_hash("bla", PASSWORD_ARGON2I)
];
echo '<pre>'.json_encode($results).'</pre>';

A PBKDF2-t meg szerintem hagyhatjuk.

[ghost]

No közben megtaláltam a kódot:

https://github.com/drupal/drupal/blob/e81312ba480f77becccb29bfb0bc5a7d311aeea5/core/lib/Drupal/Core/Password/PhpassHashedPassword.php

Ha megnézitek sha512-t használ a jelszó hash-elésre, és gyakorlatilag ennyi, még iteráció sincsen. Nem igazán akarok magyarázni, inkább linkelek egy véleményt arról, hogy még 1000 iterációval sem ajánlott: https://security.stackexchange.com/a/96485/46259

Azt kell megérteni hash-eléssel kapcsolatban, hogy az eltérő algotimusok eltérő céllal készülnek.

https://en.wikipedia.org/wiki/SHA-2#Applications

The SHA-2 hash function is implemented in some widely used security applications and protocols, including TLS and SSL, PGP, SSH, S/MIME, and IPsec.

Ha figyelmesen megnézitek, nincs közte, hogy jelszó hash-elésre ajánlott, és ez nem véletlen.

A PBKDF2 key derivation function: https://en.wikipedia.org/wiki/Key_derivation_function#Uses_of_KDFs , az eredeti célja az, hogyha titkosítani akarsz valamit, akkor a jelszóból kulcsot csinál egy drága művelettel, mondjuk 10000x meghívva ciklusban a SHA512-t, vagy ami tetszik. Ugye ha a jelszót használnánk kulcsnak, akkor dictionary attack-el, vagy csak simán random string-eket előállítva elég hamar törnék a titkosítást, mert nem elég hosszú. Ezért kell valami drága művelettel kulccsá alakítani. Ezt a kulcsot azonban nem szokás letárolni, ha nem on the fly készül el, és ha lement a titkosítás vagy kikódolás, akkor törlődik a memóriából. Ezért bár hasonlóak a követelmények a jelszó hash-eléshez ezeknél a key derivation function-öknél, mégsem a legjobb ötlet jelszó hash-elésre használni őket.

Helyette erre a célra kifejlesztett algoritmusokat kell használni, mint bcrypt vagy argon2. Ebben én nem szívesen kötnék semmilyen kompromisszumot...

[ghost]

Hmm igazából amit linkeltem az nem tudom milyen verzióhoz tartozik. Elvileg a 8.5.x-nél is így van, ami a reponkban van, de mindjárt megnézem.

https://github.com/drupal/drupal/blob/8.5.x/core/lib/Drupal/Core/Password/PhpassHashedPassword.php#L217 https://github.com/drupal/drupal/blob/9.x/core/lib/Drupal/Core/Password/PhpassHashedPassword.php#L209

Ja így van, ahogy írtam, még a 9.x-nél sem nyúltak hozzá, bár tervezik. Gondolom a csere annyi lenne, hogy teljesítjük a PasswordInterface -t egy saját osztállyal, aztán beszórjuk a konfigba.

[Endyl]

Én megnéztem a kódot, és iterál, mindig újra hozzáadva a sót; megnézve egy éles adatbázisban lévő hasht, jelenleg 65536 iteráció van beállítva.

Nyilván nem ez a legjobb megoldást; nem véletlenül van rá issuejuk, hogy lecseréljék. Ugyanakkor fentebb idéztem, hogy ez a megoldás gyakorlati szempontból PBKDF-nek megfelelő eredményt ad (de igaz, hogy erről is azt látni, hogy már csak az elmegy kategória; de megintcsak: ezért van az issuejuk).

Ha tényleg a password_hash()-t fogják használni, akkor ha akarunk ezzel vesződni, akkor azzal kellene ideiglenes lecserélnünk, és akkor talán nem kell majd minden felhasználónak kiküldeni egy password reset emailt, amikor bekerül core-ba :D

[ghost]

@Endyl Megnéztem újra, igazad van, tényleg iterál, csak nem néztem bele olyan mélyen. Persze, a password_hash-t akarom használni bcrypt-el, vagy ha van argon2 Dotrollon, akkor azzal. Nem muszáj password resetet csinálni, legalábbis ha megnézed, ők úgy oldották meg, hogy a régi verziós hash-eket is tudja ellenőrizni a kód, aztán gondolom automatikusan generál nekik új hash-t az új algoritmussal, ha helyes volt a jelszó, legalábbis láttam valami rehash vagy valami ilyesmi jellegű függvényt. Csak pár másodpercet szántam rá, nincs kedvem most visszanézni. A kérdés itt már csak az, hogy vajon konfigurálható e mindez. Ha igen, akkor pillanatok alatt cserélhető, és az első release előtt meg kell tenni. Ha nem, akkor talán jobb hagyni a gányolt verziójukat és bízni abban, hogy frissítik idővel. Én legalábbis nem szívesen tákolok rá egyik CMS-re sem, bár megtettem már párszor.

[ghost]

Azt hiszem ebből ki lehet indulni: https://www.drupal.org/docs/8/api/migrate-api/migrate-destination-plugins-examples/migrating-users-advanced-password#crypt Szóval elvileg megoldható egy új modullal, ami password hashing service-t vagy mit tartalmaz. Abba meg nem kell túl sok minden így, hogy nem migrálunk jelszavakat, csak pár nagyon egyszerű függvényt kell majd implementálni.

[Endyl]

Én úgy néztem, hogy van rá API.

[ghost]

@Endyl Ugyanazt találtad, vagy van rá valami egyszerűbb megoldás is?

[Endyl]

Valahol máshol, de ugyanilyen módszernek a leírását láttam én is.

[ghost]

Átneveztem, mert van egy hash salt-os topic, ami transient hash-ekre vonatkozik, gondolom session id-t meg ilyesmiket generálnak vele. Igy talán könnyebben észrevehető, hogy eltérő témákról szólnak.

[Pepita73]

echo password_hash("bla", PASSWORD_BCRYPT);
exit;

Alapból hibát dob, de nem szenvedtem a loggal, mert rájöttem, hogy még 5.3 php van belőve nekem (ott), és abban nincs. :-D Van egy (pontosabban 3) régi-régi oldal rajta, amiatt nem tudom feljebb húzni, azt archiválni kéne, utána lehet kísérletezni.

Alapvetően azt gondolom, hogy nem lenne annyira rossz a Drupal jelenlegi megoldása, ha nem lenne nyílt forrású... Ugyanakkor nem kis munka sajátot írni azzal, hogy majd rehash is kell. Szóval gondold meg, mielőtt bele fogsz. :)

bcrypt 99%, hogy lesz Dotrollnál, argon2 nem tudom. Amint eljutok odáig, hogy php verziót váltsak, látni fogom. A legtöbb extension pipálható, hogy akarod vagy nem.

[Pepita73]

Egy pillanatra váltottam php verziót, itt az info kimenet:

phpinfo.zip

[Pepita73]

Másik, 7.0-ás környezetben:

{"bcrypt":"$2y$10$Af2rJN7\/6xAD\/AHXgGjrGeRKOisjeeeFikxwok1kCXvzeLVxLO1Vm","argon2":null}

Aztán rájöttem, hogy ha nincs az argon2, akkor a konstans sincs, tehát elég egy

        if (defined('PASSWORD_ARGON2I')) {
            // argon2
        } elseif (defined('PASSWORD_BCRYPT')) {
            // bcrypt
        } else {
            // gebasz van
        }

feltétel. Mondjuk pw hash-t nyilván egyetlen algoritmussal szeretnénk gyártani. :)

[Endyl]

Alapvetően azt gondolom, hogy nem lenne annyira rossz a Drupal jelenlegi megoldása, ha nem lenne nyílt forrású...

Nem a forrás nyíltsága/zártsága számít, hanem hogy milyen gyorsan lehet bruteforce-olni egy-egy ilyen hash-t (azaz meddig tart 65536 SHA512-t kiszámolni). Gondolom azért nem ajánlatos már ilyen PBKDF-szerű megoldást használni (azt leszámítva, hogy nem pw hashnek szánták), mert egyre gyorsabb módszerek vannak a számolására. Szóval ha ez még elég lassú, és az is marad, amíg váltanak a drupalnál, akkor kár ezzel bajlódni. Egyébként el lehet gondolkodni az alternatívákon.

[ghost]

@Endyl Ezen kívül még collision-re szoktak játszani. Szóval az is számít valamennyit, hogy mennyire hosszú az output-ja, és mennyire gyakran ismétlődik, nem csak az, hogy mennyire álltak rá brute force-olására hardverrel.

[ghost]

@Pepita73 Irok a Dotroll-nak, megkérdem őket, de elvileg a felajánlott tárhely még mindig él az alapján, amit weblaboron írtak. Már nem emlékszem ki ajánlotta fel.

[Pepita73]

@inf3rno Dávid ajánlotta, de ha jól emlékszem ftp és db hozzáférés nélkül, gondolom ő tervezte kézzel ezeket karbantartani.

[Pepita73]

Meg van: http://weblabor.hu/forumok/temak/137651#comment-122518

6. Valószínűleg a Drupal kódjához és az adatbázishoz nem fogok tudni direkt hozzáférést adni

[ghost]

@Pepita73 Akkor az max úgy mehetne, ha ő lenne a build felelősünk. Viszont akkor ha ő kiesik, nincs második ember, aki tudja a jelszót... Jobb lenne az ilyen helyzeteket elkerülni.

[ghost]

@Pepita73

Ugyanakkor nem kis munka sajátot írni azzal, hogy majd rehash is kell. Szóval gondold meg, mielőtt bele fogsz. :)

Elvileg a Drupal is átáll idővel argon2-re. Szóval ha van olyan dotroll-nál, akkor pár sort kell csak írni, és ha a Drupal is vált, akkor ki lehet törölni azt a pár sort. Ha nincs, akkor bcrypt lesz az alternatíva, ahhoz viszont már kelleni fog majd rehash, ha úgy döntünk, hogy átállunk argon2-re, amikor kihozza a Drupal a frissítését. Annál már megfontolandóbb meghagyni a mostani Drupal-os összegányolt változatot, és megvárni a frissítést.

[ghost]

Ahogy nézem van erre már kész modul: https://www.drupal.org/project/password_hash Elvileg felülírja a password hashing inc fájlt, szóval lehet, hogy jobban járunk a korábban említett service-es megoldással, mert az nem függ a mappa struktúráktól és hasonlóktól.

[ghost]

Közben megtaláltam, hogy Endyl honnan linkelt: https://paragonie.com/blog/2016/08/on-insecurity-popular-open-source-php-cms-platforms ez egy security-s cikk, és nem igazán van kapcsolatban a Drupal fejlesztőkkel. Belenéztem a Drupal issues-ba: https://www.drupal.org/project/issues?text=password_hash&projects=&status=Open&priorities=All&categories=All Ha megnézitek ez az egész már 5 éve húzódik, és érdemi előrelépés csak annyi történt, hogy létrehoztak egy éve egy sub-issue-t, hogy egyeztessék a nevet a php password függvényeivel, tehát check helyett verify legyen interface-en, de még ezt sem sikerült mergelni, illetve nincsen assign-elve senkihez egyik issue sem. Én nem hiszem, hogy egy éven belül bármi változni fog ezen a téren, szóval jobban járunk, ha használjuk a fentebb linkelt modult miután átnéztük, vagy írunk egy saját password hashing service-t, ami szintén nem egy nagy munka. Tőlem lehet bcrypt is, még az is sokkal jobb, mint bármelyik egyedi amatőr változat.

[Endyl]

Én inkább írnék egy, az API-nak megfelelő modult, minthogy telepítsünk egy olyat, ami felülcsapja a core valamelyik fájlját, aztán sosem tudunk váltani róla. Meg kérdés, hogy az egyáltalán mennyire lenne kompatibilis a composeres telepítéssel.

[ghost]

@Endyl Én is azt támogatom, hogy az extension/module/mittomén api-ját használjuk a Drupal-nak, és arra írjunk valamit, ami megváltoztatja az eredeti viselkedését. A könyvtár struktúra, fájlnevek bármikor változhatnak bejelentés nélkül, aztán törik a kódunk, ha arra alapozunk. Egyelőre szerintem ennek vissza lehet venni a prioritását normal-ra. Elég, ha a következő release branch-be belemegy. Nekem most a test lezárása az elsődleges, de ha fontos, akkor ezt is meg tudom csinálni kb. 1-2 nap alatt, vagy ha valaki átveszi tőlem, aki érti a Drupal működését, akkor még gyorsabban is elkészülhet. Jó lenne milestone-okat létrehozni, hogy hozzá tudjuk adni az issue-kat. Már ha 1 milestone : 1 release model-t követünk.

szerk: Jó lenne lefektetni, hogy mik a milestone-ok, vagy legalább, hogy mi a következő milestone, mert ha a következőnél már fent lesz éles oldal, akkor ennek pl a high priority a jó, hogy később ne kelljen rehash-elni, egyébként meg várhat. Csinálok erre külön issue-t.

[Pepita73]

Így van, ez nem lenne jó helyzet.  Szerintem maradjunk egyelőre dotroll nál. Egyébként sem szeretnék tök ismeretlen szerveren lenni, ahol 0 választási lehetőség van bármilyen config terén. Dotroll nál van php 7.2.x és Apache, .htaccess ben majdnem azt csinálsz, amit akarsz, lehet saját php.ini. Egyedül az esetleges fizetős extension, ami nem elérhető.  Szerintem - de ezt még ellenőrizni kell - minden adott, ami a fasza deploy hoz kell.  Ha nem lesz más issue nekem hétvégére, akkor archiválom, amit kell, és valahogy megoldom, hogy lehessen nálam próbálkozni.  Nem lenne baj, ha ki tudnád személyesen próbálni, hogy mit tud ez a shared hosting.  Mondjuk ehhez valószínűleg egyszerre kéne online legyünk,hogy ne jelszót kelljen átadn, hanem pl képernyőt. B verzió a kipróbálásra, ha dotroll ad még 1-2 hétre próba tárhelyet, de akkor vmi domain ügy is van, hogy csak az övék lehet. Nem tudom, hogy van - e még ilyen lehetőség, sok éve próbáltam így ki..

Üdvözlettel: Horváth Péter

(Mobilról)

[ghost]

@Pepita73 Igazából az érdekes része talán az lenne, hogy a 7.2-nél mit jelent az, hogy limited support. (Nekem személy szerint még a nodejs-nél is lenne az érdekes. Mert gondolom valami apache mögé teszik cgi mode-ban, ami minden csak nem nodejs filozófia.) Egyelőre megvárom, amíg válaszolnak arra, hogy van e náluk argon2. Utána rákérdek erre is. Kaptam egy ticket-et vagy mit. :-)

szerk:

These features are currently being tested. Our customer service cannot assist you in case of any malfunction and the availability rate does not apply to these features.

The features marked with an asterisk have limited support. Our customer service cannot provide comprehensive assistance in relation to these features, use them at your own risk!

Az 5.6-ot írják stabilnak, a többivel kísérleteznek, szóval ha 7.2 kell, akkor valamennyi rizikót be kell vállalni. A másik kérdés esetleg a backup lehet még, hogy milyen sűrűn csinálják.

Csináljunk erre egy külön tárhely issue-t? Mintha már lett volna ilyen, de lehet rosszul emlékszem.

[ghost]

Csinálok a tárhelynek egy külön issue-t, és belinkelem Dávidnak.