Avatar billede lone_a_p Praktikant
16. april 2011 - 09:36 Der er 13 kommentarer og
1 løsning

Kryptering af password

Er det bedst/sikrest at kryptere bruger-passwords i mysql eller php?

Og hvilken funktion er bedst at anvende?

Mvh Lone
Avatar billede webweaver Praktikant
16. april 2011 - 10:05 #1
Jeg krypterer altid i PHP.

Der findes et par hurtige funktioner såsom MD5 og SHA1.

$kodeord_secure = md5($kodeord);

eller

$kodeord_secure = sha1($kodeord);

$kodeord indeholder det rå kodeord fra din form eller hvor det nu kommer fra. Så er det krypteret og du smider $kodeord_secure i databasen.

Du bør nok vælge SHA1 (eller større, SHA256 fx afhængig af hvor sikkert det skal være), da MD5 ikke er så sikkert som det har været længere og der findes en del rainbow databaser over dette efterhånden.
Avatar billede repox Seniormester
16. april 2011 - 11:12 #2
Den primære årsag til at jeg krypterer kodeordene er at jeg vil aldrig med 100% sikkerhed kunne være sikker på at mine løsninger ikke er sårbare overfor angreb.

Så hvis jeg skulle blive udsat engang, kan jeg være sikker på at mine brugeres personlige kodeord ikke er synligt for dem som har nu engang har brudt min applikation og fået fat i de oplysninger.
Avatar billede webweaver Praktikant
16. april 2011 - 15:33 #3
Hvis du virkelig ønsker en sikker "linie", bør du også læse lidt nærmere omkring det der hedder "salt". Altså salted hash. Der findes tekster omkring det på nettet, som kan findes fra Google f.eks.
Avatar billede rax Praktikant
20. april 2011 - 11:24 #4
og endelig bør du overveje, om kodeordet bør krypteres på clienten, før det sendes til serveren, hvor enten php eller mysql krypterer det. Dette gælder kun hvis du sender over http, da kodeordet ellers vil kunne sniffes før det når serveren. Sender du over https, er dette step unødvendigt.
Avatar billede repox Seniormester
20. april 2011 - 11:37 #5
#4
Det er et temmelig ekstremt scenarie - hvis det vitterligt var en reel bekymring, ville det bedste helt klart være at anbefale OP at anskaffe sig et SSL certifikat.

Men det ville absolut kun være en overvejelse for mig hvis jeg skulle gemme følsomme oplysninger om min bruger.

Med andre ord: lad være med at blive for forsigtig - det kan øge kompleksiteten unødvendigt eller give en tåbelig ekstra udgift. Overvej om det er nødvendigt inden sådanne initiativer kommer på bordet.
Avatar billede rax Praktikant
20. april 2011 - 12:54 #6
#5
Det var også blot for fuldstændighedens skyld, da spørgsmålet synes at være mere af teoretisk natur end praksis. Og bekymringen er reel nok, da det er muligt at opsnappe brugerens credentials før de ankommer på serveren. Ergo snakker man sikkerhed, så er det en væsentlig faktor at tage med i sin betragtning, selvom langt de fleste (mig selv inklusiv) fravælger at sikre sig på denne front, med mindre der er tale om ultrafølsomme oplysninger.
Avatar billede repox Seniormester
20. april 2011 - 12:59 #7
#6
Jeg vil nu alligevel sige at lige præcis den type af angreb kræver så megen teknisk viden, tid samt adgang at sandsynligheden er så lille at netop kun ultrafølsomme oplysninger (eller lovkrav) kan kræve den form for sikkerhed.
Avatar billede lone_a_p Praktikant
20. april 2011 - 13:45 #8
Vil det være dumt at poste den php krypteringfunktion, som jeg har tænkt mig at anvende, for at høre, om den er ok?

Jeg forstår ikke helt md5, sha1 og sha256. Hvis sha256 er mest sikker, hvorfor så ikke altid benytte denne?
Jeg kan se, at resultatet af sha256 fylder dobbelt så meget som sha1. Men hvis der ikke er et større problem med sha256 ift. sha1, er det vel til enhver tid bedst at benytte sha256?
Eller hvad overser jeg?
Avatar billede rax Praktikant
20. april 2011 - 13:45 #9
#7
Og der er vi fortsat enige. Men kæden er aldrig stærkere end det svageste led, så hvis du vil betragte sikkerheden ud fra et hollistisk synspunkt, så kan du smide nok så meget kryptering, validering og sikkerhed på dine inputs på serveren.. men bliver de kompromiterede før de når så langt, så er det uinteressant hvad du gør ved dem på serveren.

Nu arbejder jeg selv med udvikling i bankverdenen, som er et glimrende eksempel på behovet for den slags sikkerhed. De færeste ville bekymre sig om det på deres personlige websted, men når det kommer til sikkerhed, så er kæden aldrig stærkere end svageste led, og det bør man have i mente.
Avatar billede rax Praktikant
20. april 2011 - 13:50 #10
Lone, du har ganske ret, sha256 kan lige så godt anvendes, og giver den største sikkerhed af dine alternativer (256 bit).
Avatar billede lone_a_p Praktikant
20. april 2011 - 14:13 #11
Vil det være ok at smide den tiltænkte funktion herind i tråden, så jeg kan få respons på denne - eller er det dumt at "afsløre" denne ;)
(jeg skal nok lave mindre modifikationer til den funktion jeg kommer til at benytte)

Hvis den er sikker nok, kan den vel alligevel ikke brydes, trods den er kendt ... og egentlig er det nok også nemmere at hente selve php-krypteringsfunktionen end at bryde krypteringen, hvis det endelig skulle komme til det :)

Profilerne indeholder oplysninger om eget madindtag og motionsforbrug, så jeg taler om almindelig sikkerhed på web - ikke ekstrasikker bankniveau eller lign. :)
Avatar billede repox Seniormester
20. april 2011 - 14:17 #12
Hvis du hasher kodeordene med et salt, som tidligere nævnt her, så er det mere end rigeligt til dit behov.
Avatar billede rax Praktikant
20. april 2011 - 15:03 #13
jep, et salted hash er glimrende sikkerhed til dit behov. Og du kan roligt vise hvilken algoritme du anvender, hvis du gerne vil diskutere denne.
Avatar billede webweaver Praktikant
16. august 2011 - 22:58 #14
Svar
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Vi tilbyder markedets bedste kurser inden for webudvikling

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester