Vi bruger ikke pop-up reklamer, og de få reklamer der vises hjælper til at betale for sitets drift. Som medlem kan du desuden tjene points, og bruge dem på at fjerne reklamerne.
Denne fremgangsmåde er valgt, så selve kodeordets repræsentation i databasen, aldrig kan sammenlignes med selvsamme kodeord fra et andet websites database.
Hackes og stjæles hele databasen herfra, får folk ganske vist ukrypterede e-mailadresser og brugernavne, men kodeordene kan de ikke bruge til noget. Det er umuligt at brute force en dekryptering uden at kende både typerne, sekvensen og encryption strengen (der iøvrigt er en hel sætning som igen - kun jeg kender).
Af selvsamme grund kan jeg aldrig gensende jeres kodeord til jer. Jeg kan blot tilbyde at nulstille dem til noget andet.
Du har overvejet en mere standard process? F.eks. PBKDF2 i PHP, eller noget som bcrypt eller scrypt, alle med en random per user salt. For mig lyder det til at du har en sekvens af hashes som kan udlæses fra koden samt en salt som er ens for alle brugere i systemet, samt står i koden.
Dette vil give en ulempe at hvis databasen er komprimeret af udefrakommende, så lyder det for det første til at hvis flere har samme kode, så vil hashen være den samme for alle i systemet med den samme kode.
Samtidig, så kan det diskuteres om det er en god idé med iterationer af algoritmen. Efter en samtale med kasperd, så kan han se både gode og dårlige ting ved interations. Et højt niveau af iterations vil sætte pres på serveren, men samtidig sænke bruteforce hastigheden. Hvis man laver en penelty på for mange forkerte indtastninger af kodeordet, så vil det formindske muligheden for DDoS hvis antallet af interationer er høj.
Addendum til #5: Ideen med at have sikkerhed baseret på "kun vi kender til opbygningen" er ikke specielt god. Det går vist under "security by obscurity" og kan ikke anbefales. Så hellere bruge en metode som er kendt og bevist stærk. Samtidig, så har den kloge kasperd fortalt mig at man bør holde sig til in-framework implementeringer af sådanne algoritmer grundet at der er større chance for at de er testet, valideret og reviewed.
Det er security by obscurity. Det er dumt. :-) Problemet med hvordan man opbevarer passwords sikkert er blevet løst. MD5 og SHA1 er ikke sikre nok til at opbevare passwords.
Brug standardfunktionerne i PHP.
password_hash(password, PASSWORD_DEFAULT) // tekststreng, op til 255 karakterer
password_verify(password_hash) // True / False
Så får du dem både saltet, hashed & du sikrer dig mod timing attacks.
Jeg kan ikke lige finde ud af at redigere mit indlæg, men en lille tilføjelse:
Husk at bruge needs_rehash når brugeren logger ind, og du kan også sætte "cost" parameteren på password_hash hvis du vil have at den skal være endnu mere sikker. Men default er ganske godt. (10)
Bemærk dog at ovenstående password_* funktioner kræver PHP 5.5 og at TechStart kører på 5.4.43 (i følge response headeren). Man kan dog opnå det samme med brug af crypt http://php.net/manual/en/function.crypt.php man skal bare være opmærksom på at man med crypt() selv skal generere salten, og det er vigtigt at man har det rigtige prefix på salten så man ikke ender med at bruge DES, det er dog alt sammen beskrevet på http://php.net/manual/en/function.crypt.php. Ved sammenligning af hashes bør man heller ikke bruge almindelige sammenligningsoperatorer, men derimod funktioner som password_verify eller hash_equals() (http://php.net/manual/en/function.hash-equals.php), det er dog en PHP 5.6 funktion, men der er et eksempel øverst i kommentarene på hvordan det kan gøres i ældre versioner.
Jeg tror det var en uheldig formulering som svar på mit indlæg. DDoS er ikke en risiko baseret på et højt antal interationer i forhold til hashing af kodeord. Altså, grundet begrænset antal forsøg på login, så vil man ikke kunne bruge login mekanismen til at udføre DDoS på siden via kraftig load på hashing algoritmen.
Ved MD5 som udgangspunkt passer det med at userid er lige efter. Hash: 42f60d9092e6503bc3ebb65ed31bbe47 UserId: El_Kebabmeister Random: uudoyVqaKPNoNeV (dno hvad det bruges til)
Algoritme som passer: md5(md5(md5(sha1(md5(kodeord))))) = Hash
Du burde måske genoverveje din kode og hvorfor fanden er ens kodeord en del af cookien?
Sikkerhedsexpert bliver du vidst aldrig, eller jo, måske hos CSC. :-)
NB - TechStart skulle gerne køre PHP 5.6 nu her. Dvs. muligheder fra 5.5 og 5.6 kan jeg bruge.
Var egentlig ved at skrive en PB til dig, men tænker at vi også bare ka ta den her i åbent forum:
Tak for svar.
På PHP.NET nævnes:
Caution
The PBKDF2 method can be used for hashing passwords for storage. However, it should be noted that password_hash() or crypt()with CRYPT_BLOWFISH are better suited for password storage.
Any thoughts?
Det er for mig ét fedt hvad jeg vælger - de ser ud som om de er identiske at opkode mht. kompleksitet/kodestruktur, blot forskellige.
Til andre - jeg begyndte for lidt tid siden at omkode loginsystemet til sessionbaseret fremfor cookie storage - og det er til hashing herfor at jeg spugte El_Kebabmeister.
Eller ville en bedre anbefaling være at bruge eks. MyOpenID - og hvis ja; hvad sker der hvis MyOpenID kompromitteres? Er risikoen for at nogen vil hacke for at ramme bredt, ikke større end specifikt?
Jo større systemet er, og jo bredere folk vil ramme ved at bryde det, jo større er incitamentet så også til at skaberne holder det sikkert.
Jeg tror at login systemer som eksempelvis Facebook og Google som bruges så mange steder... De er sikret så meget, af eksperter på området, for de har ganske enkelt ikke råd til at fejle.
Der hvor jeg stejler ved netop især Facebook og Google, er at jeg helst ikke vil pådutte nogen her på portalen, at benytte "real life" navne og kontoer som er mere direkte tilknyttet hvem de er.
Ikke at det skal lyde som "dette er en portal for lyssky foretagender" - men jeg kan bare godt følge, hvis man ønsker disse ting separeret.
At skulle oprette en ny Facebook/Google konto kun for at kunne bruge den til at logge på med her, er omvendt også meget at kræve af folk.
Så er der MyOpenID; som lidt har det samme problem som Facebook og Google; der er for mange elementer jeg ikke selv kan styre. Eks. simple ting som sprog - ved fejlbeskeder, glemt kodeord osv... hvis jeg ønsker noget omformuleret, gjort på en anden måde osv...
Omvendt har jeg ikke meget hands-on erfaring med disse løsninger, så jeg tager måske fejl der?
Bare fordi man bruger Facebook/Google til authentication, så behøver man vel ikke have sit navn bundet på siden. Det eneste du håndtere er vel en authentication token af en art. Hvad du viser på siden, det må du om. Jeg vil også sige at man kan tilbyde MyOpenID, Facebook og Google authentication, men jeg mener stadig folk bør have en mulighed for bare at have en konto lokalt på siden. Den lokale bruger skal bare være sikret tilstrækkeligt og på en forsvarlig måde.
.
Indsend nyhed » 