DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Registracija korisnika (http://www.devprotalk.com/showthread.php?t=2487)

oliver78 25. 02. 2007. 20:17

Registracija korisnika
 
Hocu da napravim skriptu za registraciju korisnika.
Sta je sve vazno. Od prijave, registracije, aktivacije...

Kolacici, sesije...

Neki savet? O cemu voditi racuna?

noviKorisnik 25. 02. 2007. 21:56

Pa u svetlu postojanja servisa tipa desetominutnih mail naloga ... pitanje je ima li smisla čitava patnja oko aktivacije.

Ilija Studen 25. 02. 2007. 22:01

Citat:

Originalno napisao noviKorisnik
Pa u svetlu postojanja servisa tipa desetominutnih mail naloga ... pitanje je ima li smisla čitava patnja oko aktivacije.

Ima smisla. Bar znaš da je čovek za računarom...

Obično aktivaciju rešim tako što im pošaljem password na email adresu (sa mogućnošću da ga ponovo pošaljem za dati username ako im prvi put ne stigne). Ako ne može da pročita mail - ne može da se uloguje. Simple...

noviKorisnik 25. 02. 2007. 22:09

Uvek kriptujem pass, tako da ni nema šta da šaljem na mail :-)

- korisnik ostavlja mail adresu
- dobija mail s aktivacionim linkom
- na aktivacionoj stranici nastavlja dalje, postavlja pass, itd

zextra 25. 02. 2007. 22:09

Citat:

Originalno napisao Ilija Studen
Ako ne može da pročita mail - ne može da se uloguje.

Imas pravo - ovo je cesto jednostavnije nego dosadna aktivacija e-mail adrese. Jedino sto se onda password salje plain-textom korisniku, a to se jedino izbegava aktivacijom... Ali, ko ne mari mnogo za sigurnost svojih korisnika, onda je tvoje resenje plain & simple.

Ilija Studen 25. 02. 2007. 22:16

Obično očekuješ da će korisnik promeniti lozinku u nešto njemu poznato. Takođe, možeš nakon prvog logina da ga redirektuješ na change password stranicu i ponudiš mu da unese neku njemu poznatu lozinku kako bi povećao procenat ljudi koji izmene lozinke.

Imaš sledeće opcije:

1. Dva polja više u registracionoj formi (Password + Confirm password) + klik na aktivacioni link u mailu.
2. Smanjena sigurnost jer se lozinka šalje na mail (mada, tu funkcionalnost imaš i kod Lost password formi).

Ili?

misk0 25. 02. 2007. 22:30

Citat:

Originalno napisao noviKorisnik
Uvek kriptujem pass, tako da ni nema šta da šaljem na mail :-)

Pri kreiranju accounta generishes pass, posaljes ga na mail, kriptujes i smjestis u bazu. Znaci ipak 'ga imas' :)

zextra 25. 02. 2007. 22:37

Citat:

Originalno napisao Ilija Studen
Obično očekuješ da će korisnik promeniti lozinku u nešto njemu poznato.

Da, to bi opravdalo slanje plain-text sifre mailom (po mogucnosti odmah nakon prvog logina, na silu :)

Citat:

Originalno napisao Ilija Studen
2. Smanjena sigurnost jer se lozinka šalje na mail (mada, tu funkcionalnost imaš i kod Lost password formi).

I kod zaboravljene sifre moguce je u mailu poslati link koji vodi do stranice na kojoj korisnik unosi novu sifru.

Inace sam protiv cuvanja plain-text sifara bilo gde, osim tamo gde je to zaista neophodno.

Ilija Studen 25. 02. 2007. 22:46

Nisam rekao da čuvam čiste šifre. Uvek je to sha1 salt stringa + šifre da se oteža brutovanje iz dictionaryja. Kada korisnik zatraži šifru sa Lost password generišem i setujem random šifru i pošaljem je na mail. Ovo je moguće zloupotrebiti pa malo-malo resetovati šifru ortaku kome znaš mail, ali do sada nisam naišao na zloupotrebe, ali i to se lako može zaštititi.

bluesman 25. 02. 2007. 23:01

Jedno prakticno pitanje: zasto drzite encrypt-ovane sifre u bazi? Ako je neka "zastita" onda je sifra korisnika tvoj najmanji problem ako je neko uspeo da ti udje u bazu.

I zasto slati bilo kome sifru na mail po registraciji. To je maltretiranje ljudi. Vecina ljudi koristi istu ili 2-3 iste sifre za sve te sajtove (osim za neke bankovne racune ili slicno)... ti ga teras da pamti novu sifru, a ako ne pamti onda mora da je zapise - a to je ponovo security risk. I onda u najboljem slucaju, cim se uloguje na sajt prvi put - odmah menja sifru. Pustis coveka da sam izabere sebi sifru.

oliver78 25. 02. 2007. 23:13

Nesto o aktivaciji i aktivacionom kodu.

Jel tu ima neka fora. Pravila koja su proistekla iz iskustava?

Kako uglavnom generisete kodove, passworde?

Dušan Dželebdžić 25. 02. 2007. 23:14

Citat:

Originalno napisao bluesman
Jedno prakticno pitanje: zasto drzite encrypt-ovane sifre u bazi? Ako je neka "zastita" onda je sifra korisnika tvoj najmanji problem ako je neko uspeo da ti udje u bazu.

Drugim pasusom si odgovorio na prvi - ako ti provale u sajt, poslednje što želiš je da cracker dođe do plaintext šifara svih tvojih korisnika. Ne zbog sigurnosti tvog sajta, već zbog svih tvojih korisnika koji tu istu šifru verovatno koriste na još 30ak sajtova.

bluesman 25. 02. 2007. 23:25

Pa ako ti provali u bazu onda nemas vise ni sajt ni bazu ni bilo sta :) Sta bi on sa tim siframa? Da se uloguje u bazu u koju ionako ima full pristup :) A ako neko zna da ti udje u bazu, nije mu frka ni da provali sve sifre, koliko god one encrypt-ovane bile, neke brze neke sporije. To je cisto zaludjivanje.

Ako ti je usao u bazu a ti encryptovao sifre, ako ne zna nista drugo moze bar da uradi: DROP TABLE users... ili ako je neki dobar cika "UPDATE users set sifra je 'moja sifra'" :)

Petar Marić 25. 02. 2007. 23:45

Hehe, voleo bih da vidim junaka koji će da dekriptuje ovakav password hash u doglednom vremenu:
Kôd:

algo$salt$hsh
gde je:
Kôd:

algo = 'sha1'
salt = sha.new(str(random.random())).hexdigest()[:5]
hsh = sha.new(salt+raw_password).hexdigest()

Što se tiče menjanja podataka u bazi - čemu služi backup? ;)

zextra 25. 02. 2007. 23:54

Pa, ili generises sifru i saljes je korisniku na mail, pa trazis od njega da sam stavi sifru koju hoce, ili ga pustis da odma unese sifru koju hoce, pa mu trazis redovnu aktivaciju (click na link) da bi aktivirao postojeci nalog (ili nastavio sa procesom registracije).

zextra 26. 02. 2007. 00:02

@bluesman: pa, recimo da neko upadne u bazu gde imas usere koji stite vredne informacije onim "jacim" siframa, koje takodje koriste za druge vredne informacije - citanjem plain text sifara, email adresa i jos nekih podataka, vrlo je lako pogoditi puno toga o korisnicima.

I, Petre... ne psuj :D

ivanhoe 26. 02. 2007. 00:02

ako enkriptujes sifre one-way-hashom tesko ce provaliti sve sifre, mozda par slabijih, ali ce to trajati, pa si kupujes neko vreme (da obavestis ljude da promene passworde ili da juris napadaca ili da emigriras na Novi Zeland pod laznim imenom :D )

A takodje daleko su manje sanse da neko bas preuzme sajt skroz, pre ce usled nekog propusta/baga haker da dobije priliku da izvrsi neki upit koji ne bi smeo, pa da tako dodje do poneke sifre. U takvoj varijanti on nema pojma kako tacno tvoj kod za enkriptovanje radi, plus ima limitirano vreme dok ga ne prvalis, tako da ukoliko malkice izkomplikujes hashovanje (XOR-ujes password sa usernameom i nekom tajnom reci npr.) nece imati nikakve sanse da provali ukradenu sifru, sem ako je iz CIA-e..

