ugrás a tartalomhoz

session: felhasználó név+jelszó tárolása, rövid webcímek

jeti · 2006. Dec. 26. (K), 13.09
Sziasztok!

Sessionban, vagy sessionhoz rendelt táblában érdemesebb a jelszó, felhasználó név páros, illetve bejelentkezettség állapotát tárolni?
Hogy oldható meg a munkamenet továbbadása a rövid webcímeknél, ha böngésző letiltotta a süti használatát?
‹ PEAR::Quickform css design sablonok UTF-8 file beolvasás ›
 ■
1

is-is

jano82 · 2006. Dec. 26. (K), 20.27
A bejelentkezettség állapotát igen, esetleg a felhasználónevet is érdemes lehet session-ben tárolni, de a jelszót azt ne. Minek? Ha egyszer már úgyis
bejelentkezett elég, ha csak azt tárolod. A jelszót egyébként sehol ne
tárold. Amit tárolni érdemes az egy ujjlenyomat a jelszórol jól megsózva. :-)

A sütik használatát meg nem érdemes letiltani. Ez picit olyan, mintha
kikapcsolnád a javascript-et vagy a flash plugint.
2

nem használható?

jeti · 2006. Dec. 26. (K), 22.00
Ez az ujjlenyomat dolog jó ötlet! Úgy gondolod, hogy ujjlenyomat = hash(jelszó+fix karakterek)? Mi a különbség hash vagy az md5 függvény között?

Pont ellenkezőleg! Nem én tiltom le a sütiket. Tegyük fel, hogy felhasználó saját maga kapcsolja ki, akkor nem tudom azonosítani és továbbadni az adatait. Ezzel kilőtte a sütiket, én meg a rövid webcímekkel a PHPSESSID továbbadását. :-(
Kipróbáltam itt a weblaboron, letiltottam a sütiket, és meglepődve tapasztaltam, hogy nem tudok belépni. Azt hittem a háttérben valahogy át lehet adni a munkamenet azonosítót. Tehát, akkor rövid webcímes megoldásnál (és kikapcsolt süti támogatásnál) nem használható a munkamenet továbbadása???
3

az md5 egy hash fv

jano82 · 2006. Dec. 27. (Sze), 00.11
Az md5 egy hash függvény. A hash amolyan gyűjtőnév, hasítófüggvénynek vagy
tördelőfüggvénynek is szokták mondani. A lényeg, hogy a bemenetet mindig egy
fix hosszúságú kimenetre képezi le, md5 esetén asszem 128 bit, és úgy, hogy visszafele ne működjön a dolog. Magyarul nem tudod visszafejteni. Vannak
más hash függvények is, pl sha1.

Jelszó "tárolásra" ez önmagában viszont nem jó megoldás. Az igaz, hogy
nem lehet visszafejteni, de nem is akarjuk. Inkább fogunk egy szótárat,
leképezzük az összes elemének a hash kimenetét, és összehasonlítjuk a
"tárolt" jelszó hash-ével, és máris tudjuk mi volt a jelszó.

Ennek a kivédésére egy jó megoldás az úgynevezett sózás. Arról van szó,
hogy a hash amit tárolunk nem a jelszó hash-e, hanem a jelszó hash meg egy
véletlen kiválasztott karaktersorozat hash egy részének konkatenálásból
előállított karaktersorozat.

Íme néhány remek példa:

def set_password(self, raw_password):
        import sha, random
        algo = 'sha1'
        salt = sha.new(str(random.random())).hexdigest()[:5]
        hsh = sha.new(salt+raw_password).hexdigest()
        self.password = '%s$%s$%s' % (algo, salt, hsh)


def check_password(raw_password, enc_password):
    """
    Returns a boolean of whether the raw_password was correct. Handles
    encryption formats behind the scenes.
    """
    algo, salt, hsh = enc_password.split('$')
    if algo == 'md5':
        import md5
        return hsh == md5.new(salt+raw_password).hexdigest()
    elif algo == 'sha1':
        import sha
        return hsh == sha.new(salt+raw_password).hexdigest()
    raise ValueError, "Got unknown password algorithm type in password."
A másik kérdésedre, hogy sütik nélkül, rövid webcímekkel hogyan lehet
átadni a munkamenetet, sajnos nem tudom a választ.

Aki tudja írja meg, mert engem is érdekel!

Én egyébként nem szoktam ezzel foglalkozni, nem készülök fel arra az
esetre, ha a user kikapcsolja a sütiket. legalább is nem így.

jano82
4

Nem akarok kötekedni

krey · 2006. Dec. 27. (Sze), 02.58
De miért írsz Python kódot egy PHP kérdésre/topicba? Ettől a kérdező nem lesz sokkal okosabb szerintem.

üdv. krey
6

én sem akarok kötekedni, de ... :-D

jano82 · 2006. Dec. 27. (Sze), 12.07
Szerintem meg de. Okosabb lesz. Ha bárki bebizonyítja, hogy hülyébb lesz,
elnézést fogok kérni.

Egyébként ez volt kéznél, és nagyon szemléletes, azért ezt írtam.
A python egy nagyon beszédes nyelv, ebből a pár sorból az elvet
simán meg lehet érteni.

Azt meg ne várja senki, hogy kész php kódot illesztek be ide, amit
ctrl-c ctrl-v módszerrel bemásol a saját kódjába és működik.
5

szerintem nem kell sessionba zsúfolni mindent...

virág · 2006. Dec. 27. (Sze), 08.32
Szerintem a munkamenetbe csak a felhasználó azonosítóját (egyedi) kell tárolni, minden mást ez alapján kérsz le akkor amikor szükség van rá (adatbázisból). Ezzel ellenőrizhetsz mindent. Jelszavat, loginnevet stb. én soha nem tárolok "Session"-ban. (Md5 használható ebben az esetben is, de szerintem semmi értelme, mert csak egy szám fog "közlekedni" a lekérések közt, de a plusz biztonság soha nem árthat)

Rövid URL-ben is át lehet adni a Session-t, de semmi értelme, mert akkor már nem nagyon lesz rövid :), +szép és +értelmes az-az URL... Ha ilyet akarsz akkor ne gondolkodj rövid URL-ben. (Viszont elvileg elgondolkodtató, hogy mennyire törékeny is ez az egész webes fejlesztés...de ez csak margóra.)

Letiltósdi játék:
Aki letiltja a JavaScript-et vagy a sütiket az bizonyosan okkal teszi és rendelekezik a megfelelő indokkal, (plusz hozzáértéssel) tehát: számol a következményekkel (pl. nem lesz elérhető számára egy csomó lehetőség, szolgáltatás). Ez legyen az ő gondja. Fel kell tüntetni az oldalon, hogy a letiltásnak mi a hozadéka, +mik a működési feltételek stb.
13

elérhetőség

Hodicska Gergely · 2007. Jan. 29. (H), 03.34
Sok esetben talán belefér, hogy nem törődsz a látogatok valamennyi százalékával, de ha van egy üzleti jellegű szolgáltatásod, akkor ott igenis fontos lehet, hogy úgy csináld meg az oldalt, hogy minden esetben működjön. Pl.egy bank nem engedheti meg magának, hogy ne legyen elérhető pár százalék embernek, de pl. az általunk fejlesztett oldal is úgy működik, hogy minden funkció elérhető COOKIE-t tiltó felhasználók számára, valamint minden AJAX-os funkció diszkrét JS módon van megvalósítva.

Rövid URL-ben is át lehet adni a Session-t, de semmi értelme, mert akkor már nem nagyon lesz rövid :),
Nyugodtan ott figyelhet a szép URL végén a "?sid=akarmi", ráadásul a PHP ezt transzparensen megoldja a számodra, tehát igazából szinte semmibe nem kerül támogatni a COOKIE nélküli látogatókat.

Letiltósdi játék:
Ezt nem nevezném manapság játéknak, főleg, hogy itt a weblaboron is kiderült már párszor, hogy a fejlesztők többsége nincs tisztában mondjuk az XSS támadhatóság súlyosságával ;), így saját önön érdeked is lehet, hogy ne mászkálj szanaszét a neten bekapcsolt JS-sel. De ha rákeresel mondjuk Jeremiah Grossman blogjára, akkor igen csak el fogsz csodálkozni, hogy mi mindent össze lehet sakkozni JS segítségével (amire alap esetben nem is gondolna az ember, pl. egy apró trükk segítségével simán ki tudja JS-ből találni, hogy egy adott oldalon be vagy-e jelentkezve stb.).


Üdv,
Felhő
7

hash a javascriptből

gitamp · 2007. Jan. 26. (P), 20.36
Érdekelne a véleményetek:

Tegyük fel:
Van egy megbízható munkamenetkezelés.
Ennek egyik eleme egy véletlenszerű karaktersorozat. Ezt megkapja a bőngésző is és a sessionban is tárolva van.

Van egy javascript függvény ami:
- bejelentkezéskor a password mezőbe beírt jelszót ezzel a karatkersorozattal eltorzítja valami XOR alapú algoritmussal, majd ennek a hash értékét küldi el a szervernek
- a szerveren a felhasználóhoz tárolt jelszót ugyanígy kezeli majd hasonlítja össze a kapottal

hátránya:
- az adatbázisban tárolnom kell az eredeti jelszót (esetleg visszafejthetően titkosítva)

előnye:
- a vonalból nem csíphető el a jelszó, az elcsípett hash viszont nem használható semmire mert munkamenetfüggő

Mit könnyebb megtörni? A vonalat vagy a szerver adatbázisát?
8

HTTPS

attlad · 2007. Jan. 26. (P), 22.02
Miért nem HTTPS-t használsz?
9

inkább https

Darkfish · 2007. Jan. 26. (P), 22.06
Miután a javascripnek a kódolását is megtudja nézni az aki lehallgatta az adatokat, ezért ennek nem sok értelme van...
10

https nélkül

gitamp · 2007. Jan. 28. (V), 15.27
Ha http - mert gyorsabb, és nincs szükség minden adat titkosítására...

A javascript kódólás megszerzésével szerintem még nem sokra megy - mert a vonalban a hash érték megy, így a jeszó elkódolt változata nem állapítható meg, hisz csak a hash látszik, a jelszó csak a memóriáában létezik.

HTTPS: Volt olyan problémám amikor egy flash elem a https oda-vissza forgatásban megsérült és nem bitről bitre adta vissza, emiatt természetesen nem is működött. (freebsd)

A jelen probléma inkább csak amiatt izgat, hogy egy egyszerű portál rendszeren SE LEHESSEN elcsenni a jelszavakat.

Azóta tovább dolgoztam, így a szerveren sem kell a jelszót tárolni - csak a hash értékét, így valóban senki sem tudja - csak a gazdája.

1. szerver: munkamenet_kulcs [generálás, elküldés]
2. terminál: jelszó [beír]
3. terminál: v1 = MD5(jelszó)
4. terminál: v2 = torzít(v1, munkamenet_kulcs)
5. terminál: v3 = MD5(v2) [elküld]
6. szerver: s1 = MD5(jelszó) [tárolt]
7. szerver: s2 = torzít(s1, munkamenet_kulcs)
8. szerver: s3 = MD5(s2)
9. szerver: összehasonlít v3 == s3 ?
11

Csak jelszó átvitelkor HTTPS

attlad · 2007. Jan. 28. (V), 19.08
Úgy is szokták használni a HTTPS-t hogy csak a bejelentkezés, regisztrálás és jelszó változatás esetén a további kommunikáció meg már a kapott session is alapján sima HTTP-n megy. (Bár szerintem az egész HTTPS-en kéne menjen, ha olyan tartalmak is láthatók amik bejelentkezés nélkül nem.) A te megoldásodban a reg. és a jelszó változtatás továbbra sem biztonságos. De nyilvános gépről bejelentkezésre jónak tűnik (ha a keyloggerek elleni védelem is megoldott).
12

session hijacking

Hodicska Gergely · 2007. Jan. 29. (H), 03.16
Bár szerintem az egész HTTPS-en kéne menjen, ha olyan tartalmak is láthatók amik bejelentkezés nélkül nem.
Pontosan, hisz ha le tudja hallagatni az illető hálózati fogalmát, akkor ha épp be van jelentkezve, akkor bármikor ellophatja annak sessionjét a sessionid ismeretében.


Üdv,
Felhő
14

védelem

KergeKacsa · 2007. Jan. 29. (H), 09.42
Mondjuk session-kezelésbe fél perc beírni, hogy IP-t és mondjuk User Agentet ellenőrizzen, ami azért egy hangyányival megbízhatóbb lesz. :)
(Bár közel sem 100%-os védelem, de nem tudom, hogy látezik-e legalább 99%-os. :))
15

IP-t nem szerencsés

Hodicska Gergely · 2007. Jan. 29. (H), 11.56
fél perc beírni, hogy IP-t ellenőrizzen
Ez nem túl szerencsés, mert vannak olyan szolgáltatók, ahol a felhasználó böngészése közben változik az IP cím.

fél perc beírni, hogy mondjuk User Agentet ellenőrizzen,
Egyrészt szerintem jellemzően céges környezetben van valakinek arra lehetősége, hogy lehalgassa más hálózati forgalmát (feltételezve, hogy egy netszolgáltatót megbízhatónak tekintünk), ahol meg gyakori, hogy a gépek uniformizáltak, nem lesz különbség User Agentben, másrészt pedig ha lehallgatja a vonalat, akkor ott lesz a kezében az UA is, fogja és szpen beállítja a saját böngészőjében.


Üdv,
Felhő
16

süti

gitamp · 2007. Jan. 29. (H), 15.54
Nemrég olvastam a PHP fejlesztés felsőfokon c. könyvet ahol a munkamenetről azt írta, hogy IP és USER_AGENT felejtendő (sok esetben proxi miatt is), és helyette
a sütik használandók: munkamenet azonosító + ellenőrző kód belekódolva esetleg az utolsó mozdulat ideje stb..

A süti szintén elkapható a vonalból, nem?