Új hozzászólás Aktív témák
-
DNReNTi
őstag
válasz tothjozsi96 #16500 üzenetére
A kérdésedben benne a válasz.
UTF8 a fájlod, erre beállítod hogy a böngésző ISO-8859-2 formátumként kezelje.but without you, my life is incomplete, my days are absolutely gray
-
tothjozsi96
addikt
-
MODERÁTOR
válasz tothjozsi96 #16502 üzenetére
Mindenképpen session cookie.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
DNReNTi
őstag
válasz tothjozsi96 #16502 üzenetére
A biztonságos beléptetés valamint főleg a felhasználói adatok biztonságos kezelése elég összetett dolog, írhatnék délig, mire leírom az egésszel kapcsolatban a véleményemet. Mivel az idő az ellenségem, rövidre fogom. Ami már kiderült itt korábban is a felhasználói adatok sütiben tárolása a lehető legrosszabb megoldás, ha ráadásul még a jelszót is sütiben tárolod (ahogy korábban írtad) az pedig egyenesen kötél általi halált ér.
Leírom az én alap megoldásom, aztán majd a többiek kijavítják vagy kiegészítik, szerintem ez egy weboldal esetén megfelelően biztonságos:
A felhasználók az alap adataikon kívül regisztrációkor kapnak egy mondjuk 20 számjegy hosszú unique random számsort, amely adatbázisban a felhasználó táblában van rögzítve. Amikor a felhasználó a felhasználónév és jelszó párossal helyesen belép, akkor a $_SESSION[] változóban eltárolom ezt a random azonosítót. Innentől a böngésző bezárásáig ez alapján azonosítom a felhasználót. A számsor unique, szóval ugyan úgy használhatom erre a célra mint mondjuk az id-t. Ha lehetőséget adsz arra, hogy a felhasználó belépve maradjon, akkor ezt a számsort nyugodtan tárolhatod sütiben is, így amikor a felhasználó újra meglátogatja az oldalt, a süti tartalmát beállítod a session változóba és minden megy tovább ahogy eddig. Kilépéskor a sütit "lejáratod" a sessiont unset()-eled.Miért számsor és nem string?
Mert az SQL lekérdezés gyorsabb számszerű ekvivalenciára mint szöveges egyezésre.Miért jó ez megoldás?
Mert ha még valaki, valahogyan hozzá is jutna, ehhez az azonosítóhoz (pl. a sütiból), abban semmilyen logikai minta nincs, ami alapján a többi felhasználó azonosítója megszerezhető lenne.Hogyan lehet ez még biztonságosabb?
Ennek a level 2 változata, ha random azonosítót minden belépéskor generálod és mented el a felhasználóhoz, ez viszont félmegoldás, mivel ha a felhasználó miközben be van lépve, belép egy másik eszközről, akkor az eredeti munkamentét el fogja veszíteni.Hogyan akadályozható ez meg?
Egyszerűen, level 2 helyett egyből a level 3-mal. Ugyan úgy egyedi azonosítót generálsz belépéskor, de ezt már nem a felhasználó táblában, hanem egy külön a belépéseket kezelő táblában rögzíted. Fontos, itt nem elég csak a random azonosítókat és a felhasználó id-kat tárolni, az egyértelmű azonosítás érdekében környezeti változók mentésére is szükség van. Kilépéskor a tárolt munkamenet célszerű az adatbázisból eldobni, így nem lesz tele szeméttel, továbbá érdemes időközönként háttérfolyamattal takarítani, teszem azt mondjuk a 48 óránál régebbi munkameneteket eldobni.Röviden ennyi.
Aki nem ért egyet pls javítson ki.but without you, my life is incomplete, my days are absolutely gray
-
-
Sk8erPeter
nagyúr
válasz Peter Kiss #16505 üzenetére
Szerintem mindenki jobban jár, ha leírod a megfelelő megközelítést.
Sk8erPeter
-
biker
nagyúr
válasz tothjozsi96 #16502 üzenetére
Most lehet páran nekem ugranak, vagy legalább elindul egy vita, de...
Az md5 NEM alkalmas jelszó titkosítására, mert nem titkosító eljárás. egy kód, ami 32 bit hosszú, akkor is, ha az input "a" vagy épp NULL, és 32 bit akkor is, ha egy 10GB-os image file ellenőrzőkóód generálás a feladat.
Ebből ered, hogy információt nem hordoz, és persze nem is visszafejthető, (de vannak md5/szó pár adatbázisok)
Ellenben kis valószínűséggel, de előfordul hogy két teljesen más karaktersornak ugyanaz lesz az md5 értéke.
A többit rád bízom, mit választaszElektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
DNReNTi
őstag
válasz Peter Kiss #16505 üzenetére
"Az meg nettó hülyeség, hogy ennyire kicsi adat mellett bármit számítana a szám vs. szöveg megkeresése"
Most csak a kedvedért egy 96.675 soros táblán lefuttattam egy-egy selectet:
String-re (felhasználónév) keresve: 125 ms.
Int-re (id) keresve: <0 ms.Egy forgalmas oldalnál szvsz ez igenis számít, napi több tízezer (esetleg még több) lekérés esetén ez nagy különbség. A random szám generálást nálam egy saját metódus oldja meg, ami eredetileg random stringet generál, de beállítható paraméterrel, hogy a string csak 0-9-ig karakterekből álljon, így "számosítható" az eredmény.
but without you, my life is incomplete, my days are absolutely gray
-
disy68
aktív tag
válasz DNReNTi #16504 üzenetére
Amit én használok biztonságos megoldásként az kicsit bővíti az általad írt 3. megoldást (sajnos az eredeti cikket nem találom):
- Van egy "sorozat" token
- Van egy egyszeri tokenMindkét token egy hash érték, amiket úgy generálunk, hogy egyedi értékek legyenek - ne forduljon elő, hogy két felhasználónak azonos értéket adunk. A tokeneket a felhasználó egyedi azonosítójával együtt egy külön tábla tartalmazza - itt tárolhatunk egyéb információkat is a bejelentkezésekhez, pl. ip, user agent, stb.
Amikor a felhasználó bejelentkezik, akkor kap egy-egy tokent. A "sorozat" token nem fog változni a bejelentkezés alatt, viszont az egyszeri token minden lekéréskor változik - ezt természetesen figyelembe kell venni a tervezés során, hiszen minden oldallekérés adatbázisművelettel is párosul, kis felhasználószám esetén nincs jelentősége.
Egy felhasználóhoz több sorozat + egyszeri token rendelhető (egy "sorozat" token egy egyszeri tokennel áll párban), így lehet a felhasználó több kliensen egyszerre bejelentkezve. Bejelentkezéskor a felhasználóhoz tartozó tokenek törlésével/nem törlésével oldhatjuk meg a "nem lépek ki más böngészőből" itt a ph-n is használatos funkciót.
Amennyiben valaki megszerzi a két értéket, akkor addig tud ügyködni a nevünkben, amíg mi nem frissítjük az oldalt -> amikor ellenőrizzük a 2 tokent, akkor a sorozat ugyanaz, de az egyszeri nem, ezért kiléptetjük a felhasználót.
A két tokent és a felhasználó egyedi azonosítóját tárolhatjuk session és/vagy cookie értékként (akár az egészet egy stringként), elsődlegesen a session változót figyelembe véve. Amennyiben nincs session csak cookie, akkor kezelhetjük úgy a felhasználót, hogy nem biztonságosan van bejelentkezve és egyes funkciókat (pl. jelszóváltoztatás) csak a jelszó újbóli megadása után teszünk elérhetővé. Ha a felhasználó bejelöli a "bejelentkezve maradok" pipát, akkor tároljuk az értékeket cookie-val és session-nel, ha nem akkor csak session-nel.
Remélem sikerült érthetően megfogalmaznom a lényeget.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
fordfairlane
veterán
válasz DNReNTi #16508 üzenetére
Van azon a string mezőn index?
Egyébként meg a biztonsági vitához: Szerintem egy kezdő ne akarjon ilyenbe belemenni, elég volna, ha a beépített sessionkezelőt használja. Ez még mindig sokkal jobb opció, mint ahogy eredetileg akarta, hogy majd nekiáll cookieba menteni házibarkács hash-adatokat meg jelszót. Nem is értem, hogy miért erőlteti ezt a dolgot, amikor alapvető dolgokkal nincs tisztában.
[ Szerkesztve ]
x gon' give it to ya
-
DNReNTi
őstag
válasz fordfairlane #16510 üzenetére
Van bizony. Most kipróbáltam olyan mezőn amin nincs, úgy >700ms.
Szerkesztéshez: +1.(#16509) disy68
E má' level 4.but without you, my life is incomplete, my days are absolutely gray
-
disy68
aktív tag
Jelszó tároláshoz érdemes egy biztonságosnak tekintett hash algoritmust használni sóval (ami biztos, hogy az md5 és sha1 elavultnak tekinthető). Nem szabad abban bízni, hogy az általunk használt eljárás nem ismert (security through obscurity).
Természetesen plusz funkcióként használhatunk captcha-t (többszöri próbálkozás ellen), de ez nem mentesít a megfelelő tárolástól.
Ennek azért elég nagy az irodalma érdemes rendesen utánajárni, ha valóban fontos a biztonság (algoritmusok, só, iterációk, ellenőrzés).
Egy jó cikk a témában. Van példakód is pár nyelven.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
honda 1993
senior tag
Üdv.
Hol találok olyan táblázatot, vagy oldalt ahol minden egyes karakter jelentése le van írva?
Mint pl ahogy a (.) - ot úgy hívjuk hogy összefűző operátor, vagy a ("") - be a karakterláncokat írjuk, stb.
Azért kellene, mert elég gyakran elfelejtem hogy mi mit jelent, és jó lenne ha egy helyen meglenne minden.
[ Szerkesztve ]
XD alias IKSZDé
-
DNReNTi
őstag
válasz honda 1993 #16514 üzenetére
but without you, my life is incomplete, my days are absolutely gray
-
Des1gnR
őstag
Sziasztok!
Egy ilyen hibát dob az oldalam:
Please enable cookies.
Error 1001 Ray ID: 17d551354a1b0563
DNS resolution error
What happened?
You've requested a page on a website (uijquery.org) that is on the CloudFlare network. CloudFlare is currently unable to resolve your requested domain (uijquery.org). There are two potential causes of this:
Most likely: if the owner just signed up for CloudFlare it can take a few minutes for the website's information to be distributed to our global network.
Less likely: something is wrong with this site's configuration. Usually this happens when accounts have been signed up with a partner organization (e.g., a hosting provider) and the provider's DNS fails.
CloudFlare Ray ID: 17d551354a1b0563 • Your IP: 195.70.47.141 • Performance & security by CloudFlareTalálkoztatok már vele?
Dell G3 3779 || Samsung S23+ || Samsung Watch 5 Pro || Oculus Quest 2 || Creality Ender 3 V2
-
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy ti milyen hosszúságokat szoktatok beállítani SQL-ben?
Pl.
ID -> INT(10)
Username -> VARCHAR(40)
Email -> Varchar(40)Ezekre lennék kíváncsi, egy régebbi oldalban láttam ezeket, de nem tudom hogy mennyire hasznosak.
Láttam olyan oldalt ahol problémát okozott már az INT(10) is. -
DNReNTi
őstag
válasz tothjozsi96 #16518 üzenetére
"Láttam olyan oldalt ahol problémát okozott már az INT(10) is."
Az 4.2+ milliárd rekord. Milyen oldal lehet az ahol ez problémát okoz? igyelmen kívül hagyva természetesen az interneten belüli interneteket (Google, Facebook, és társaik.)Most remélem nem fogok hülyeséget írni, de: Egyébként az INT esetében a mező méretének definíciója teljesen felesleges, az INT ígyis úgyis 4 byte, azaz 4.2+ milliárd egyedi egész számot tárollhatsz így. A sima INT értéktartománya: -2147483648- tól 2147483648-ig terjed. Ha ID-hoz használod az INT típusú mezőt, akkor célszerű INT UNSIGNED-ként definiálni, így negatív értékek nincsenek, 0-tól 4294967295-ig mehetnek bele az értékek.
Ha ez sem elég, ott a BIGINT, 8 byte-on, UNSIGNED-nak definiálva 0-18446744073709551615 egész szám. Nem tudom elképzelni, hogy ez se lenne elég.
Hogy a többire is válaszoljak:
Teljesen projekt függő. E-mail címeknek én simán VARCHAR(255)-öt adnék. Vannak elég extrém címek. A többi rajtad múlik. Fontos viszont, hogy a beadott stringek hosszúságát ellenőrizd szerver oldalon, ne told bele a max 40 hosszú mezőbe a 120 hosszú stringet, mert így jársz.but without you, my life is incomplete, my days are absolutely gray
-
DNReNTi
őstag
válasz tothjozsi96 #16520 üzenetére
De most ha mondjuk 0.1 másodpercenként van egy üzenőfali bejegyzés, ami lássuk be elég aktív oldal lehet, akkor naponta, 864.000 db bejegyzés keletkezik. Legyen 1 millió, hogy könnyű legyen számolni. Ez az INT-et 4290 nap alatt, azaz majdnem 12 év alatt meríti ki, ilyen extrém használat mellett. Wtf?
but without you, my life is incomplete, my days are absolutely gray
-
peterfihugo
újonc
[link]
A fenti linken található kódsorból valaki mondja már meg hogy mi a hiba .... mert nem tudok rájönni... amint ez a php-t beinclude-olom az admin felületemen, akkor olyan, mintha folyton elkezdené újratöltögetni az oldalt.... és nem bírok rájönni miért... már lehet h fáradt vagyok... -
Zedz
addikt
válasz peterfihugo #16522 üzenetére
Édes istenem, ezt te átlátod? Nem bántásból mondom, de szerintem nagyon gyorsan el kellene kezdened rendszerezni a kódod.
-
wis
tag
válasz peterfihugo #16522 üzenetére
Ezek a részek okoznak átirányítást:
<script>window.location.href='<?=DEVELOP_URL?>/admin/?menu=slider';</script>(#16523) Zedz
Ezt inkább már kukázni kéne -
PumpkinSeed
addikt
válasz peterfihugo #16522 üzenetére
Szvsz ezt a kódot még én se használnám, pedig én kezdő fejjel elég sok hibát szoktam véteni.
De a lényeget megragadva, és nem a kérdésedre válaszolva, szerintem ez már kicsit idejét múlta kódrészlet, mert mysql_query-ket használ, már ebből is látszódik, hogy nem ajánlatos a használata.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #16526 üzenetére
Jól mondod. Ez a kód szerintem az utóbbi idők összes példaként linkelt kódját felülmúlja ocsmányságban. Megkapja a PHP topic Arany Málna díját.
Sk8erPeter
-
tothjozsi96
addikt
Egy olyan kérdésem lenne hogy ti mivel védenétek ki egy robot támadást?
Mondjuk valaki úgy akarja leterhelni az Apache-ot hogy elkezdi a bejelentkezést terhelni, persze random adatokkal és több helyről indít egy robotot.Gondolkodtam kicsit és szerintem egy jó megoldásra jöttem rá.
Az a lényeg hogy lenne egy rejtett input, abban benne lenne egy uniqid() és ez el lenne mentve SESSION-ban, és ezt vizsgálnám a végrehajtó php-ban, és ha nincs érték akkor elutasítanám és nem is jutna el odáig hogy adatbázisból lekérje hogy egyáltalán létezik-e a felhasználó.
Vélemény?[ Szerkesztve ]
-
DNReNTi
őstag
válasz tothjozsi96 #16528 üzenetére
És ez miért is akadályozna meg bárkit abban, hogy szétterhelje az oldalt? A robot is megkapja a uniqid()-t.
but without you, my life is incomplete, my days are absolutely gray
-
Zedz
addikt
válasz tothjozsi96 #16530 üzenetére
Itt nem csak azzal van a baj, hogy 1 fájlt támadnak. Hanem a folyamatos lekérés a szervertől. Pl. ddos támadást ismered?
-
DNReNTi
őstag
válasz tothjozsi96 #16530 üzenetére
Szerintem egyszerűbb megnézni a végrehajtóban, hogy a http request post e. Ha nem az, viszlát.
but without you, my life is incomplete, my days are absolutely gray
-
tothjozsi96
addikt
De a DDos-t inkább szerver felőli oldalról érdemes megközelíteni szerintem.
Mivel ha túl sok az egyidejű lekérdezés, meg túl nagy adatok érkeznek meg mittudjaménmik
Akkor értelemszerűen bann jár érte.(#16532) DNReNTi
Az se rossz elképzelés, de szerintem az uniqid-t nehezebb megszerezni, lehet hogy egy robot képes arra hogy szimulálja a postot.[ Szerkesztve ]
-
wis
tag
válasz tothjozsi96 #16533 üzenetére
Egy robot mindenre képes lehet amire egy böngésző is
-
PumpkinSeed
addikt
válasz tothjozsi96 #16528 üzenetére
Én ezt talán úgy fogalmaznám át, hogy aki egyszer próbálkozott az kap egy ID-t session-ben vagy cookie-ban tárolva és az bizonyos ideig nem csinálhat semmit. Értem ezalatt a regisztrációt. Adsz neki 3 próbálkozási lehetőséget majd ha annyira béna, hogy ezután se tud regelni akkor lehet robot lesz, és ekkor megkínálod 2 perc tiltással, mely minden sikertelen cselekedet után hatványozódik.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Zedz
addikt
válasz tothjozsi96 #16533 üzenetére
De a végrehajtott fájlt is le kell kérni nem? Tehát ott is a szerver válaszolgat...
-
válasz PumpkinSeed #16536 üzenetére
És a sessionben való tárolás már magával hozhat adatbázis-műveletet is.
-
tothjozsi96
addikt
válasz Peter Kiss #16538 üzenetére
Szerintem sokkal jobb megoldás ha külön van egy input és mindenki kap egy uniqid-t.
Mivel ha nem egyezik a session a post-al akkor sose fog tudni belépni. -
Szóval flood ellen úgy lehetne értelmesen védekezni, ha user host address mellé jegyeznénk memóriában az utolsó kérést, és amennyiben ez túl közeli (túl sűrűn kértek adatokat), nem adunk vissza semmit.
-
tothjozsi96
addikt
válasz Peter Kiss #16540 üzenetére
Igen, csak mondjuk az se a legjobb megoldás hogyha a sok logolás lassítja meg a szervert ...
Több ezer felhasználó közül kiakar szúrni az ember 1 felhasználót aki nyomja a ddos-t, hát az úgy elég meredek megoldás.Azért akarom ezeket kivédeni.
Mert egy die() nem fogja leterhelni a szervert.
Azért is kérdeztem hogy szerintetek jó megoldás-e ez a rejtett input?Amúgy azt felesleges szerintem vizsgálni hogy POST-e a bejövő adat, olyant már láttam ddos-olni.
De az uniqid-t ezzel ellentétben nem tudja ellopni elvileg, mivel a <form> nem egy lapon van a feldolgozó résszel. -
válasz tothjozsi96 #16541 üzenetére
Nem kell logolni semmit. In memory intéződik minden, tiltani meg tűzfalból kell hosszútávon.
-
tothjozsi96
addikt
válasz Peter Kiss #16542 üzenetére
Igen, ez igaz.
Főleg hogyha nem a tied a szerver gép hanem mondjuk csak tárhelyet bérelsz ...
Úgy nem igazán fogsz tűzfalon keresztül bannolni senkit.Egyéb:
Szerintetek miben érdemes tárolni a felhasználók jelszavát?
Eddig úgy tároltam hogy md5(sha1($username.$password);Nem tudom hogy lehet biztonságosabb.
Láttam olyan megoldásokat is hogy két külön oszlopba van tárolva egy random érték meg a jelszavad titkosítva és akkor a kettő együtt md5-el ha egyezik akkor belépsz ...Most én ilyesmi féle megoldást nem szeretnék.
Igazából amit tárolni szeretnék az az "username", "hash" ami uniqid lesz és még a "passhash"-t.És nem tudom miben lenne érdemes titkosítani a jelszót.
[ Szerkesztve ]
-
válasz tothjozsi96 #16543 üzenetére
Ez nem titkosítás, hanem hash-elés.
Azzal, hogy ráküldöd az sha1-re még az md5-öt, sikerült csökkentened a lehetséges jelszóvariánsok számát brute force esetén.
Megoldás: PHP Manual > Function Reference > Cryptography Extensions > Password Hashing
(password_compat, ha kellene)
-
tothjozsi96
addikt
válasz Peter Kiss #16544 üzenetére
Váóó.
Elsőre tényleg sokkal jobbnak tűnik mint egy md5(sha1()) kombó.Ez jól néz ki, kérdés hogy miben érdemes tárolni SQL-ben.
Mivel látom ez folyton más értékeket generál, de úgy látom akkor is VALID marad ha akár melyik értéket ellenőrzöm ezzel a password_verify()-vel.Erre érdemes MD5-öt tenni az SQL tároláshoz?
Úgy nézem hogy mindig 60 karakter lesz az értéke ...[ Szerkesztve ]
-
biker
nagyúr
válasz tothjozsi96 #16545 üzenetére
crypt() + salt, vagy password_hash() ?
Elektromos autó töltő berendezések | Mesterséges növényvilágítás | Mai ajánlatunk: www.gerisoft.hu | www.e-autotoltokabel.hu | www.agrar-vilagitas.hu |
-
válasz tothjozsi96 #16545 üzenetére
Elmondom, hogy a dupla hash csak kárt okoz, erre megint ráküldene egy MD5-öt.
@biker
"password_hash() is simple crypt() wrapper"[ Szerkesztve ]
-
tothjozsi96
addikt
válasz Peter Kiss #16547 üzenetére
Akkor úgy tároljam hogy VARCHAR(60)-al?
Akkor nem teszek rá semmit ha úgy biztonságos. -
DNReNTi
őstag
válasz Sk8erPeter #16534 üzenetére
Miután má' leírtam nekem is eszembe jutott.
but without you, my life is incomplete, my days are absolutely gray
-
tothjozsi96
addikt
Itt azt írják hogy max. 60 karakter.
Na most, nekem 63.
Egy egyszerű regisztrációba kellene.
Így írtam bele.
echo password_hash($_POST["password"], PASSWORD_DEFAULT);Alapból így van megadva amúgy:
$password = !empty($_POST["password"]) ? $_POST["password"] : '';Azt hittem hogy valami baja lesz az empty-vel, de nem ...
De ha simán beírom valahova hogy
echo password_hash("valami123", PASSWORD_DEFAULT);
akkor az 60 karakter lesz.
WTF?[ Szerkesztve ]
Új hozzászólás Aktív témák
- Mibe tegyem a megtakarításaimat?
- Ezek a OnePlus 12 és 12R európai árai
- World of Tanks - MMO
- A fociról könnyedén, egy baráti társaságban
- Autós topik
- Skoda, VW, Audi, Seat topik
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Robot fűnyírók
- Autóhifi
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest