ugrás a tartalomhoz

Elflejtett jelszó rendszer létrehozása

Anonymous · 2004. Dec. 16. (Cs), 15.14
Udv Mindenkinek,

olyan kerdesem lenne, milyen modon induljak el egy olyan jelszoemlekezteto rendszer feljeszteseben, amit PHP-vel kellene megoldanom?

Sajnos a HotScripts.com-on és a Google-ban kapott tutorialok eleg gyengek...

vmi jo otlet kellene!

1. Hogyan taroljam el
2. Hogyan tudom visszafejteni
3. Kelloen biztonsagos legyen (jo ez nem konkret, de fontos lehet)

Udv
Sanyi
xo3_delphi##kukac##freemail.hu
 
1

Biztonsag

Hegi · 2004. Dec. 16. (Cs), 15.26
Nos,en azt mondom,hogy a jelszot hash-ben tarold,ne pedig visszafejtheto formaban.

Ha a juzer azt mondja elfelejtette a jelszavat,akkor kuldj neki egy mailt,amiben egy azonositohoz kotod a lenyeget.
xy.php?user=KisPista&azonosito=22m2k4ksm45643mkgktroe


Ja es szerintem celszeru letarolni meg a keres idejet is,es akkor pl 24h utan nem lehet mar ezt az azonositot hasznalni. Persze itt mondjuk azert kerdeses,hogy kiadd e a jelszo megvaltoztatas formot erre a lekeresre,vagy a felhasznalo regisztracioban megadott ugynevezett emlekeztetojet iratod ki vele.Nos en az utobbit javasolnam,ugyanis az email-t el lehet csipni akar,es akkor barki megvaltoztathatja a jelszot.


//Hegi
4

Biztonsag

Anonymous · 2004. Dec. 16. (Cs), 15.56
>> felhasznalo regisztracioban megadott ugynevezett emlekeztetojet >> iratod ki vele.Nos en az utobbit javasolnam,ugyanis az email-t el >> lehet csipni akar,es akkor barki megvaltoztathatja a jelszot.

Ez lesz a jo megoldas az emlekezteto helyett a cegkodot kell neki megadni es megvaltoztathatja a jelszavat

Koszi ezzel mar tovabblephetetk
2

Szerintem

kgyt · 2004. Dec. 16. (Cs), 15.29
Nem fontos feltétlenül a jelszót megmondanod a juzernek.
Jó megoldás lehet, ha az e-mail címére kap egy linket, amellyel új jelszót generálhat.
Ahhoz, hogy ne küldjenek neki napi száz jelszógeneráló e-mailt a haverjai, be lehet állítani napi limitet és lehet egy kérdést feltenni a létező adataiból.
Pl. Mikor születtél? - ha egyezik az adataival, akkor kap csak levelet a linkkel...

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
6

e-mailes

sajt · 2004. Dec. 18. (Szo), 12.06
Ennél az e-mailes dolgonál lehet nézni mondjuk az ip címét, nehogy valaki lelopja az e-mailt. vagy a következő dolog. Azt kell kérni, hogy az elküldött link-et ugyanabba az ablakba masolja be, mint ahol eppen van. Akkor elvileg ugyanabban a session-ben marad, tehat biztos, hogy o volt, aki a linket kerte. Persze ezt is meg lehet bundazni, ugy, hogy mas keri le a jelszot, es aztan kapja el a levelet.
14

ip

kgyt · 2004. Dec. 21. (K), 11.47
A jópofa haverokkal legtöbb esetben egy ip-n csücsül a felhasználó (pl. otthoni adsl megosztás, lan party, netcaffee stb.), azok meg sniffelik a helyi hálót és lelopják a jelszavát, szessönjét, mindenét...
Sőt! A legelterjedtebb ,,módszer'', hogy beíráskor lelesik a jelszavát...
És végül a haverok megváltoztatják a nemét, meg az érdeklődési köreit... ;-)

Szóval azellen nemvéd.

--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
3

Elflejtett jelszó rendszer létrehozása

Anonymous · 2004. Dec. 16. (Cs), 15.46
Koszi a valaszokat,

annyit meg hozza tennek:
1. hogy ket azonosito(azonosito, cegkod) van es egy jelszo, amivel apellalhatok, ez a hash-es megoldasra gondoltam magam is, csak avval nem lehet visszafejteni az jelszo-t ha elfelejti (hetvegen is kell mukodnie :-) , nem telefonalhat egy uj jelszoert)

