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? |
Pa u svetlu postojanja servisa tipa desetominutnih mail naloga ... pitanje je ima li smisla čitava patnja oko aktivacije.
|
Citat:
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... |
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 |
Citat:
|
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? |
Citat:
|
Citat:
Citat:
Inace sam protiv cuvanja plain-text sifara bilo gde, osim tamo gde je to zaista neophodno. |
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.
|
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. |
Nesto o aktivaciji i aktivacionom kodu.
Jel tu ima neka fora. Pravila koja su proistekla iz iskustava? Kako uglavnom generisete kodove, passworde? |
Citat:
|
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'" :) |
Hehe, voleo bih da vidim junaka koji će da dekriptuje ovakav password hash u doglednom vremenu:
Kôd:
algo$salt$hsh Kôd:
algo = 'sha1' |
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).
|
@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 |
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.. |
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.
|
Citat:
Š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). |
Citat:
"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. |
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:
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 ... |
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 05:08. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.