mboost-dp1
Kryptering af password
Det lyder ikke særlig sikkert.Fifan (3) skrev:Er det så muligt at inkludere adgangskoden fra en anden webserver hvor brugeren ikke har adgang med include() ?
En søgning på Google efter "php sql password" gav blandt andet en youtube video med instruktioner som lød lovende. Men Google har ødelagt linkene på søgeresultaterne så man ikke længere kan kopiere dem, så prøv selv om du kan finde den.
kasperd (5) skrev:Det lyder ikke særlig sikkert.
En søgning på Google efter "php sql password" gav blandt andet en youtube video med instruktioner som lød lovende. Men Google har ødelagt linkene på søgeresultaterne så man ikke længere kan kopiere dem, så prøv selv om du kan finde den.
Hvorfor er det ikke sikkert? Havde tænkt mig at lave koden som en variable og kalde den et eller andet sindsygt. Kan man benytte sig af en variable som kommer fra en anden side man har inkluderet?
Så har du tabt.Fifan (7) skrev:Det er hele computeren som andre brugere har adgang til og ikke kun en 'public' mappe.
Hvis du vil have revanche, så bliver du nødt til at flytte applikationen fra php til den computer bagved, som kodeordet skulle give adgang til. Præcist hvordan det gøres afhænger af hvilken protokol du snakker med computeren bagved.
Hvis det f.eks. er SQL må du implementere applikationen i SQL vha. views, triggers, osv. Hav så niveauer af adgang til databasen. F.eks. root med de højeste privilegier, en admin med adgang til at ændre på triggers og lignende. En account med adgang til at ændre tabeller så længe konsistenskravene er opfyldt, og endeligt en applikationsbruger, der kun kan interagere gennem views, stored procedures osv. Så ender du med at php kun bruges til at formatere output og alt sikkerhed håndteres i SQL.
Hvis man kan læse filen med en URL i skal der ikke ret meget til for at tilgå den URL. Derudover kommer trusselen om at hijacke forbindelsen mellem de to webservere for at injecte php kode.Fifan (8) skrev:Hvorfor er det ikke sikkert?
Det lyder som om du har tænkt dig at bruge security through obscurity samtidigt med at din adversary har adgang til at læse hele din kildekode. Er det korrekt forstået?Fifan (8) skrev:Havde tænkt mig at lave koden som en variable og kalde den et eller andet sindsygt.
Hvilket password drejer det sig om ?
Som udgangspunkt kan du ikke skjule noget for din bruger / udvikler, med adgang til hele computeren samt PHP koden... Selv om du krypterede koden, ville man jo kunne lure den ved at echo'e resultatet af din decrypt rutine.
Det du kan gøre er at have dine config filer med koder liggende et andet sted, og så kun give adgang til mappen med dit PHP projekt, men igen ville man kunne læse passwordet hvis man har adgang til at ændre og eksekvere PHP-koden.
Hvis det drejer sig om et hardcoded password, f.eks til et backend kan du bruge f.eks SHA1 hashing.
kasperd's løsning er nok den mest robuste, hvis det er SQL vi taler om, da alt andet generelt er security through obscurity.
Som udgangspunkt kan du ikke skjule noget for din bruger / udvikler, med adgang til hele computeren samt PHP koden... Selv om du krypterede koden, ville man jo kunne lure den ved at echo'e resultatet af din decrypt rutine.
Det du kan gøre er at have dine config filer med koder liggende et andet sted, og så kun give adgang til mappen med dit PHP projekt, men igen ville man kunne læse passwordet hvis man har adgang til at ændre og eksekvere PHP-koden.
Hvis det drejer sig om et hardcoded password, f.eks til et backend kan du bruge f.eks SHA1 hashing.
kasperd's løsning er nok den mest robuste, hvis det er SQL vi taler om, da alt andet generelt er security through obscurity.
Gem en MD5 krypteret udgave af kodeordet i din PHP variabel.
Den kode som brugeren indtaster laver du så en MD5 krypteret udgave af, og ser om den er den samme som i din PHP variabel.
Hvis der er et match, har brugeren angivet det rigtige kodeord, uden at du på noget tidspunkt har skrevet kodeordet i din PHP-kode.
Hvis du vil øge sikkerheden endnu mere, så benytter du en "salt" ved MD5 krypteringen.
Den kode som brugeren indtaster laver du så en MD5 krypteret udgave af, og ser om den er den samme som i din PHP variabel.
Hvis der er et match, har brugeren angivet det rigtige kodeord, uden at du på noget tidspunkt har skrevet kodeordet i din PHP-kode.
Hvis du vil øge sikkerheden endnu mere, så benytter du en "salt" ved MD5 krypteringen.
#11
Saa benytter den onsindede bruger jo bare samme salt og MD5 kode til at opnaa det rigtige password? :)
#12
Saa bruger du en read-only service konto fra dit AD.
Det giver ikke mening at du koerer *noget som helst* med din egen user.
Din user i et AD skal *KUN* bruges til handlinger du selv, manuelt, udfoerer.
Saa benytter den onsindede bruger jo bare samme salt og MD5 kode til at opnaa det rigtige password? :)
#12
Saa bruger du en read-only service konto fra dit AD.
Det giver ikke mening at du koerer *noget som helst* med din egen user.
Din user i et AD skal *KUN* bruges til handlinger du selv, manuelt, udfoerer.
#13 Selvom en ondsindet bruger kender MD5 værdien af kodeord + salt, kan brugeren næppe komme frem til det oprindelige kodeord. Så længe login-funktionen stadig MD5 krypterer det indtastede kodeord sammen med en salt'en, og laver sammenligningen ud fra det, så skulle der ikke være nogen risiko for det.
Har den ondsindede bruger dog direkte adgang til PHP filerne, så kan brugerne jo altid bare ændre i koden sådan at man enten automatisk er logget ind, eller ændre variablerne for MD5 værdien og salt'en til noget fra et kodeord han selv finder på.
Har den ondsindede bruger dog direkte adgang til PHP filerne, så kan brugerne jo altid bare ændre i koden sådan at man enten automatisk er logget ind, eller ændre variablerne for MD5 værdien og salt'en til noget fra et kodeord han selv finder på.
Den løsning virker kun hvis alle brugere at webapplikationen kender passwordet til databasen.milandt (11) skrev:Hvis der er et match, har brugeren angivet det rigtige kodeord, uden at du på noget tidspunkt har skrevet kodeordet i din PHP-kode.
Jeg kan få øje på tre fejl i den sætning.milandt (11) skrev:Hvis du vil øge sikkerheden endnu mere, så benytter du en "salt" ved MD5 krypteringen.
Hvis man vil gå den vej, så kan man lige så godt lære fra starten af at salt er obligatorisk. Vi skal ikke give nogen en opfattelse af at salt er noget man bruger hvis man synes, hasher man selv passwords, så bruger man salt.
Derudover er det tåbeligt at bruge MD5 hvis man vil lave noget som helst nyt, hvor man har brug for en kryptografisk hash. Som minimum bruger man SHA1, men hellere SHA2.
Endeligt hedder det ikke en kryptering. Det hedder en hash eller en kryptografisk hash. Dog er angreb imod MD5 i dag så effektive at den ikke længere kan kaldes en kryptografisk hash.
Og så mangler vi stadig at få at vide hvad passwordet skal bruges til. Det kunne være til en database, men det ved vi ikke. Du har tilsyneladende en anden opfattelse af passwordets anvendelse end resten af os, men det har vi jo ikke fået noget svar på endnu.
Indtastes passwordet af brugeren og bruges det til at oprette forbindelse til en database, så behøver php scriptet måske ikke engang validere passwordet. Det kan bare oprette forbindelsen og se om databasen accepterer passwordet.
Adversary har adgang til alle filer på computeren, og computeren har adgang til et netværksfilsystem. Hvad får dig til at tro at adversary ikke bare læser de filer som computeren bruger til at autentificere sig overfor filserveren og opnår adgang af den vej?Fifan (15) skrev:Jeg kunne jo ligge koden på et netværksdrev og bruge file_get_content
Fifan (1) skrev:Er det muligt at skjule eller kryptere et password i PHP så man ikke kan se passwordet som klar tekst hvis en bruger har adgang til php filen's kildekode.
Fifan (3) skrev:Er det så muligt at inkludere adgangskoden fra en anden webserver hvor brugeren ikke har adgang med include() ?
Fifan (8) skrev:Hvorfor er det ikke sikkert? Havde tænkt mig at lave koden som en variable og kalde den et eller andet sindsygt. Kan man benytte sig af en variable som kommer fra en anden side man har inkluderet?
(10) skrev:Det du kan gøre er at have dine config filer med koder liggende et andet sted, og så kun give adgang til mappen med dit PHP projekt,
Fifan (15) skrev:Jeg kunne jo ligge koden på et netværksdrev og bruge file_get_content som i youtube videoen.
Vi har koden:
<?php
$un = "Fifan";
$pw = "hemmelig";
noget($un, $pw);
?>
som vi vil sikre.
Nu betaler vi verdens 10 bedste kryptografi eksperter om at lave en ny 1 million bit kryptering.
Og så gemmer vi kryptereret password og key på 10000 servere fordelt over hele verden.
Og så retter vi koden til:
<?php
$un = "Fifan";
$pwinfo = hent_pw_info_fra_1000_servere();
$pw = dekrypter_med_1millionbit_key($pwinfo);
noget($un, $pw);
?>
Hvorefter hackeren bruger 5 sekunder på at rette koden til:
<?php
$un = "Fifan";
$pwinfo = hent_pw_info_fra_1000_servere();
$pw = dekrypter_med_1millionbit_key($pwinfo);
send_password_til_hacker($pw);
noget($un, $pw);
?>
kalder siden og retter tilbage igen.
Konceptet duer ikke!!
milandt (11) skrev:Gem en MD5 krypteret udgave af kodeordet i din PHP variabel.
Den kode som brugeren indtaster laver du så en MD5 krypteret udgave af, og ser om den er den samme som i din PHP variabel.
Hvis der er et match, har brugeren angivet det rigtige kodeord, uden at du på noget tidspunkt har skrevet kodeordet i din PHP-kode.
Men det er jo en løsning på et helt andet problem end det som spørges til.
Jeg synes spørgsmålet er lidt uklart. Det kunne være enten det ene eller det andet.arne_v (19) skrev:Men det er jo en løsning på et helt andet problem end det som spørges til.
Korrekt. Der er meget effektive collision attacks imod MD5. Men preimage og second preimage angreb er der til gengæld mig bekendt aldrig udført imod MD5.arne_v (20) skrev:Men i denne sammenhæng er det værd at bemærke at det er collision attack ikke preimage attack hvor MD5 er hullet som en si.
Og selv hvis man havde et preimage angreb er det ikke givet at det ville kunne bruges til at bryde password hashes.
Der er ingen akut trussel imod passwords beskyttet med salt og MD5.
Men hvis man stadig bruger MD5 som om det var en kryptografisk hash er det nok fordi man ikke har designet sit system til at kunne opgradere til en ny hash. Og så er det på tide man ændrer sit design.
kasperd (23) skrev:Det indlæg forstod jeg til gengæld overhovedet ikke.
Der er tale om denne kode lokalt på maskinen.
Hvor det er 'password' som skal skjules.
<?php
$url = "http://localhost";
$username = "domæne\brugernavn";
$password = "password";
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERPWD, "$username:$password");
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
$output = curl_exec($ch);
curl_close($ch);
echo $output;
?>
#24
Hvordan vil du gemme passwordet naar du skal authenticate paa den maskine automatisk? :)
Det du efterspoerger kan ikke lade sig goere paa en praktisk maade, uden at du begraenser andres adgang til brugerkonti og krypterer mappen fra den bruger der skal koere automatisk.
Hvordan vil du gemme passwordet naar du skal authenticate paa den maskine automatisk? :)
Det du efterspoerger kan ikke lade sig goere paa en praktisk maade, uden at du begraenser andres adgang til brugerkonti og krypterer mappen fra den bruger der skal koere automatisk.
fidomuh (27) skrev:#24
Hvordan vil du gemme passwordet naar du skal authenticate paa den maskine automatisk? :)
Det du efterspoerger kan ikke lade sig goere paa en praktisk maade, uden at du begraenser andres adgang til brugerkonti og krypterer mappen fra den bruger der skal koere automatisk.
Passwordet er jo gemt når jeg har angives det og gemt filen. Derefter kører jeg filen i IE som en opgave i opgavestyring.
kasperd (21) skrev:Korrekt. Der er meget effektive collision attacks imod MD5. Men preimage og second preimage angreb er der til gengæld mig bekendt aldrig udført imod MD5.
Jeg er for søvnig til at søge og checke; men den meget aktuelle Flame beroede på certifikatfusk med MD5 (så vidt min søvnige hjerne husker); det kunne godt være et vellykket pre-image attack. Alle mulige forbehold for at jeg husker forkert tages...
fidomuh (29) skrev:#28
Men har de andre brugere administrativ adgang til samme maskine, saa er alt hvad du skriver i den fil, kompromitteret.
Derfor havde jeg muligvis tænkt mig at benytte mig af youtube videoen fra #6 og placere adgangskoden på et netværksdrev som er forbundet til min bruger og derefter bruge file_get_content til at hente adgangskoden til DOM-objektet.
Fifan (31) skrev:fidomuh (29) skrev:#28
Men har de andre brugere administrativ adgang til samme maskine, saa er alt hvad du skriver i den fil, kompromitteret.
Derfor havde jeg muligvis tænkt mig at benytte mig af youtube videoen fra #6 og placere adgangskoden på et netværksdrev som er forbundet til min bruger og derefter bruge file_get_content til at hente adgangskoden til DOM-objektet.
hvad er der i vejen for at du laver det sådan at du mødes af en promt som vil have en kode inden den fortsætter?
Sandsynligvis har nogen lækket den hemmelige nøgle, eller også har en person med legitim adgang til den hemmelige nøgle været medskyldig.Pally (30) skrev:den meget aktuelle Flame beroede på certifikatfusk med MD5
Den slags forekommer jo tit, og det har intet at gøre med om kryptografien er sikker.
Meget usandsynligt.Pally (30) skrev:det kunne godt være et vellykket pre-image attack.
Den mest sandsynlige forklaring er at et autentisk certifikat er blevet misbrugt. En mindre sandsynlig, men ikke fuldstændigt usandsynlig forklaring er at de har brugt en kollision med MD5.
Det har været offentligt kendt i otte år, at der kan laves kollisioner imod MD5. Hvis nogen stadig bruger MD5 til at underskrive certifikater, så burde de ikke have et job.
#31
Saa han retter bare i koden og skriver "echo $password" bagefter og magisk har han adgang?!
Du kan ikke lave det paa den maade, uden at begraense adgangen til computeren. :)
Derfor havde jeg muligvis tænkt mig at benytte mig af youtube videoen fra #6 og placere adgangskoden på et netværksdrev som er forbundet til min bruger og derefter bruge file_get_content til at hente adgangskoden til DOM-objektet.
Saa han retter bare i koden og skriver "echo $password" bagefter og magisk har han adgang?!
Du kan ikke lave det paa den maade, uden at begraense adgangen til computeren. :)
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund