Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
AbonnerSkjul
Host1.no - Webhotell fra 29,-, virtuell server fra 249,-. 15% rabatt med rabattkode "nFF". Besøk oss på Host1.no!
  12 1500
i mac
52 2
19. mai 2010
Hei

Jeg er veldig paranoid.
Er sessions sikker å bruke for innlogging ?

Selvfølgelig har jeg SHA-1 encryption og sjekk mot database med tusenvis av begrensinger fra lengde til bruk av tall mellomromm og ALT du kan tenke deg. Og jeg har sikret meg mot mysql injections osv osv.

Når det er bekreftet at brukeren eksisterer bruker jeg session for å gi brukeren tilgang til det han har rett til. Men jeg er veldig paranoid, er session sikre nokk?

jeg bruker session sha1 av brukerid & navn for å "huske" hvilken bruker jeg har inne.
EivindH
695 37
19. mai 2010
Det er nå greit nok, men jeg ville sett litt på hvordan du krypterer passord. Google Doublesalt, og se hva du finner på php.net. Den vil jeg si er ganske sikker. (sha512 + noe annen kryptering)
s1gh
s1gh's Avatar
1.785 384
19. mai 2010
Bare sørg for å validere input og output.
Sessions fungerer jo til sitt formål, men det kan fort bli en sikkerhetsbrist hvis nettsiden din er sårbar for XSS.
i mac
Trådstarter
52 2
20. mai 2010
Er det nokk å hindre XSS ved å filtrere alt input ??

Sitat av EivindH Vis innlegg
Det er nå greit nok, men jeg ville sett litt på hvordan du krypterer passord. Google Doublesalt, og se hva du finner på php.net. Den vil jeg si er ganske sikker. (sha512 + noe annen kryptering)
Vis hele sitatet...
Jeg bruker sha1 som sagt, men jeg vurderer å lage min egen algoritme fordi jeg ikke stoler på sha1, eller forsåvidt ingen andre fordi jeg er paranoid.

Hjelp har aldri hørt om Doublesalt, fant ikke noe via google, kan du gi meg link ?
Sist endret av i mac; 20. mai 2010 kl. 00:05.
s1gh
s1gh's Avatar
1.785 384
20. mai 2010
PHP har noen fine funksjoner for å filtrere input. Les litt mer om dem på php sine nettsider.
Nå har jeg ikke alle i hodet, men htmlspecialchars() er vel én av dem.

Lage din egen algoritme? Virkelig? Jeg vil heller anbefale deg å bruke en av de kjente algoritmene som finnes i dag, gjerne sammen med et salt.


Edit: For å pirke, hvis du bruker SHA-1, MD5 osv. så krypterer du ikke passordet, du hasher det.
Med kryptering kan du komme tilbake til den opprinnelige dataen ved hjelp av f.eks. en nøkkel - det kan du ikke med hashing.
Sist endret av s1gh; 20. mai 2010 kl. 00:13.
i mac
Trådstarter
52 2
20. mai 2010
Sitat av s1gh Vis innlegg
PHP har noen fine funksjoner for å filtrere input. Les litt mer om dem på php sine nettsider.
Nå har jeg ikke alle i hodet, men htmlspecialchars() er vel én av dem.

Lage din egen algoritme? Virkelig? Jeg vil heller anbefale deg å bruke en av de kjente algoritmene som finnes i dag, gjerne sammen med et salt.
Vis hele sitatet...
Problemet er vel at alle algoritmer kan knekkes og de algoritmene som finnes er public, mens en egen algoritme er ikke tilgjengelig for alle å eksperimentere på.

Sitat av s1gh Vis innlegg
PHP har noen fine funksjoner for å filtrere input. Les litt mer om dem på php sine nettsider.
Nå har jeg ikke alle i hodet, men htmlspecialchars() er vel én av dem.

Lage din egen algoritme? Virkelig? Jeg vil heller anbefale deg å bruke en av de kjente algoritmene som finnes i dag, gjerne sammen med et salt.


Edit: For å pirke, hvis du bruker SHA-1, MD5 osv. så krypterer du ikke passordet, du hasher det.
Med kryptering kan du komme tilbake til den opprinnelige dataen ved hjelp av f.eks. en nøkkel - det kan du ikke med hashing.
Vis hele sitatet...
Nettopp. Hasher kan ikke reverseres, matematisk definert, men det er mulig å finne svakheter i det. Såkalte kollisjoner.

edit:
Ved å bruke egen algoritme isteden for hash eller andre algoritmer, gir man ikke andre muligheten til å eksperimentere for å finne slike kollisjoner. Men jeg tror absolutt ikke at jeg kan lage noe som er mer sikkert enn sha-x, men jeg tror faktumet at ingen andre har tilgang til det vil gjøre den mer sikker.

edit2:

Så når man ser på det fra ulike synsvinkler er det to sider av samme sak.
Det er umulig å gjøre seg 100% sikker mot alt.
s1gh
s1gh's Avatar
1.785 384
20. mai 2010
1) Mener du selv at du kan lage en algoritme som sikrer passordene bedre enn f.eks. SHA-1?
2) Ja, hash collisions eksisterer, det er derfor jeg anbefaler deg å bruke et salt sammen med den hash-algoritmen du måtte bestemme deg for å bruke.
danielsk
2.224 689
20. mai 2010
Sitat av i mac Vis innlegg
Problemet er vel at alle algoritmer kan knekkes og de algoritmene som finnes er public, mens en egen algoritme er ikke tilgjengelig for alle å eksperimentere på.



