Éppen most alakítok ki egy weboldalt, bár egyelőre nem lesz nyitott a felhasználó regisztráció, mégis szeretném biztonságosan tárolni a jelszavakat.
Kérdésem, hogy az alábbi módszer mennyire biztonságos?
Készítettem egy bash scriptet, ami egy jelszóból legenerál egy hasht, amit elmentek adatbázisba. A következő képpen generálom le:
van egy titkos kulcs (SECRET), amit /dev/urandom-mal generáltam le. Ez fix, sosem változik.
Eztuán jelszavanként készítek egy SALT-ot szintén /dev/urandom segítségével.
Majd a következő paranccsal készül el a hash:
mkpasswd -m sha-512 $PASSWORD$SECRET $SALT
Tehát a password után teszem az állandó kulcsomat. Főleg az a kérdésem, hogy ez így megálja-e a helyét?
Ez a bash a /var/www mappában van, de az apache csak a /var/www/html mappát éri el. Persze a php majd eléri ezt a www mappát. Szóval úgymond nincs kint a titkos kulcs a weben…
Persze azt is tudom, hogy ha a hálózaton lenne külön egy authentikáló gép, ami nem érhető el az internet felől, akkor úgy biztonságosabban lenne tárolva ez a secret.
A hash előállító algoritmus meg azért nem php, mert nem biztos, hogy a backend véglegesen php marad vagy sem. És így kell egy olyan megoldás, ami általánosan működik. Python alapból nincs a szerveren és nem is tennék emiatt rá.
Kicsit off kicsit nem, de ha mar adatok tarolasarol van szo, nem tudom tarolsz-e majd szemelyes adatokat, ha igen akkor majustol GDPR :) Ami pont a netre kikerult db-kbol szarmazo adatokkal valo visszaeles miatt fontos.
Néztem a PBKDF2-t, a bcrypt és scrypt-et is. Egyikkel sem sikerült valamiért bashben megoldani a feladatot. Ha pythont telepítettem volna, akkor működött volna az scrypt. Az ubuntu szerverre a bscryptet felrakva meg azt írta, hogy 2002-es a kód. :) Vagy az nem számít vagy rosszat tettem fel? :)
Egyébként alapból bscrypttel szerettem volna megvalósítani.
Szerencsére személyes adatot nem akarok tárolni az adatbázisban.
Amúgy mi ez a GDPR? Mármint nagyjából sejtem, de úgy általánosságban csak annyi, hogy személyes adatokat biztonságosan kell tárolni?
@FooLman amúgy köszi a linket, lesz mit olvasnom még.
Lenyegeben a szemelyes adatok vedelmerol szolo eu szabalyozas. Pl kerhetem a bankot, hogy a naluk tarolt szemelyes adataimat adjak at a masik banknak ha bankot valtok, vagy kerhetem azt is h toroljek el teljesen. Persze egyelore nem tudni, hogy ezt mennyire fogjak szigoruan venni, de eleg nagy a maximalisan kiszabott buntetes ha valaki nem tesz ennek eleget. Sot igazabol ha ceget valtasz ott is mondhatod h toroljenek rolad minden szemelyes adatot.
Nekem még a backend projektem php-ban van. De pont azért nem akartam php-ban megoldani ezeket, mert ha egyszer váltok valami másra, akkor ez ne legyen gond. És én is gondolkodtam a nodejs-ben, de annyira sokminden meg van írva php-ban, hogy elég nagy hátránnyal indulnék. Ettől függetlenül lehet elkezdek majd valamikor áttérni php-ról.
Még egyébként a swiftet szeretném kipróbálni backendre. Azzal csak az a baj, hogy egyelőre csak ubuntu támogatott. Ha áttérek másik rendszerre valaha, akkor meg megint buktam a backendet. Bár az ubunturól váltás sem fenyeget, mert az elérhető amazonos rendszereknél a suse lenne még, amit használnék (munkahelyemen azt használunk), de az meg már fizetős… :)
En nem foglalkoznek ilyen “mi lenne ha majd egyszer” kerdesekkel. Ird meg PHP-ban, de hasznalj valami altalanos algoritmust (pl PBKDF2.) aztan ha attersz valamire, akkor ott majdnem biztos, hogy lesz implementacio. (kiveve, ha valami nagyon egzotikus nyelvet valasztasz, de ott lesz mas bajod is…)
Következő kérdésem a témában:
A szóban forgó weboldal könyv írással és olvasással kapcsolatos. Az adatbázis röviden: Szerző, Könyv, Fejezet táblákból állna. A kérdésem az lenne, hogy mennyire ajánlott vagy nem ajánlott NoSQL adatbázis erre?
Ugyanis most szemezgetek az Amazon DynamoDB szolgáltatással. Csak oda kicsit más logika kell, mint a relációs adatbázisokhoz. Terveim szerint egy éven belül 20e fejezet bejegyzés lenne. És ennek főleg az olvasás része lenne ami erőforrás igényesebb. Ajánlott-e erre DynamoDB? Mik lennének a hátrányok vagy előnyök mondjuk MySQL-lel szemben?
Persze az egyik nyilvánvaló előnye, hogy az egyetlen EC2 webszervert nem terhelném már eleinte sem az adatbázissal. Ugyanakkor relációs adatbázist is lehet futtatni külön Instance-ként, persze azt már rögtön havi díjjal, míg a DynamoDB nagyon sokáig nem kerülne költségbe. Viszont utólag kontrollálhatóbb a költség a külön adatbázis Instance-nak. Szóval nagy dilemmában vagyok, hogy egyáltalán érdemes-e elindulni a DynamoDB irányában.
Ez a cikk már nem konkrét program írásról szól, hanem hogy egy fejlesztő hogyan tudott ellopni több ezer érzékeny infót: bankkártyaadatok és jelszavak. Még csak az első bekezdésben vagyok túl, de az is rettentően durva. Eredmény: csak a magad által írt kódban bízz!!! (Természetesen).
