Kezdőoldal » Számítástechnika » Weblapkészítés » Autentikáció php-vel, milyen...

Autentikáció php-vel, milyen elv alapján?

Figyelt kérdés

sziasztok!


odáig trivi, hogy lekérdezem a DB-ből, hogy a jelszó jó e, de utána kicsit gondban vagyok. nem szeretném minden oldalnál lekérdezni a DB-ből az adatokat, hogy így kíméljem a szervert. az megfelelően biztonságos megoldás, hogy session-be létrehozok egy változót, és amíg ez a változó él, és van értéke, addig hagyom garázdálkodni a felhasználót az oldalon?


szeretnék jogosultsági szinteket is létrehozni, ha a fenti változó egy szám lenne, és pl. ha nagyobb mint 3, akkor beengedném az admin felületre, az járható út? vagy ezeket a session változókat fel lehet törni és módosítani? mert akkor elég könnyű lenne feltörni az oldalt.


biztonságosra kellene megcsinálni, milyen észrevetéeleitek és ötleteitek vannak?


2011. aug. 7. 09:31
1 2
 1/18 anonim ***** válasza:
Ez engem is érdekel. Az biztos, hogy fölösleges minden oldalnak újrahitelesíteni SQL-el. Hiszen akkor vagy beírod a jelszót mindig vagy valahonnan előveszed. A kérdés pedig az, hogy a session elég biztonságos-e. Gondolom.
2011. aug. 7. 09:58
Hasznos számodra ez a válasz?
 2/18 A kérdező kommentje:
jaja.
2011. aug. 7. 10:03
 3/18 anonim ***** válasza:

Bár most elgondolkodtam egy dolgon:

Bejelentkezéskor:

A sessionban generálsz valami hasht az idő függvénynében. MAz IP címet is fellhasználod, meg egy random kódot a generáláshoz, amit az SQL adatbázisba írsz.

Ekkor viszont mindig le kell hívni az adatokat SQL-ből, hogy minden oldal ellenőrizze, hogy helyes-e hash is.

Nem nagyon értek hozzá, csak próbálok ötletet adni.

2011. aug. 7. 10:40
Hasznos számodra ez a válasz?
 4/18 anonim ***** válasza:

na leírom értelmesen:

Bejelentkezéskor SQL -be a userhez lemented, hogy mikor lépett be utoljára, milyen IP címről és egy random pl. 10 jegyű kódot.

Hitelesítéskor a sessionba mented pl. a user nevét, majd generálsz egy hast, a user nevéből, jelszavából, IP címéből, a belépési időből és a random kódból.


Az oldalaid pedig mindig létrehozzák az SQL adatai alapján a sessionbna lévő hasht és ellenőrzik, hogy a sessionban érvényesek-e az adatok.

Bár lehet ez nem túl jó megoldás, nekem tetszik.

2011. aug. 7. 10:48
Hasznos számodra ez a válasz?
 5/18 anonim ***** válasza:

Sőt így jobb:



Bejelentkezéskor SQL -be a userhez lementessz, egy hash-t amit ezekből az adatokból hozol létre:

Mi a neve, Mi a jelszava, Mikor lépett be utoljára, Milyen IP címről és egy random pl. 10 jegyű kódból. Tehát vannak az SQL-ben a user adatai, a hash.

A sessionba csak a hasht mented el, esetleg user neve, ip címe.

Az oldalaid pedig ellenőrzik, hogy a hash azonos-e a userhez tartozó SQL-es hash-el, meg azt, hogy erről az IP-ről vagy-e bejelentkezve.

Azt is meg lehetne csinálni, hogy a Sessionban lév hash minden oldal töltéskor más legyen, de az már baromság vagy nem tudom.

2011. aug. 7. 10:58
Hasznos számodra ez a válasz?
 6/18 A kérdező kommentje:

igen, ez ésszerű megoldás, és láttam is már valahol, csak kérdéses , hogy szükséges e.

ha több ezer felhasználó használja egyszerre az oldalt, akkor nagyon sok lekérdezést generál csak a böngészés. ha az admin felületet külön kezelném, akkor ott megvalósítható lenne, mert kevés az admin, de mivel egy kalap alatt kell kezelni az usereket az adminokkal, így már nem jó a dolog sztem.


egy másik oldalon említették, hogy elég,h a sessionbe tárolom a dolgokat, mert az a kliensből nem igazán lehet szerkeszteni. ez tényleg így van?

2011. aug. 7. 11:04
 7/18 anonim ***** válasza:

A kérdés csak az most, hogy a session lopható-e snifferrel.

Lehet baromságot írtam, de ezeken jó elgondolkodni.

2011. aug. 7. 11:05
Hasznos számodra ez a válasz?
 8/18 zsomkovacs ***** válasza:

Az ezzel a gond, hogy így is minden oldal lekérdezést futtat. De ha a sessionben átküldöd ezeket az adatokat és a hash kódot is, szerintem már az is elég erős.


Példa:

Veszed a felhasználónevet, a titkosított jelszót, az IP-t és a belépési időt. Ezeket stringként egymás után fűzöd. Ezt titkosítod egy erős jelszóval (ezt nem tudhatja a felhasználó!), majd az így kapott stringet hasheled mondjuk SHA1-el. A sessionben küldöd a felhasználónevet, a titkosított jelszót, az IP-t, a belépési időt és a hash kódot. Így a szerver SQL nélkül tud majd ellenőrizni, viszont ha a szerveren beállított jelszót nem ismerik, a hash kódot kb. lehetetlen előállítani.


A jogosultságokhoz:

Jobban jársz, ha UNIX-szerű jogosultságrendszert használsz. Ez a következőképpen néz ki: az egyes jogokat a kettő hatványainak felelteted meg (pl.: 1-olvasás, 2-írás, 4-futtatás...). A felhasználó jogosultsága a jogok összege (olvasás+futtatás: 1+4=5). Ha meg akarod tudni, hogy a felhasználó rendelkezik-e az adott joggal, csak egy bitenkénti és műveletet kell futtatnod az adott jog kódjával. Ez 0-t ad, ha a felhasználó nem rendelkezik a joggal, egyébként egy pozitív számot (pl. az 5 jogosultságú /olvasás+futtatás/ felhasználó írhat-e (2)?

5&2=0 -> nem írhat.

Futtathat-e?

5&4=4 -> futtathat).


Jogosultság hozzáadása: bitenkénti vagy művelet

Jogosultság elvétele: bitenkénti és művelet az adott jogosultság komplementerével.

2011. aug. 7. 11:11
Hasznos számodra ez a válasz?
 9/18 anonim ***** válasza:

Huhh, Ti a nasa.com-ot szerkesztitek? :D


Bocs, de nem kötekedésből: mi a gond a sütikkel?? Miért nem jó a jól bevált megoldás.. cookiekban tárolod a user+pass adatokat, és csókolom.

2011. aug. 7. 11:30
Hasznos számodra ez a válasz?
 10/18 A kérdező kommentje:
azért mert pénz fog folyni az oldalon keresztül, és amit már én is fel tudnék törni, az sztem nem jó ^^
2011. aug. 7. 11:49
1 2

Kapcsolódó kérdések:




Minden jog fenntartva © 2025, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!