mboost-dp1
newz.dk
Har de til dels gjort allerede, det hedder Phishing.
Men ja, den her form er meget hidsigere, forestil jer danskebank.dk var omstillet til en lignende..
For satan de kan snuppe mange oplysninger, selvom det kun er et par timer.
Note to self: Log danskebanks's IP adresse.
Men ja, den her form er meget hidsigere, forestil jer danskebank.dk var omstillet til en lignende..
For satan de kan snuppe mange oplysninger, selvom det kun er et par timer.
Note to self: Log danskebanks's IP adresse.
#2 Som Azuria skriver så har det ikke noget med Phishing at gøre. Dette er et hack på selve DNS serverne.
At logge ip adressen holder ikke i det lange løb idet tanken netop er at ip-adresser kan udskiftes løbende. fx når der skiftes udbyder eller blot skift til backup center.
Det er i øvrigt næppe bankerne der er det værste. Dels sikres det at det er en valid side af det certificat der hører sammen med https Dette burde stoppe man-in-the-middle attach - eller vanskelig gøre dem.
Tilsvarende sendes der ikke creditkort oplysninger o.lign før du er logget ind. Og informationerne der sendes i forbindelse med login burde være værdiløse - med mindre der netop er tale om et man-in-the-middle attach.
At logge ip adressen holder ikke i det lange løb idet tanken netop er at ip-adresser kan udskiftes løbende. fx når der skiftes udbyder eller blot skift til backup center.
Det er i øvrigt næppe bankerne der er det værste. Dels sikres det at det er en valid side af det certificat der hører sammen med https Dette burde stoppe man-in-the-middle attach - eller vanskelig gøre dem.
Tilsvarende sendes der ikke creditkort oplysninger o.lign før du er logget ind. Og informationerne der sendes i forbindelse med login burde være værdiløse - med mindre der netop er tale om et man-in-the-middle attach.
Gaaab:
http://cr.yp.to/djbdns/notes.html
Hvorfor det kommer frem som et problem igen lige nu, who knows :-?
http://cr.yp.to/djbdns/notes.html
Hvorfor det kommer frem som et problem igen lige nu, who knows :-?
For en gangs skyld et fornuftig menneske som opdager en fejl og IKKE offentligør den før patchen er ude.
Hader når medierne blæser de nyeste indbrudstekniker op foran alle landets indbyggre :O
Hader når medierne blæser de nyeste indbrudstekniker op foran alle landets indbyggre :O
browseren laver et tjek på om det der står i serverens certifikat i feltet commonname svarer til hvad der er indtastet i browseren...... hvis dns er poisoned og resolver til en anden ip, hvordan skal PKI så opdage det?
10 skrev:For en gangs skyld et fornuftig menneske som opdager en fejl og IKKE offentligør den før patchen er ude.
Hader når medierne blæser de nyeste indbrudstekniker op foran alle landets indbyggre :O
Og for en gangs skyld nogle ansvarlige som lytter til kritik og gør noget ved problemet.
Det ser ud til at denne sag er blevet håndteret usædvanligt fornuftigt.
hmm, ved nærmere eftertanke vil pki faktisk komme med en advarsel..........
Jeg tænkte i banerne at man kunne duplikere certifikatet fra den oprindelige bank, og så lege MITM, men uden certifikatets private key får man ikke meget ud af det.............
man kunne dog lade være med at bruge https....
Jeg tænkte i banerne at man kunne duplikere certifikatet fra den oprindelige bank, og så lege MITM, men uden certifikatets private key får man ikke meget ud af det.............
man kunne dog lade være med at bruge https....
øhm, er det ikke lidt ligemeget at snakke om certifikater og kryptering osv?
det er en viderestilling, så hvis jeg går på danskebank.dk så ryger jeg til en anden server end den siden ellers ligger på. Smæk en anden side på der ligner den rigtige, og når så folk vælger deres nøgle og logger ind gemmer den falske server info og kommer med en besked om serveren desværre ikke lige er i stand til at logge personen på i øjeblikket, men den skulle være oppe snart...
så har man login til alle der forsøger at logge på i den tidsrum hvor man har lavet hack, og er man lidt fix med det er der ingen der finder ud af det. voila, gratis login til en masse netbanker...
eller har jeg misforstået noget fra nyheden?
Ups, glemte selvfølgeligt at sige, hvis man får dns til at pege på en anden server, hvorfor er man så debil nok til at ville forsøge at lave certifikater overhovedet? det giver jo ikke nogen mening...
det er en viderestilling, så hvis jeg går på danskebank.dk så ryger jeg til en anden server end den siden ellers ligger på. Smæk en anden side på der ligner den rigtige, og når så folk vælger deres nøgle og logger ind gemmer den falske server info og kommer med en besked om serveren desværre ikke lige er i stand til at logge personen på i øjeblikket, men den skulle være oppe snart...
så har man login til alle der forsøger at logge på i den tidsrum hvor man har lavet hack, og er man lidt fix med det er der ingen der finder ud af det. voila, gratis login til en masse netbanker...
eller har jeg misforstået noget fra nyheden?
Ups, glemte selvfølgeligt at sige, hvis man får dns til at pege på en anden server, hvorfor er man så debil nok til at ville forsøge at lave certifikater overhovedet? det giver jo ikke nogen mening...
9 skrev:Gaaab:
http://cr.yp.to/djbdns/notes.html
Hvorfor det kommer frem som et problem igen lige nu, who knows :-?
Præcist, denne "massive" sikkerhedsfejl forekommer grundet sloppy programmering af rekursive/caching dns-servere - dårlige practices som "pludselig" viser sig at give problemer.
sjovt nok tog djb sig af dette for flere år siden.
10 skrev:For en gangs skyld et fornuftig menneske som opdager en fejl og IKKE offentligør den før patchen er ude.
Hader når medierne blæser de nyeste indbrudstekniker op foran alle landets indbyggre :O
Da dette problem har været oppe og vende flere gange, er der vidst tale om at dem der laver services til dns er et par årtier bagud i forhold til sikkerhed. DNS poisoning er ikke en ny ting, og som b.la Blomma har påpeget har nogle faktisk for mange år siden lavet produkter der stadig er sikre, uden brug af patches. Ejheller til dette "problem".
At best, har Dan Kaminsky fundet en måde at gøre metoden mere effektiv, men der er ikke noget nyt over det.
Gammel vin på nye flasker.
16 skrev:øhm, er det ikke lidt ligemeget at snakke om certifikater og kryptering osv?
det er en viderestilling, så hvis jeg går på danskebank.dk så ryger jeg til en anden server end den siden ellers ligger på. Smæk en anden side på der ligner den rigtige, og når så folk vælger deres nøgle og logger ind gemmer den falske server info og kommer med en besked om serveren desværre ikke lige er i stand til at logge personen på i øjeblikket, men den skulle være oppe snart...
så har man login til alle der forsøger at logge på i den tidsrum hvor man har lavet hack, og er man lidt fix med det er der ingen der finder ud af det. voila, gratis login til en masse netbanker...
eller har jeg misforstået noget fra nyheden?
Ups, glemte selvfølgeligt at sige, hvis man får dns til at pege på en anden server, hvorfor er man så debil nok til at ville forsøge at lave certifikater overhovedet? det giver jo ikke nogen mening...
Der er ikke noget "viderestilling" over det her, medmindre du kalder normal dns opførsel for viderestilling.
Mht nøgler, bør alle bankers brugsvejledning fortælle at man -altid- skal checke at forbindelsen er sikret via SSL, hvis ikke ville jeg finde en anden bank.
Hvis der skulle forfalskes et certifikat, ville det også være nødvendigt at "forgifte" en certifikat udgiver's adresse og agere dem på lige fod, for at kunne validere certifikatet.
Besværligt, men bestemt ikke umuligt.
Bedst ville det selvfølgelig være at bruge en netbank der bruger forskellige authentication methods, f.eks jyske banks brug af kodekort + personlig kode.
Da netbanken spørger efter en specifik kode på det kodekort du har fået udstukket - med nummer + bogstav kombination, ville dette kræve en -voldsom- del hel for at kunne misbruges.
17 skrev:At best, har Dan Kaminsky fundet en måde at gøre metoden mere effektiv, men der er ikke noget nyt over det.
Det er vel også slemt nok? Som de siger på det mørke sydfyn hvor jeg kommer fra: et hul er hul.
18 skrev:Hvis der skulle forfalskes et certifikat, ville det også være nødvendigt at "forgifte" en certifikat udgiver's adresse og agere dem på lige fod, for at kunne validere certifikatet.
Besværligt, men bestemt ikke umuligt.
Det er vist ikke helt sådan det fungerer.
I din browser er installeret en række rodcertifikater fra forskellige udbydere, f.eks. Verisign. De følger med selve browseren og skal ikke downloades nogen steder fra. Når du så opretter forbindelse til f.eks. din bank via SSL så sender bankens server sit certifikat til din browser som er signeret af f.eks. Verisign. Browseren checker så om signaturen er gyldig via en matematisk proces som udelukkende involverer certifikatet fra bankens server og rodcertifikatet på din egen computer - der er ingen 'validering' mod en fjernserver.
Hvis du skal kompromitterer denne proces bliver det noget med at bryde fysisk ind (det kan ikke gøres via f.eks. DNS-poisoning) i det datacenter hvor Microsoft eller Mozilla el. lign. opbevarer de rodcertifikater som de sender ud med installationsfilerne til deres browsere. Det vil være meget svært - sådan et sted er sandsynligvis topsikret, af samme årsag.
20 skrev:18 skrev:Hvis der skulle forfalskes et certifikat, ville det også være nødvendigt at "forgifte" en certifikat udgiver's adresse og agere dem på lige fod, for at kunne validere certifikatet.
Besværligt, men bestemt ikke umuligt.
Det er vist ikke helt sådan det fungerer.
I din browser er installeret en række rodcertifikater fra forskellige udbydere, f.eks. Verisign. De følger med selve browseren og skal ikke downloades nogen steder fra. Når du så opretter forbindelse til f.eks. din bank via SSL så sender bankens server sit certifikat til din browser som er signeret af f.eks. Verisign. Browseren checker så om signaturen er gyldig via en matematisk proces som udelukkende involverer certifikatet fra bankens server og rodcertifikatet på din egen computer - der er ingen 'validering' mod en fjernserver.
Hvis du skal kompromitterer denne proces bliver det noget med at bryde fysisk ind (det kan ikke gøres via f.eks. DNS-poisoning) i det datacenter hvor Microsoft eller Mozilla el. lign. opbevarer de rodcertifikater som de sender ud med installationsfilerne til deres browsere. Det vil være meget svært - sådan et sted er sandsynligvis topsikret, af samme årsag.
Lige præsis. Og derfor beviser SSL da også i mine øjne hvorfor det er et god form for sikkerhed.
Men der er da helt sikkert stadig en masse andre applicationer som kan blive hårdt ramt af den slags. Om ikke andet så kan man da tjene penge på den trafik man kunne stjæle fra Google
21 skrev:Lige præsis. Og derfor beviser SSL da også i mine øjne hvorfor det er et god form for sikkerhed.
Jep, PKI på IP-niveau (tror det kaldes DNSSEC) burde være indført som standard for mange år siden. Det ville kunne eliminere et utal af alvorlige sikkerhedsproblemer nærmest fra den ene dag til den anden. Så mange at man fristes til at spørge om det mon er sikkerhedsindustrien selv der forsinker processen...
#18 tror ikke helt du forstod min pointe, SSL og certificater handler om at sikre komminikationen imellem to klienter.
Og det kan da godt være en hver seriøs netbank bør skrive man skal kontrollere certifikat osv. men lad os nu prøve at være realistiske, vi snakker om hr og fru jensen. Hvor mange af dem kan rent faktisk finde ud af hvad et certificat er. hvor mange ved rent faktisk om en forbindelse er sikker eller ej?
hvis jeg valgte at sende www.danskebank.dk til en eller anden rusisk hacker server, med en kopi af danske banks forside samt login. Hvor mange personer ville så rent faktisk bemærke at der ikke kørte certifikat på den side (hvorfor skulle jeg dog installere det?), hvor mange ville rent faktisk bemærke at de login informationer jeg taster ind ikke ryger til danske banks loginserver, men derimod til rusland?
Så ja, SSL er godt, så lang tid man er opmærksom på det, og man er sikker på hvem man snakker med(serveren).
Og det kan da godt være en hver seriøs netbank bør skrive man skal kontrollere certifikat osv. men lad os nu prøve at være realistiske, vi snakker om hr og fru jensen. Hvor mange af dem kan rent faktisk finde ud af hvad et certificat er. hvor mange ved rent faktisk om en forbindelse er sikker eller ej?
hvis jeg valgte at sende www.danskebank.dk til en eller anden rusisk hacker server, med en kopi af danske banks forside samt login. Hvor mange personer ville så rent faktisk bemærke at der ikke kørte certifikat på den side (hvorfor skulle jeg dog installere det?), hvor mange ville rent faktisk bemærke at de login informationer jeg taster ind ikke ryger til danske banks loginserver, men derimod til rusland?
Så ja, SSL er godt, så lang tid man er opmærksom på det, og man er sikker på hvem man snakker med(serveren).
24 skrev:Så ja, SSL er godt, så lang tid man er opmærksom på det, og man er sikker på hvem man snakker med(serveren).
Opmærksom, javist, men man behøver ikke at være sikker på hvem man snakker med, eftersom certifikatet (som flere også har nævnt) sammenlignes med domænenavnet. Det kræver så at angriberne har et gyldigt (og underskrevet) certifikat med samme navn som ens bank. Det valser de nok ikke direkte ind hos VeriSign og får.
Men det er klart at dette kun udgør i en sikkerhed i det omfang at folk rent faktik tjekker at der er ikke er noget galt når de logger ind. Browserne advarer jo hvis domænenavn ikke passer eller certifikatet ikke er underskrevet.
#25 - Man kan få et "quick" certifikat meget let og hurtigt. Det kræver blot at man har adgang til en bestemt mailkonto for det domæne, som man ønsker et certifikat til. "Fully-automated 10-minute provisioning process" reklamerer GeoTrust med i forbindelse med deres QuickSSL.
Men man kan da håbe at udstedere af "quick" certifikater ikke er sårbare overfor dns problemet, og man dermed ikke kan forgifte sig til at få den email de sender med certifikatet i. :)
Men man kan da håbe at udstedere af "quick" certifikater ikke er sårbare overfor dns problemet, og man dermed ikke kan forgifte sig til at få den email de sender med certifikatet i. :)
23 skrev:#8 og #12
Læs #13...
PKI bruger jo netop DNS til at sikre sig at man har fat i den rigtige server...
Nej ... SSL bruger PKI til at sikre at DNS opgiver den rigtige server. Ikke omvendt.
26 skrev:#25 - Man kan få et "quick" certifikat meget let og hurtigt.
Det er vel irrelevant hvor hurtigt det går så længe procedurerne er i orden. Det er ikke helt til at vurdere ud fra det du skriver.
19 skrev:Det er vel også slemt nok? Som de siger på det mørke sydfyn hvor jeg kommer fra: et hul er hul.
Det er korrekt, dette hul skulle bare have været fixet i 2003, eller tidligere, hvilket var pointen. (I forhold til at Thorleif mente at sagen var håndteret godt).
28 skrev:Det er korrekt, dette hul skulle bare have været fixet i 2003, eller tidligere, hvilket var pointen. (I forhold til at Thorleif mente at sagen var håndteret godt).
Hvordan kan du vide det? Det er jo ikke engang blevet offentliggjort endnu?
20 skrev:
Det er vist ikke helt sådan det fungerer.
I din browser er installeret en række rodcertifikater fra forskellige udbydere, f.eks. Verisign. De følger med selve browseren og skal ikke downloades nogen steder fra. Når du så opretter forbindelse til f.eks. din bank via SSL så sender bankens server sit certifikat til din browser som er signeret af f.eks. Verisign. Browseren checker så om signaturen er gyldig via en matematisk proces som udelukkende involverer certifikatet fra bankens server og rodcertifikatet på din egen computer - der er ingen 'validering' mod en fjernserver.
Hvis du skal kompromitterer denne proces bliver det noget med at bryde fysisk ind (det kan ikke gøres via f.eks. DNS-poisoning) i det datacenter hvor Microsoft eller Mozilla el. lign. opbevarer de rodcertifikater som de sender ud med installationsfilerne til deres browsere. Det vil være meget svært - sådan et sted er sandsynligvis topsikret, af samme årsag.
Fair nok, jeg havde regnet med at der blev foretaget et key-challenge-response check på de offentlige udbyderes keyservere imod dette licens.
Så ville der i stedet skulle fakes eventuelle opdateringer til browsere, i hvilket tilfælde det sandsyngvis ville være nemmere, samt mere interresant at smide spy/malware ind i processen.
29 skrev:Hvordan kan du vide det? Det er jo ikke engang blevet offentliggjort endnu?
Fordi de patches der pt. er blevet implementeret til at fixe problemerne gør det v.h.a randomization af porte. (deraf, Dan's kommentar om at de de patches der er implementeret heldigvis ikke -umidbart- giver muligheden for reverse engineering).
Der er tale om dns poisoning som af andre er blevet ordnet v.h.a randomization af porte i 2003 eller tidligere.
Det er et tidligere ignoreret problem fordi det var skønnet at det ville være upraktisk men ikke umuligt at gøre - dengang.
At Dan så har fundet en måde at gøre det mere effektivt er så hvad det er, men det skulle allerede være ordnet dengang.
30 skrev:Så ville der i stedet skulle fakes eventuelle opdateringer til browsere, i hvilket tilfælde det sandsyngvis ville være nemmere, samt mere interresant at smide spy/malware ind i processen.
Hvilket naturligvis ville være nøjagtigt ligeså umuligt fordi opdateringerne skal signeres med, ja gæt hvad, selv samme rodcertifikater som du forsøger at udskifte.
#31
Det lyder meget interessant. Du har siden 2003 kendt til en sårbarhed som 5 år senere pludselig får udviklere fra verdens førende teknologiproducenter til at mødes i al hemmelighed på Microsoft Campus marts i år for at sammen at finde en løsning. Fortæl mig mere.
#27
Det har du ret i. Validering af køber består dog kun i at køber kan modtage email på en bestemt konto på domænet. Så derfor er det naturligvis vigtigt at udstederen får fat i den rigtige mailserver, når domænet slås op i DNS.
Det er vel irrelevant hvor hurtigt det går så længe procedurerne er i orden. Det er ikke helt til at vurdere ud fra det du skriver.
Det har du ret i. Validering af køber består dog kun i at køber kan modtage email på en bestemt konto på domænet. Så derfor er det naturligvis vigtigt at udstederen får fat i den rigtige mailserver, når domænet slås op i DNS.
32 skrev:Hvilket naturligvis ville være nøjagtigt ligeså umuligt fordi opdateringerne skal signeres med, ja gæt hvad, selv samme rodcertifikater som du forsøger at udskifte.
#31
Det lyder meget interessant. Du har siden 2003 kendt til en sårbarhed som 5 år senere pludselig får udviklere fra verdens førende teknologiproducenter til at mødes i al hemmelighed på Microsoft Campus marts i år for at sammen at finde en løsning. Fortæl mig mere.
Ja - alle software vendors bruge selvfølgelig certifikater, i forhold til alt. det havde jeg glemt.
jeg synes jeg havde understreget at:
1) dette er et dns poisoning angreb. det er ikke noget nyt fænomen.
2) andre vendors har implementeret countermeasures, og er ikke vulnerable. disse er implementeret v.h.a random ports.
3) patches til vulnerable services er implementeret m. random ports.
Ergo, hvis b.la bind ikke havde siddet på sine hænder og glædet sig over sin markedsandel, men faktisk været proaktiv i forhold til sikkerhed, ville de ikke være sårbare i dag.
Igen, gammel vin på nye flasker - men jeg er sikker på at du er i stand til at tage et udpluk og give det en eller anden form for spin. EOD herfra.
34 skrev:1) dette er et dns poisoning angreb. det er ikke noget nyt fænomen.
Hørt hos systemadministratoren for den 30.000 mand store virksomhed efter alle deres systemer er blevet ramt af en lammende virus: "Jeg har læst i Computerworld at der er tale om en såkaldt computervirus - det er ikke noget nyt fænomen - jeg fjernede allerede en virus i begyndelsen af 2003, så jeg agter ikke at foretage mig yderligere i denne sag."
Ergo, hvis b.la bind ikke havde siddet på sine hænder og glædet sig over sin markedsandel, men faktisk været proaktiv i forhold til sikkerhed, ville de ikke være sårbare i dag.
Jeg syntes bare det betænkeligt at du har kendt til en sårbarhed siden 2003 som får verden til at stå på den anden ende fem år senere. Hvorfor har du ikke sagt noget til Paul Vixie? - stakkels Paul Vixie som kun har udviklet Internettets mest udbredte DNS-server - han er jo ingenting i forhold til dig.
Igen, gammel vin på nye flasker
Microsoft kendte ikke sårbarheden. Cisco kendte ikke sårbarheden. Paul Vixie kendte ikke sårbarheden. Daniel Bernstein som du selv refererer til kendte ikke sårbarheden. Men du gjorde - fascinerende.
EOD herfra.
Hvorfor? Er du bange?
#34
For lige at gnide salt i såret. Fra Dino Dai Zovi, der i modsætning til dig rent faktisk kender sårbarheden:
Og så er den sag vist afgjort.
Der er uden tvivl tale om en ny og kritisk sårbarhed. Lad være med at stille dig op som sikkerhedsekspert på baggrund af en eller anden kommentar du har lige har samlet op på Slashdot. Computersikkerhed er en alvorlig sag - overlad det venligst til eksperterne (dvs. hverken mig eller dig).
For lige at gnide salt i såret. Fra Dino Dai Zovi, der i modsætning til dig rent faktisk kender sårbarheden:
Dan explained the full details and scope of his attack and both of us were impressed and agreed that it is way more serious than we had imagined. ... In summary, when the full details of Dan’s attack come out, you will most likely be impressed. I definitely was.
Og så er den sag vist afgjort.
Der er uden tvivl tale om en ny og kritisk sårbarhed. Lad være med at stille dig op som sikkerhedsekspert på baggrund af en eller anden kommentar du har lige har samlet op på Slashdot. Computersikkerhed er en alvorlig sag - overlad det venligst til eksperterne (dvs. hverken mig eller dig).
37 skrev:#34
For lige at gnide salt i såret. Fra Dino Dai Zovi, der i modsætning til dig rent faktisk kender sårbarheden:
Og så er den sag vist afgjort.
Der er uden tvivl tale om en ny og kritisk sårbarhed. Lad være med at stille dig op som sikkerhedsekspert på baggrund af en eller anden kommentar du har lige har samlet op på Slashdot. Computersikkerhed er en alvorlig sag - overlad det venligst til eksperterne (dvs. hverken mig eller dig).
Siden du insisterer på at blive ved med at kaste mudder:
http://www.doxpara.com/ - Dan Kaminsky's hjemmeside, med dns checker.
Må jeg henrette opmærsomheden på sektion 2
(An Astonishing Collaboration)
DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.
Derudover kunne du/I læse http://cr.yp.to/djbdns/dns_random.html
Altså, dette var løst I af andre tidligere, publiceret og informeret til b.la. BIND (OG Paul Vixie) men ignoreret.
38 skrev:Altså, dette var løst I af andre tidligere, publiceret og informeret til b.la. BIND (OG Paul Vixie) men ignoreret.
Nej, det er jo lige nøjagtigt det det ikke var - og det ved du helt ligeså vel som mig.
Det som Kaminsky har opdaget er en sårbarhed. Det som DJB anbefalede var en praksis. Du kritiserer Vixie for ikke at have implementeret denne praksis tidligere. Fortæl os nu: hvorfor skulle Vixie have implementeret denne praksis?
39 skrev:Nej, det er jo lige nøjagtigt det det ikke var - og det ved du helt ligeså vel som mig.
Det som Kaminsky har opdaget er en sårbarhed. Det som DJB anbefalede var en praksis. Du kritiserer Vixie for ikke at have implementeret denne praksis tidligere. Fortæl os nu: hvorfor skulle Vixie have implementeret denne praksis?
Igen taget fra Dan Kaminisky's post, på hans eget site, i den artikel jeg refererede til tidligere.
Of course, it remains obvious that something new is up, and that something will be found eventually. But there’s a lot of buggy systems out there, vulnerable not just to new bugs but bugs that have been known for years. If all this effort ever accomplished was sweeping old and crusty BIND8 off the Internet, if we could finally fully eliminate Joe Stewart’s (edit: Originally Vagner Sacramento’s, thanks Joe!) Birthday Attacks from 2002, if we started doing something about Amit Klein’s Transaction ID Randomness finds (even the deeply underrated client vulns) from last year, and yes, if the static port assignments DJB warned us about ages ago were finally shut down — then this would still be a huge win.
(interresant at en praksisk potentielt kan udrydde så mange problemer, ikke?)
http://cr.yp.to/djbdns/forgery.html
Ydermere: http://cr.yp.to/djbdns/forgery-cost.txt
Samt mere eller mindre alle ikke glue-record relaterede dns poisoning "problemer".
For år siden, var det praksis at bruge cleartext authentication, I dag bruger man kryptering. Det er også en praksis.
Hvis et produkt i dag kun brugte cleartext - ville det blive betragtet som et sikkerhedshul, ikke en manglende praksis.
hth. HAND.
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
- ⟨
- Nyheder
Gå til bund