Velika mana cuvanja one-way hashovanih passworda je sto korisnici non-stop zaboravljaju passworde i onda moras stalno da im generises nove, sto ih dodatno zbunjuje, pa onda jos vise zaboravljaju i tako u krug... Iz tog razloga ja sam pre sklon da cuvam sve passworde u plain textu pa kud puklo da puklo.... ili akome ne mrzi eventualno da ih enkriptujem nekim 2-way algoritmom (blowfish ili nesto slicno), mada je to diskutabilno posto moras da imas key negde na serveru, tako da bas i nije neka sigurnost...cisto dimna zavesa za script-kiddies..

Ivan 26. 02. 2007. 00:22

Uglavnom, bilo kakva enkripcija je dobro dosla zbog sigurnosti korisnika na drugim sajtovima/forumima/email nalozima/ i slicno ... jer vecina taj isti koristi i na tim drugim mestima.

Ilija Studen 26. 02. 2007. 08:13

Citat:

Originalno napisao ivanhoe
Velika mana cuvanja one-way hashovanih passworda je sto korisnici non-stop zaboravljaju passworde i onda moras stalno da im generises nove, sto ih dodatno zbunjuje, pa onda jos vise zaboravljaju i tako u krug...

Onda možda malo da ukomplikuješ Lost password sistem. Kada čovek ode na lost password stranicu ponudiš mu formu gde će da unese novu šifru i objašnjenje da će kod za aktivaciju biti poslat na njegovu email adresu. Zapamtiš privremenu lozinku, pošalješ mail i nakon klika na aktivacioni link pregaziš postojeću.

Što se čuvanja plain šifre u bazi tiče - zavisi šta praviš. Ako je tvoj projekat zanimljiv napadačima (popularni open source prozivodi, sistemi koji barataju sa potencijalno vrednim podacima itd) onda definitivno uloži sve da bi zaštitio šifre svojih korisnika, čak i po cenu cimanja da se resetuje lozinka. U ostalim situacijama može da prođe i plain varijanta, ali je definitivno ne bih preporučio... Radi sve do jednom (to "do jednom" ne mora nikad da se desi, ali je otovrena opcija).

Dušan Dželebdžić 26. 02. 2007. 09:47

Citat:

Originalno napisao bluesman
Ako ti je usao u bazu a ti encryptovao sifre, ako ne zna nista drugo moze bar da uradi: DROP TABLE users... ili ako je neki dobar cika "UPDATE users set sifra je 'moja sifra'" :)

Zato što je ogromna razlika između:

"Dragi korisnici, izvinite zbog downtimea, imali smo hakerski napad, vraćamo backup"

i:

"Dragi korisnici, izvinite zbog downtimea, imali smo hakerski napad, vraćamo backup. Ah da, sve vaše lozinke su pokradene, ako ih koristite na više sajtova trk da ih menjate" :1074:

Okreni-obrni, sajt ti je srušen. Stvar je tvoje politike da li će korisnici samo malo gunđati zbog downtime-a, ili će brže-bolje pozatvarati naloge kad vide da njihove šifre kod tebe nisu sigurne.

marinowski 26. 02. 2007. 21:50

Sve više su popularni 'lazy registration' sajtovi, koji omogućuju da uradiš dosta toga bez registracije. Naravno da se često registracija ne može izbeći. U tom slučaju preporučujem da se držite sledećih pravila:
  • napišite jasno šta korisnik dobija registracijom.
  • neka forma bude što jednostavnija
  • neka bude što manje obaveznih polja
  • ako forma mora biti opširna, neka bude na dve stranice. Nakon što korisnik popuni prvu stranicu, sledeću će popuniti da je završi
  • više preferiram validaciju e-maila, nego slanje passworda na e-mail

Zašto što manje obaveznih polja? Ukoliko se korisnik navikne na servis, i vidi da su ostali korisnici popunili polja, poželeće i on da popuni ostala polja i da bude punopravni član zajednice.

Takođe, bitno je da svoju bazu korisnika održavate čistom, ukoliko je e-mail bitan. Broj mrtvih e-mailova je veći nego što možete pretpostaviti. Takođe, ima više freemail naloga nego što mislimo: baš danas sam pregledao servise koje održavamo u Mađarskoj, od 300.000 korisnika, 2/3 koristi freemail naloge ...

zextra 27. 02. 2007. 00:17

Kad spomenu free mail naloge.. Evo liste freemail domena iz 2003 godine - ako ih je onda bilo toliko (i verujem da su svi imali svoje korisnike), koliko li ih je onda danas...


Vreme je GMT +2. Trenutno vreme je 12:30.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.