2. header('WWW-Authenticate: Basic realm="Private"'); használok a bejelentkezesre MySQL adatbazissal osszekotve, de kell majd egy kulon oldal, ahol ezeket az adminisztracios dolgokat elvegezhetik (elfelejtette a jelszot, uj jelszot akar stb.)

Közben gondolkodtam, lehet hogy felboritom ezt az egeszet es mas megoldas fele nezek, mert ha 2 azonosito van...

Udv
Sanyi
5

Adminisztracios felulet

Hegi · 2004. Dec. 16. (Cs), 16.04
Nos igen,ez mindenkeppen kell.De en arra gondoltam hogy elkuldod az emailt,rakattint a linkre,ahol jon a kerdes,es ha tudja ra a valaszt,akkor bejon egy form ahol meg kell adni az uj jelszavat.Es ekkor belepteted az uj jelszoval,amit felulirsz.
Ja,es a 'cegkod' ha jol ertem statikus,belepesnel kapja,mint a juzernevet,en szerintem celszeru meg egy sajat azonositot is generalni ami random,hogy ne lehessen olyan egyszeruen belepni arra az oldalra.

kgyt javasolta a napi limitet,igen ez jo otlet,hiszen ezzel megakadalyozhatod a spam-eket,szerintem naponta 1 kell,ha mar ugy is van benne 24oras idokorlat.

//Hegi
7

md5(id+CheckSum)

Dualon · 2004. Dec. 18. (Szo), 13.17
Nagyobb szabadságot akartam a felhasználóknak, úgyhogy nálam megváltoztathatják az azonosítójuk, a jelszavuk, de akár a nevüket is (vagyis a név és az azonosító is külön megy - miért korlátozzam őket túlzottan névválasztás terén?).
Ennek megfelelően egy id-jük, illetve egy ellenőrzési összegük van, amely mindig fix, utóbbi egyik része a felhasználóra jellemző, a másik egy random számból áll össze (regisztrációkor). A kettőből csinálok egy stringet, amit md5-tel hash-elek, innentől pedig Hegi megoldását tartom a legelőnyösebbnek (de nem jelszóemlékeztetőt kérek be, azt általában elfelejtik, hanem születési évet; ez kevésbé biztonságos, de célravezetőbb).
Szvsz ez is egy elég jól járható út. (Egyébként mit gondoltok róla? Az egész mondjuk ott esik kútba, hogy nem használhatom a mail() függvényt. :/)
8

Hat igen

Hegi · 2004. Dec. 18. (Szo), 15.05
Hat oszinten megmondom annak a random azonositonak nem latom ertelmet,mert ugye azt a felhasznalo nem adja meg,nem is tudja,ezert innentol szvsz lehetne akarmi,mivel az nem a felhasznalotol szarmazik.Mer ugye mas lenne a helyzet ha az IDvel jaccanal a masik szamnal es azt raknad random helyett.

Amugy jelszoemlekeztetore mondjuk ha az emberunk egy ra jellemzo dolgot ad meg,pl "Hogy hivjak a macskajat?" akkor arra tudja a valaszt azt nem felejti el.

De igen a mail() nelkul elegge nehez a dolog,ott kiesik az a biztonsag hogy e-mail alapjan kideritsuk hogy valoban a juzer kerte a jelszoemlekeztetest.De pl asszem a freemail-nal(javitsatok ki ha nem jol tom) ott ugy van hogy egybol keri a jelszoemlekeztetot,oan helyen ahol nincs mail() meg ez lehet biztonsagos megoldas.


//Hegi
9

"random"

Dualon · 2004. Dec. 18. (Szo), 15.58
A második, "random azonosítónak" (nevezzünk ellenőrzési ID-nek) pont az a lényege, hogy a user(ek) nem tud(nak) róla.
A regisztrációkor kapott id-t bárki megnézheti, ha lekéri a felhasználók listáját, így egyedül ezt használni értelmetlen. Az azonosítót, vagy jelszót még beépíthetném a checksum-ba, de azok változnak, így egyszerűbbnek, kiszámíthatóbbnak, átláthatóbbnak találtam egy olyan ellenőrzési ID bevezetését, ami "belső", így csak a rendszer ismeri az eredetét, viszont afféle "kettős próbával", vagy páros ellenőrzéssel elég jól azonosítható vele a felhasználó.
Pl. ha csak ID-ből generálnám az md5 hash-t, azt ugye bárki reprodukálhatná. Viszont az ID+ellenőrzési ID-ből generált hash-t elég nehezen találhatja ki más, nem lehet (nem érdemes, annyi időt emészt fel) visszafejteni, így a cookie-manipulációk ellen - szerintem - aránylag jól védett a rendszer. Ha az ID is, az ell. ID-is egyezik (tehát session-ben, cookie-ban tárolt checksum egyezik), jó eséllyel a megfelelő felhasználóról van szó. Ha bármelyik eltér, a checksum tök más lesz, a felhasználó véletlenül vagy szándékosan megbuherált ezt-azt. Ha meg nincs session, vagy nincs cookie, akkor egyértelmű a helyzet.
(Elnézést, ha "túlmagyaráztam".)

