egyébként meg egy saját konvertálás megvalósítása sem nehéz, én valami ilyesmire gondoltam:
<?php
$abc='aábcdeéfghiíjklmnoóöőpqrstuúüűvwxyz';
// oda
$betu='g';
$szam=strpos($abc,$betu); // 8
// vissza
$szam=5;
$betu=$abc[$szam]; // e
?>
persze ilyenkor problémás lehet ha a számokat nem tömbben, hanem stringben tárolod, mert ki tudja, hogy a "128763284 8734 873383839" 1-gyel vagy 12-vel kezdődik. persze ha eltolod az abc-det úgy, hogy az a betű a 10-es számnak felel meg, akkor az összes betűd kétjegyű számmá konvertálható.
gex
u.i.: a sprintf függvénnyel az egyjegyű számokból is gyorsan tudsz kétjegyűt csinálni és akkor eltolni sem kell az abc-det:
Ha nem szeretnéd, hogy plaintextben menjen át a jelszó, akkor számítasz arra, hogy valaki lehallgatja a kommunikációt. Ha valaki képes erre, akkor a "1024586" ugyanolyan hasznos neki, mint a jeszó, mivel a szerver erre mindig ugyanúgy reagál.
Ha biztosnágos jelszóküldést szeretnél használj https-t, vagy egy challenge-resonse módszert, ahol a szerver küld egy véletlen stringet pl "apacuka", a kliens erre a következőképpen válaszol: crc("jelszo" + "apacuka") - itt a crc egy tetszőleges egyirányú algoritmus. Így a hallagtózó fél tudja majd, hogy mit kell az "apacuka"-ra válaszolni, de annak esélye, hogy a szerver mégegyszer ugyanezt a véletlen stringet generálja a nullához közelít. A string hosszával növekszik a biztosnág.
Most ott tartok, hogy szerveradatbázisba elmentem a user+passwordot, és user oldalon pedig, egy md5-ös kódot a jelszóról, majd amikor megy a szolgáltatás kérés, akkor a user oldalon tárolt md5-öt összehasonlítom a szerveroldalival, ha jó akkor mehet a kérés.
Ez addig jó, hogy a jelszó biztonságban van, viszont magához a szolgáltatáshoz elég maga az md5 és a username.
(A kereső használata után)
Van két weblaboros cikk. Az első:
http://weblabor.hu/cikkek/munkamenetkezeles1
Amúgy bátorítanálak saját beléptetőrendszer írására. Az elv nem bonyolult. Van egy login.php ami megkapja a usernév/jelszó párost. Ha szerepel az adatbázisban (user tábla), akkor létrehozol egy 32 karakter hosszú véletlen stringet, ez lesz a Session ID (sid) - ezt cookie-ként elküldöd. Ugyanekkor a session tánlában létrehozol egy rekordot, amely tartalmazza a sid-et, a megelelő user azonosítóját (hogy kit is takar a session), és a bizonság érdekében egy source mezőt. A source-ra bizonsági szempontból van szükség. Kiszámítása: md5($_SERVER["REMOTE_ADDR"] . "/" . $_SERVER["HTTP_USER_AGENT"]) ennek is egyeznie kell a sid-del együtt, hogy érvényes legyen a session. A session táblában van egy elévülési idő is. Ezt frissíted minden alkalommal, amikor lefut egy php. Ezt ellenőrzöd minden php futásának elején, pl egy függvénnyel: get_current_user() vagy ilyesmi.
md5-nek van köze az eredeti jelszóhoz, abból jön létre (és az eredeti jelszó ismeretében mindig az, 1-1 kvázi egyirányú(egyik irányba jóval nehezebb) megfeleltetés), lényeg hogy az adatbázis megszerzésével, a támadó nem jut hozzá az összes jelszóhoz automatice, csak a kódolt formájukhoz
de az md5-höz jár egy idézet a
Using the MD5 of a user's password is a common approach that is no longer considered particularly safe. Recent discoveries have revealed both weaknesses in the MD5 algorithm , and many MD5 databases minimize the effort required to reverse an MD5. To see an example, visit http://md5.rednoize.com/.
The best protection is to salt the user's password using a string that is unique to your application. For example:
Essential PHP Security
By Chris Shiflett
...............................................
Publisher: O'Reilly
Pub Date: October 2005
ISBN: 0-596-00656-X
re
pontosítás
balaton <-> 06146161 (csak példa)
ord/chr vagy saját konvertálás
egyébként meg egy saját konvertálás megvalósítása sem nehéz, én valami ilyesmire gondoltam:
gex
u.i.: a sprintf függvénnyel az egyjegyű számokból is gyorsan tudsz kétjegyűt csinálni és akkor eltolni sem kell az abc-det:
De miért?
B
környezet
Bővebben?
Ha biztosnágos jelszóküldést szeretnél használj https-t, vagy egy challenge-resonse módszert, ahol a szerver küld egy véletlen stringet pl "apacuka", a kliens erre a következőképpen válaszol: crc("jelszo" + "apacuka") - itt a crc egy tetszőleges egyirányú algoritmus. Így a hallagtózó fél tudja majd, hogy mit kell az "apacuka"-ra válaszolni, de annak esélye, hogy a szerver mégegyszer ugyanezt a véletlen stringet generálja a nullához közelít. A string hosszával növekszik a biztosnág.
B
hogyan működik az "Emlékezzen rám ezen a gépen"?
Ez addig jó, hogy a jelszó biztonságban van, viszont magához a szolgáltatáshoz elég maga az md5 és a username.
Session
Ha felhasználókezelést csinálsz amúgy is session kell hozzá (és itt nem elsősorban a PHP beépített session kezelésére gondolok, csak ha nincs jobb).
Látod, hogy megérte volna a valódi problémával kezdeni a kérdést?
session kezelés
weblabor wiki vagy weblabor kereső
Van két weblaboros cikk. Az első:
http://weblabor.hu/cikkek/munkamenetkezeles1
Amúgy bátorítanálak saját beléptetőrendszer írására. Az elv nem bonyolult. Van egy login.php ami megkapja a usernév/jelszó párost. Ha szerepel az adatbázisban (user tábla), akkor létrehozol egy 32 karakter hosszú véletlen stringet, ez lesz a Session ID (sid) - ezt cookie-ként elküldöd. Ugyanekkor a session tánlában létrehozol egy rekordot, amely tartalmazza a sid-et, a megelelő user azonosítóját (hogy kit is takar a session), és a bizonság érdekében egy source mezőt. A source-ra bizonsági szempontból van szükség. Kiszámítása: md5($_SERVER["REMOTE_ADDR"] . "/" . $_SERVER["HTTP_USER_AGENT"]) ennek is egyeznie kell a sid-del együtt, hogy érvényes legyen a session. A session táblában van egy elévülési idő is. Ezt frissíted minden alkalommal, amikor lefut egy php. Ezt ellenőrzöd minden php futásának elején, pl egy függvénnyel: get_current_user() vagy ilyesmi.
B
miért jobb az md5 mint a random string?
Akkor meg miért olyan népszerű?
re
de az md5-höz jár egy idézet a
The best protection is to salt the user's password using a string that is unique to your application. For example:
<?php
$salt = 'SHIFLETT';
$password_hash = md5($salt . md5($_POST['password'] . $salt));
?>
a 3.2. SQL Injection fejezetéből
Essential PHP Security
By Chris Shiflett
...............................................
Publisher: O'Reilly
Pub Date: October 2005
ISBN: 0-596-00656-X
üdv t