Nettopp. Hasher kan ikke reverseres, matematisk definert, men det er mulig å finne svakheter i det. Såkalte kollisjoner.

edit:
Ved å bruke egen algoritme isteden for hash eller andre algoritmer, gir man ikke andre muligheten til å eksperimentere for å finne slike kollisjoner. Men jeg tror absolutt ikke at jeg kan lage noe som er mer sikkert enn sha-x, men jeg tror faktumet at ingen andre har tilgang til det vil gjøre den mer sikker.

edit2:

Så når man ser på det fra ulike synsvinkler er det to sider av samme sak.
Det er umulig å gjøre seg 100% sikker mot alt.
Vis hele sitatet...
Dersom du bruker Sha1 med skikkelig salt er det nok ikke her bekymringen bør ligge. Du kan jo selvfølgelig gå for Sha256 eller Sha512 isteden...

Hvordan beskytter du deg mot man-in-the-middle attack? Hvordan sikrer du webserveren din mot angrep?
Sist endret av danielsk; 20. mai 2010 kl. 00:26.
i mac
Trådstarter
52 2
20. mai 2010
Sitat av s1gh Vis innlegg
1) Mener du selv at du kan lage en algoritme som sikrer passordene bedre enn f.eks. SHA-1?
2) Ja, hash collisions eksisterer, det er derfor jeg anbefaler deg å bruke et salt sammen med den hash-algoritmen du måtte bestemme deg for å bruke.
Vis hele sitatet...
Q.E.D ovenfor.

Sitat av danielsk Vis innlegg
Dersom du bruker Sha1 med skikkelig salt er det nok ikke her bekymringen bør ligge. Du kan jo selvfølgelig gå for Sha256 eller Sha512 isteden...

Hvordan beskytter du deg mot man-in-the-middle attack? Hvordan sikrer du webserveren din mot angrep?
Vis hele sitatet...
Uansett om jeg har https så kan jeg risikere en MITM angrep. Jeg har ingen anelse om hvordan man beskytter seg mot det. Ingen strategi. Hvor skal jeg starte?
EivindH
695 37
20. mai 2010
This.

Kode

<?php
function doubleSalt($toHash,$username){
$password = str_split($toHash,(strlen($toHash)/2)+1);
var_dump($password);
$hash = hash('sha512', $username.$password[0].'centerSalt'.$password[1]);
return $hash;
} 
?>
Vil anse denne som relativ trygg, iom at den lager én hash til vær bruker, som er unik og 255 characters lang.
Sist endret av EivindH; 20. mai 2010 kl. 00:37.
vidarlo
Trigonoceps occipita
vidarlo's Avatar
Donor
27.682 31.077
20. mai 2010
Definer kven du skal beskytte deg mot. Sessions er trygt nok til vanlig, causual bruk, men neppe spesielt holdbart om det er PST som er trusselen din, ettersom dei kan snoope opp sessioncookies fra ISP om dei har rettsordre. Det er heller ikkje ekstremt effektivt mot nokon på samme fysiske nettverk.

Og i mac: det er et ordtak som seier at alle er i stand til å lage et system som er så trygt at dei ikkje kan knekke det. IKKJE forsøk å lage egne kryptoalgoritmer eller hashfunksjoner. Det er dømt til å gå rett i dass, omtrent uansett kor omfattande erfaring du har med det. Security by obscurity funker ikkje. Og når det gjeld SHA-512 så er det ikkje kjente kollisjoner så vidt eg veit - og om det er det så er dei hovedsaklig av akademisk interesse.
fuzzy76
webdings
fuzzy76's Avatar
2.482 589
20. mai 2010
Hva er det du krypterer? session-innholdet? session-id'en? brukernavnet i databasen?

Det viktigste sikkerhetselementet i en session er at innholdet (som default, det går an å endre) lagres på serveren, slik at klienten aldri ser det. Og har derfor ingen mulighet til å se eller endre innholdet. Dette gjelder da PHP, andre plattformer kan gjøre ting litt annerledes.
▼ ... over en uke senere ... ▼
z0p
uʍop ǝpısdn
z0p's Avatar
3.814 906
29. mai 2010
Hvordan er den fysiske sikkerheten til host? Det virker en smule overdrevent å fokusere såpass mye på kryptering av passord. Jeg ville også kryptert databasen og all informasjon dersom det var snakk om så utrolig spennende innhold. Eller jeg ville sannsynligvis dratt ut nett-kontakten og, satt meg i hjørnet med en stor skiftnøkkel og ei skive med ost.

Neida, det er selvfølgelig viktig å tenke på sikkerhet, men det er også viktig å prioritere, og lokalisere det svakeste punktet. Sessions er ikke sikkert om det ikke kjører på en sikker platform, og ingen vil bruke tid på å knekke passord kryptering om de kan gå rett til dataen.