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. |
Vreme je GMT +2. Trenutno vreme je 20:15. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.