A jelszóemlékeztetőknél magamból indultam ki... :)

Természetesen meggyőzhető vagyok, szóval köszönöm a véleményt, és várom a további javaslatokat!

Ha már szóba került a freemail: mivel ott ugye nem feltétlenül van már e-mail címe a regisztrálónak, így azt az ötletes megoldást alkalmazták, hogy az adataid megadása után még egyszer meg kell adnod a jelszavad. Még nem próbáltam, mi történik, ha akkor rosszat adsz meg, de ez feltétlenül egy kiváló emlékeztető, figyelmeztető megoldás.
10

Aha...

Hegi · 2004. Dec. 18. (Szo), 16.43
Nos igen,de mi van akkor ha szepen ellopjak az embered session-jet.Akkor ugyebar tok8 hogy milyen nehezen generalod az azonositot,az ott van.Mar egy masik forumba irtam,hogy erdemes az IP cimet osszekotni a session-nel,es a session-t csak random azonositonak hasznalni,benne a juzer ID-t tarolni.Igy hiaba lopjak el a sesson-t,nem tudjak hasznalni(hacsak nem egy halozatban vannak es ugyanazon IP -rol).Az en velemenyem szerint ez egy viszonylag biztonsagos modszer.

A freemailt viszont nem hasznalom,de persze lattam mar.

//Hegi
11

Sessionben csak md5 hash

Dualon · 2004. Dec. 18. (Szo), 18.38
Hm, igazad van. Hiába van a cookie-ban / session cookie-ban csak ID és md5 hash, ha megszerzik, akkor lényegében a usernek tűnnek.
Ezek szerint tényleg érdemes az IP-t is betenni.
Hogyan érdemes ilyenkor megoldani, hogy a rendszer a usert auto felismerje (pl. beléptesse)? Sry, ha ez itt offtopic, mehet a kérdés máshova is (bár szerintem ez még hasznos lehet az elfelejtett jelszavak kérdésénél is).
12

Cookieval

Hegi · 2004. Dec. 18. (Szo), 19.45
Gondolkoztam a problemadon,utannaneztem cikkekben,de semmi.Arra jutottam hogy ezzel (a dinamikus IP cimek miatt) elvesztenenk az IP-t.

Azert nem adtam fel ilyen konnyen,egy alternativat talaltam amirol irjatok meg hogy szerintetek helyes e.

A lenyeg az lenne,hogy egy JS -el megoldani,hogy az X-re kattintva ha van Cookie,akkor futtasson le egy PHP scriptet,ami generel egy kilepesi azonositot,es azt helyezze el a DB-ben meg egy Cookie-ban.Ezt az egy megoldast talaltam erre a problemara,mer ugye ha mar kilepett az oldalrol,akkor mar nem tudjak ravenni hogy ellopjak tole ezt az azonositot.Szoval valami ilyen megoldas amit en jarhatonak tartok.Persze belepeskor azonnal toroljuk a kilepesi azonositot,ha letezik.(Kilepesi azonosito akar a kilepes ideje time()-ban)

Oszinten ez ami valamely biztonsagot nyujt,de szerintem jobb megoldas ha mindig be kell jelentkeznie az emberunknek,sot idokorlatot is erdemes bevezetni,ha X percig nem kattint akkor ne legyen ervenyes a session-je,hanem ujra be kelljen lepnie.

//Hegi
13

Érdekes megoldás

Dualon · 2004. Dec. 20. (H), 01.39
Köszönöm, hogy utánanéztél a dolognak!
Én is utánaolvastam, de még igazából itt, a weblaboron (a világ közepe :D) sem született erre igazán elegáns megoldás (vagy nem találtam meg).

Bevallom, a JS-ben, illetve az ezzel kapcsolatos megoldásokban nem igazán bízom. Legjobb tudomásom szerint a netezők 10-12%-a "lekapcsolja" a JS-t, ami igen komoly arány.

Mindenesetre előbbre jutottam a fentiekkel, még egyszer kösz.
19

Ha olyan hülye,h

Fekete Ferenc GDA · 2005. Már. 28. (H), 15.06
Ha olyan hülye,h elfelejtette a jelszavát (ami általában 12345 vagy jucika, meg stb:) és újat akar, akkor ugyan kapcsolja már be arra az 5 percre a JS-.:))))


ferenc voltam
15

Visszafejtés

unreal · 2005. Már. 27. (V), 21.50
Az md5() tel kódolt hash-et, nem lehet visszafejteni valahogy?

Burgermeiszter Zoltán
16

one-way encryption

Dualon · 2005. Már. 28. (H), 00.19
Az md5 legjobb tudomásom szerint "egyoldalú" kódolás.
Egész pontosan nem is kódolásra találták ki, hanem adategyezés ellenőrzésére: változó hosszúságú stringből fix, 128 bites "azonosítót" hoz létre, amelyet aztán összevethetsz pl. egy beküldött anyag hasonló md5 hash-ével, vagy letöltésnél is használható amolyan "crc-ként".

Ha jelszavakról van szó, akkor nem feltétlenül ez az üdvözítő út.

Valahol pár éve egyébként mintha azt olvastam volna, hogy az md5-tel kódolt string is visszafejthető, csak számítási kapacitás, meg "némi idő" kell hozzá. ,)
Meg aztán nemrégiben hallottam olyat is, hogy elméletileg lehetséges két különböző stringből egyező md5 hash-t létrehozni, de egyrészt gyakorlatilag erre még nem volt példa, másrészt nem igazán bizonyították a dolgot.
Szóval ezeket inkább csak az érdekesség kedvéért írtam.
17

Nekem PHP-ba kellene

Tome · 2005. Már. 28. (H), 10.38
Nekem PHP-ba kellene valamilyen titkosítás, ami string (jelszó) alapján titkosít, és a visszafejthető (természetesen a jelszó ismeretében). Erre tudtok valami megoldást?
Csak kód vagy függvény jöhet szóba, mivel ingyenes tárhelyről szeretném majd futtatni a kódot.
18

Jelszó ismeretében egyszerű

tiny · 2005. Már. 28. (H), 13.26
Szia!
Ha jól értettelek, akkor nem is kell ezt visszafejtened, mert ha ismered a jelszót, akkor azt egy ecrypt() vagy md5() fv-nyel titkosítod, s így hasonlítod össze a másik, eleve titkosított jelszócal. Üdv:
Mr.Tiny :: MRT Site
20

Sajna nem értettél jól.

Tome · 2005. Már. 30. (Sze), 17.08
Sajna nem értettél jól. Nekem olyan titkosítás kellene (persze nem 100%-ig bombabiztosra gondolok, de mezei PC-vel azér, ne lehessen 10 perc alatt visszafejteni), ami valami alapján titkosít, és csak ugyanazon "valami" ismerete alapján lehet visszafejteni az adatok (lehet, hogy az előző hozzászólásomban szerencsétlen volt a jelszó megnevezés, mivel a topic kifejezetten erről szól, nekem pedig nem erre kell). Tartalmat szeretnék tárolásra olyan módon titkosítani, hogy még az adatbázis/tárhely adminja se tudja elolvasni az infokat a titkosítás kulcsának ismerete nélkül. Tehát csak a tulajdonos férjen hozzá, amíg titkosítva van, senki más!

Nos, létezik ilyen kód? Pls segítsen vki!
21

Szia,

virág · 2005. Már. 30. (Sze), 17.46
Szia,

ha van a szerveren mcrypt akkor azzal:

http://hu.php.net/manual/hu/ref.mcrypt.php

Leírás példákkal:

http://phpdocs.tsn.dk/da/function.mcrypt-encrypt.html
22

Nagyon köszönöm a

Tome · 2005. Már. 31. (Cs), 17.31
Nagyon köszönöm a segítséget, valami ilyenre gondoltam. Szerencsére az egyik magyar ingyenes tárhelyszolgáltató támogatja az Mcrypt-et. Magyar nyelvű dokumentáció, vagy legalább valami kis leírás létezik ehhez a titkosításhoz? (egy pár paraméterrel nem teljesen vagyok tisztába)