mboost-dp1
Kan de ikke bare opgradere til en sha-2 hash i stedet for kun sha-1? Og så senere på året sha-3.
Folk der bruger et pw på mere end én side, hvor LinkedIn er jo stadigvæk blevet kompromitteret.
Hvad enten det har kostet brugerne eller ej, er for så vidt jo ligegyldigt. Men fint at de får et smæk udover den dårlige PR, så de sætter deres underbemandede sikkerhedsafdeling til at lave noget.
Folk der bruger et pw på mere end én side, hvor LinkedIn er jo stadigvæk blevet kompromitteret.
Hvad enten det har kostet brugerne eller ej, er for så vidt jo ligegyldigt. Men fint at de får et smæk udover den dårlige PR, så de sætter deres underbemandede sikkerhedsafdeling til at lave noget.
Lad os lige en gang for alle få slået fast. Et læk af den type som skete for Linkedin er kun en trussel for brugere der har brugt for svage passwords. Desuden er trusselen i det tilfælde størst for brugere, som har brugt samme passwords til flere sites.
Har man brugt et stærkt password har man været fuldstændigt uberørt af hændelsen, indtil Linkedin lukkede for alle passwords svarende til lækkede hashes, uanset hvor stærke passwords, der var tale om.
Hvis brugere er blevet negativt berørt er det altså ikke pga. dårlig sikkerhed hos Linkedin, men derimod fordi brugernes egen adfærd ikke lever op til branchens standarder.
Linkedin kan selvfølgelig også forbedre deres sikkerhed, men det mest effektive tiltag de kan tage er faktisk at forhindre brugere i at vælge dårlige passwords.
Næstefter kvaliteten af de passwords brugerne vælger er den mest effektive foranstaltning at bruge salt til at beskytte passwords.
Men valget af hashfunktion er dog ikke særligt vigtigt i forhold til de andre punkter. De to vigtigste foranstaltninger er:
1. Brugerne vælger gode passwords.
2. På serveren hashes de med et salt på minimum 64 bits.
Har man brugt et stærkt password har man været fuldstændigt uberørt af hændelsen, indtil Linkedin lukkede for alle passwords svarende til lækkede hashes, uanset hvor stærke passwords, der var tale om.
Hvis brugere er blevet negativt berørt er det altså ikke pga. dårlig sikkerhed hos Linkedin, men derimod fordi brugernes egen adfærd ikke lever op til branchens standarder.
Linkedin kan selvfølgelig også forbedre deres sikkerhed, men det mest effektive tiltag de kan tage er faktisk at forhindre brugere i at vælge dårlige passwords.
Næstefter kvaliteten af de passwords brugerne vælger er den mest effektive foranstaltning at bruge salt til at beskytte passwords.
at det sociale medie samtidig ikke anvendte "etablerede krypterings-protokoller, der er standard i branchen".Vås. Protokoller til verifikation af passwords kunne hjælpe gevaldigt på sikkerheden. Den slags er der desværre ingen etablerede standard for. Alle sites bruger samme usikre metode hvor serveren får at vide hvad brugerens password er.
Det er underordnet. MD5, SHA1, SHA224, SHA512 er alle stærke nok til at de ikke i dag udgør nogen betydelig svaghed når de bruges til passwords. Men er man først igang med at ændre noget, så kan man lige så godt bruge den stærkeste af de tilgængelige hashfunktioner.Djensen (1) skrev:Kan de ikke bare opgradere til en sha-2 hash i stedet for kun sha-1? Og så senere på året sha-3.
Men valget af hashfunktion er dog ikke særligt vigtigt i forhold til de andre punkter. De to vigtigste foranstaltninger er:
1. Brugerne vælger gode passwords.
2. På serveren hashes de med et salt på minimum 64 bits.
Og det er den vigtigste lektion at lære. Det er ikke Linkedins fejl at brugerne har gjort det. Der er intet Linkedin kan gøre for at forhindre brugere i at bruge samme password på forskellige sites.Djensen (1) skrev:Folk der bruger et pw på mere end én side, hvor LinkedIn er jo stadigvæk blevet kompromitteret.
Så hvis ens login ikke har været disabled, så er ens password ikke blandt de lækkede?kasperd (2) skrev:Linkedin lukkede for alle passwords svarende til lækkede hashes, uanset hvor stærke passwords, der var tale om.
Det har jeg så overset. Men fint tiltag.
Anyway, nu hvor der har været så meget tale om salt for tiden - noget jeg aldrig har sat mig ind i - kan jeg ikke lade være med at tænke...
Kunne man ikke bare lave noget i stil med, at passwordet bliver en hash af md5(inputPassword)+inputPassword ->
07e26bd19d43dd0987d334d6c67742dc + inputPassword ->
2e6021ab04875fb7c0892e6ca95ffbad.
Eller er der en sårbarhed i dét, som jeg overser?
(Ville gerne have skrevet "hash + input" i ét ord, men d'et ville hoppe ned på næste linie. Meh.)
Det kan man ikke sige med 100% sikkerhed, da der mig bekendt endnu ikke er nogen forklaring på hvordan hashværdierne blev lækket i første omgang.Mnc (3) skrev:Så hvis ens login ikke har været disabled, så er ens password ikke blandt de lækkede?
Der er blevet spredt knap 6 millioner SHA1 hashværdier på nettet. Men vi ved ikke om nogen har været i besiddelse af 12 millioner SHA1 hashværdier fra Linkedin og valgte kun at sprede halvdelen.
De jeg kan sige med sikkerhed er at SHA1 hashen af mit password er på den lækkede liste, og det blev lukket. Jeg fik en email om det fra Linkedin for ca. 2 uger siden.
Jeg kan ikke vide om Linkedin har lukket for præcist de rigtige passwords. Det har jeg ikke mulighed for at undersøge.
Det du beskriver er ittereret hashing. Der er uenighed om hvor mange gange man bør itterere. Men det løser ikke det problem man ønsker at løse med salt.Mnc (3) skrev:Kunne man ikke bare lave noget i stil med, at passwordet bliver en hash af md5(inputPassword)+inputPassword ->
07e26bd19d43dd0987d334d6c67742dc + inputPassword ->
2e6021ab04875fb7c0892e6ca95ffbad.
Ved at alle passwords hashes på samme måde sker der det at to brugere med samme password vil have identisk hash. Man kan altså uden videre finde brugere med identiske passwords.
Desuden kan man effektivt beregne hashværdien af alle ord i en ordbog og sammenholde med de lækkede hashværdier (ved at sortere begge lister af hashværdier).
Ved brug af salt bliver hashværdien forskellig hver gang, også selvom password er identisk.
Itterering som du beskriver og salting kan kombineres. Der er ingen tvivl om at det er brugen af salt som har størst effekt. Itterering gør det også sværere at bryde passwords, men har ikke nær samme effekt som salt. Desuden vil itterering gøre servicen mere sårbar overfor DoS angreb.
Et par itterationer eller fire er et fornuftigt valg til at beskytte imod evt. svagheder i hashfunktionen. Derudover vil jeg kalde det overkill da hver itteration styrker sikkerheden på et punkt og svækker den på et andet.
I dit eksempel ville man lagre MD5(MD5(password)||password). Med salt uden itterering ville man lagre salt||MD5(salt||password). Kombinerer man begge kunne man lagre salt||MD5(MD5(salt||password)||password).
Man kan blive ved med at salte i hver itteration. Jeg har ikke kendskab til om salt i hver itteration er nødvendigt, men det skulle umuligt kunne skade at blive ved med at salte. Jeg har heller ikke kendskab til om rækkefølgen man sætter værdierne sammen spiller nogen rolle. Det vil dog kun kunne gøre en forskel hvis man når op over hashfunktionens blokstørrelse. MD5 har en blokstørrelse på 64 bytes. Hvis du f.eks. har salt på 8 bytes og hash fra tidligere runde på 16 bytes kan du have op til 40 bytes i passwordet uden at overskride blokstørrelsen, og i så fald er det fuldstændigt ligegyldigt for sikkerheden om man beregner MD5(MD5(salt||password)||salt||password) eller MD5(salt||password||MD5(salt||password)).
Skulle jeg designe noget nyt i dag ville jeg dog vælge SHA512 fremfor MD5. Men resten af overvejelserne er de samme uanset valg af hash.
Mht. iteraitoner.
En fremgangsmåde jeg har set i projekter jeg er med i er et loop over 5000 iterationer, der hasher resultatet hver gang.
Kommentaren er:
"// Hash 5000 times to burn CPU cycles"
Formålet er at besvære en angribers tilgang, da alle forsøg skal hashes 5000 gange (ie. 5000 gange længere tid).
--
Vi brugte også salts.
En fremgangsmåde jeg har set i projekter jeg er med i er et loop over 5000 iterationer, der hasher resultatet hver gang.
Kommentaren er:
"// Hash 5000 times to burn CPU cycles"
Formålet er at besvære en angribers tilgang, da alle forsøg skal hashes 5000 gange (ie. 5000 gange længere tid).
--
Vi brugte også salts.
#4
Jeg kan bare ikke lade være med at tænke, at hvis salt skal genereres tilfældigt for hver ny bruger, så må saltet skulle kunne hives ud af en database, så det kan genbruges. Og kan saltet findes, så må det være lettere at knække, end hvis man først skal regne ud om der saltes eller ej.
Eller noget.
Men hvis jeg forstår det korrekt, så ligger sikkerheden ikke i at ens kode bliver ai6eikclillepeteredderkop, men istedet i at det ikke er til at vide hvordan saltet bruges?
I.e.
salt+pass+salt VS. salt+salt+pass+salt VS. salt+pass+salt+salt VS. salt+salt+salt+pass OSV., da det vil stå i kodebasen, som forhåbentlig er lidt sværere at få adgang til, end en database via et web-hul.
Jeg kan bare ikke lade være med at tænke, at hvis salt skal genereres tilfældigt for hver ny bruger, så må saltet skulle kunne hives ud af en database, så det kan genbruges. Og kan saltet findes, så må det være lettere at knække, end hvis man først skal regne ud om der saltes eller ej.
Eller noget.
Men hvis jeg forstår det korrekt, så ligger sikkerheden ikke i at ens kode bliver ai6eikclillepeteredderkop, men istedet i at det ikke er til at vide hvordan saltet bruges?
I.e.
salt+pass+salt VS. salt+salt+pass+salt VS. salt+pass+salt+salt VS. salt+salt+salt+pass OSV., da det vil stå i kodebasen, som forhåbentlig er lidt sværere at få adgang til, end en database via et web-hul.
#6, salts er tilfældigt genererede tal, så de kommer ikke fra en database. Formålet er at forhindre brugen af præberegnede tabeller (fx rainbow tables) til cracking. Det hjælper ikke angriberen at vide om der saltes (det er ikke svært at finde ud af).
Saltet gemmes sammen med det hashede password, så det er ikke som sådan hemmeligt, og behøver derfor ikke blive gemt separat. Man kan kalde det en parametrisering til den anvendte hash-algoritme.
Mht. iterationer, er der jo flere hashfunktioner der i forvejen er itereret internt i deres beregning (SHA-1 fx 80 gange). Det giver ikke nødvendigvis øget sikkerhed at iterere yderligere.
Saltet gemmes sammen med det hashede password, så det er ikke som sådan hemmeligt, og behøver derfor ikke blive gemt separat. Man kan kalde det en parametrisering til den anvendte hash-algoritme.
Mht. iterationer, er der jo flere hashfunktioner der i forvejen er itereret internt i deres beregning (SHA-1 fx 80 gange). Det giver ikke nødvendigvis øget sikkerhed at iterere yderligere.
Og alt den CPU bruges på serveren, hver eneste gang der bliver forsøgt et login.LordMike (5) skrev:Formålet er at besvære en angribers tilgang, da alle forsøg skal hashes 5000 gange (ie. 5000 gange længere tid).
Hvis f.eks. serveren har CPU kraft nok til at hashe en million gange i sekundet, og hvert loginforsøg kræver 5000 hashes, så kan serveren kun håndtere 200 loginforsøg i sekundet. Med andre ord kræver det kun 200 forespørgsler i sekundet at bringe sådan en server i knæ.
Jo flere itterationer du bruger, des nemmere er det at udføre et DoS angreb imod din webservice.
Ja, salt gemmes sammen med hashværdien.Mnc (6) skrev:Jeg kan bare ikke lade være med at tænke, at hvis salt skal genereres tilfældigt for hver ny bruger, så må saltet skulle kunne hives ud af en database, så det kan genbruges.
Alle den slags algoritmer skal designes udfra en antagelse om at de angribes af en person med komplet kendskab til algoritmen. Det vil sige de skal være sikre, hvis det eneste man ikke kender er passwords.Mnc (6) skrev:Og kan saltet findes, så må det være lettere at knække, end hvis man først skal regne ud om der saltes eller ej.
Selvfølgelig ved personen der forsøger at bryde passwords at de er saltet. Den oplysning hjælper ham ikke ret meget, han skal regne på alle de forskellige salt værdier alligevel.
Hvis du tager det konkrete læk, så tager det kun en brøkdel af et sekund at undersøge om et specifikt password er med i listen. Du vil kunne undersøge mange passwords hvert sekund.
Til sammenligning er her samme liste af lækkede passwords, hvor jeg har tilsat salt og MD5 hash: http://kasperd.net/~kasperd/linkedin-salted.zip.to...
Brugen af forskellig salt til hver eneste indgang betyder at du nu skal bruge en times tid for hvert eneste password du vil gennemsøge listen for.
Det beskytter også imod andre typer angreb som ikke kræver at man beregner noget på forhånd.cryo (7) skrev:Formålet er at forhindre brugen af præberegnede tabeller (fx rainbow tables) til cracking.
Hvis du har en liste med f.eks. 6.000.000 lækkede hashværdier og en ordbog med 100.000.000 ord, så kan du ved blot at hashe hvert enkelt ord og sortere de to lister finde ud af præcist hvilke hashes i den lækkede liste, der svarer til ord i din ordbog.
Det vil sige at med blot 100.000.000 hashberegninger har du brudt et meget stort antal brugeres passwords.
Var de lækkede passwords saltet, så ville du skulle du hashe hvert eneste ord i din ordbog 6.000.000 gange for at undersøge det samme. Dermed skal der altså bruges i alt 600.000.000.000.000 hashberegninger for at sammenligne samtlige brugeres passwords med din ordbog.
kasperd (9) skrev:Det beskytter også imod andre typer angreb som ikke kræver at man beregner noget på forhånd.
Hvis du har en liste med f.eks. 6.000.000 lækkede hashværdier og en ordbog med 100.000.000 ord, så kan du ved blot at hashe hvert enkelt ord og sortere de to lister finde ud af præcist hvilke hashes i den lækkede liste, der svarer til ord i din ordbog.
Klart nok, men "blot ved at hashe hvert enkelt ord" vil jeg nu kalde at beregne det på forhånd :p. En rainbow table kan også beregnes på stedet, hvis man har CPU-kraften til det. Pointen er dog i begge tilfælde at den ikke afhænger af de hashede passwords.
Det gør en fuldt saltet præberegnet passwordordbog naturligvis heller ikke, men sådan en er, som det efterhånden er blevet slået fast, upraktisk.
#2
Jeg er ikke enig.
Du opstiller det som at der er:
A) gode passwords som er sikre uanset brug af salt eller hash algoritme
B) dårlige passwords som ikke er sikre uanset brug af salt eller hash algoritme
Det mener jeg er for simpelt.
Der må være:
A) gode passwords som er sikre uanset brug af salt eller hash algoritme
B) la la passwords som er sikre ved brug af salt og en god hash algoritme men ikke er sikre uden brug af salt og med en outdated hash algoritme
C) dårlige passwords som ikke er sikre uanset brug af salt eller hash algoritme
Industry standard idag er brug af salt og SHA2 (SHA-224/256/384/512).
LinkedIn brugte ikke salt og SHA1.
Gruppe af folk i la la gruppen ville have været sikre hvis LinkedIn havde brugt industry standard men var ikke sikre med de valg LinkedIn havde taget.
Hvorvidt det er nok til at gøre LinkedIn erstatnings ansvarlig er en helt anden sag.
Hvis ikke LinkedIn har lovet brugerne noget specifikt, så kan jeg ikke se noget erstatningsansvar.
Jeg er ikke enig.
Du opstiller det som at der er:
A) gode passwords som er sikre uanset brug af salt eller hash algoritme
B) dårlige passwords som ikke er sikre uanset brug af salt eller hash algoritme
Det mener jeg er for simpelt.
Der må være:
A) gode passwords som er sikre uanset brug af salt eller hash algoritme
B) la la passwords som er sikre ved brug af salt og en god hash algoritme men ikke er sikre uden brug af salt og med en outdated hash algoritme
C) dårlige passwords som ikke er sikre uanset brug af salt eller hash algoritme
Industry standard idag er brug af salt og SHA2 (SHA-224/256/384/512).
LinkedIn brugte ikke salt og SHA1.
Gruppe af folk i la la gruppen ville have været sikre hvis LinkedIn havde brugt industry standard men var ikke sikre med de valg LinkedIn havde taget.
Hvorvidt det er nok til at gøre LinkedIn erstatnings ansvarlig er en helt anden sag.
Hvis ikke LinkedIn har lovet brugerne noget specifikt, så kan jeg ikke se noget erstatningsansvar.
LordMike (5) skrev:Mht. iteraitoner.
En fremgangsmåde jeg har set i projekter jeg er med i er et loop over 5000 iterationer, der hasher resultatet hver gang.
Kommentaren er:
"// Hash 5000 times to burn CPU cycles"
Formålet er at besvære en angribers tilgang, da alle forsøg skal hashes 5000 gange (ie. 5000 gange længere tid).
Det ses en del.
Men jeg er lidt skeptisk overfor ideeen.
hashe 5000 gange =>
crackeren skal bruge 5000 gange mere CPU tid
web sitet skal bruge 5000 gange mere CPU tid på at validere login
øge minimum password længde med 2 =>
crackeren skal bruge 3844 (eller mere hvis special tegn er tilladt) CPU tid
web sites skal bruge 10-25% mere CPU tid på at validere login
Det sidste er simpelthen mere effektivt.
#MD5
Jeg vil kraftigt fraråde brug af MD5.
Ganske vist er pre-image attack på MD5 stadig ikke nemme (i modsætning til collision attack hvor MD5 er totalt brudt).
Jeg har to grunde til at fraråde alligevel:
1) En praktisk. Hvis man kan søge efter MD5 i ens source code og ikke finder noget, så har man ikke et MD5 hul. Hvis man søger og for hver forekomst skal checke om brugen er et problem eller ej, så skal man bruge en masse tid.
2) Mit postulat: hvis der findes svagheder i en hash eller krypterings algoritme, så øges sandsynligheden for at yderligere svagheder findes ganske betragteligt.
For MD5 er status at collision attack er pære nemme og at man er igang med pre-image attack (nogle kinesere har allerede fundet en svaghed som reducerer kompleksiteten fra 2^128 til 2^123.4). Algoritmen er rådden.
Jeg vil kraftigt fraråde brug af MD5.
Ganske vist er pre-image attack på MD5 stadig ikke nemme (i modsætning til collision attack hvor MD5 er totalt brudt).
Jeg har to grunde til at fraråde alligevel:
1) En praktisk. Hvis man kan søge efter MD5 i ens source code og ikke finder noget, så har man ikke et MD5 hul. Hvis man søger og for hver forekomst skal checke om brugen er et problem eller ej, så skal man bruge en masse tid.
2) Mit postulat: hvis der findes svagheder i en hash eller krypterings algoritme, så øges sandsynligheden for at yderligere svagheder findes ganske betragteligt.
For MD5 er status at collision attack er pære nemme og at man er igang med pre-image attack (nogle kinesere har allerede fundet en svaghed som reducerer kompleksiteten fra 2^128 til 2^123.4). Algoritmen er rådden.
#MD5
Det var nu også bare for eksemplets skyld. Jeg har ikke lavet web udover et meget lille "kunne være meget sjovt at prøve" projekt for over 7 år siden.
Jeg lavede en "åben" tagwall med admin login (hvor password var md5 hashed) og så kunneman jeg edit/delete posts...
Basic stuff, men som sagt, bare fordi det kunne være sjovt at prøve.
Det var nu også bare for eksemplets skyld. Jeg har ikke lavet web udover et meget lille "kunne være meget sjovt at prøve" projekt for over 7 år siden.
Jeg lavede en "åben" tagwall med admin login (hvor password var md5 hashed) og så kunne
Basic stuff, men som sagt, bare fordi det kunne være sjovt at prøve.
Korrekt. Brugen af salt er den foranstaltning som gør den største forskel. Valget af hashfunktion er også relevant men ikke afgørende.arne_v (11) skrev:Industry standard idag er brug af salt og SHA2 (SHA-224/256/384/512).
Det er korrekt, dog vil jeg stadigvæk holde fast på at brugeren bærer en større del af skylden i det tilfælde.arne_v (11) skrev:Gruppe af folk i la la gruppen ville have været sikre hvis LinkedIn havde brugt industry standard men var ikke sikre med de valg LinkedIn havde taget.
Så simpelt er det desværre ikke. En passende konstruktion lagrer oplysninger om algoritme, parametre og hashværdi i en database.arne_v (14) skrev:Hvis man kan søge efter MD5 i ens source code og ikke finder noget, så har man ikke et MD5 hul. Hvis man søger og for hver forekomst skal checke om brugen er et problem eller ej, så skal man bruge en masse tid.
Når en hashfunktion viser sig at være svag holder man hurtigst muligt op med at bruge den til nye indgange i databasen. Men der vil stadigvæk være gamle indgange med den svage hash (i dette tilfælde MD5). De kan fjernes hen ad vejen, men indtil de alle er væk vil man ikke slette kildekoden til at håndtere dem.
Der er forskellige metoder til at slippe af med de gamle svage databaseindgange:
1. Opdater kun koden til oprettelse af passwords. De gamle indgange vil eksistere indtil alle brugere har ændret passwords.
2. Opdater koden til oprettelse af password. For brugere med det gamle format opdateres databasen automatisk første gang de logger på med korrekt password.
3. Lav både et nyt format og et overgangsformat. Overgangsformatet fungerer ved at lave et ekstra lag af indpakning af det gamle svage format. Opdater til nyeste format første gang brugeren logger på med korrekt password.
4. Annuller de gamle passwords og kræv at brugerne autentificerer sig med en anden metode for at ændre password.
Metode 1-3 vil alle kræve at koden til håndtering af det gamle format bevares indtil alle brugere har logget på eller skiftet password. For et site af Linkedins størrelse vil det i praksis sige at det gamle format skal understøttes i al fremtid.
Metoderne har stigende beskyttelse af brugernes password i overgangsperioden men også stigende kompleksitet.
Metode 4 giver mulighed for at slette den gamle kode øjeblikkeligt, men lider af et andet problem. I stedet for brugerens password bruges der en svagere metode til at autentificere brugeren. Det åbner op for at brugeres login kan overtages helt uden at bryde deres password.
Da et læk af passwords med den gamle svage beskyttelse udgør en trussel imod de pågældende passwords selv hvis databasen er blevet opdateret kan det være en god idé at kræve at brugerne skifter password under alle omstændigheder.
Dermed kunne en fornuftig fremgangsmåde være følgende:
1. Send email til alle brugere og bed dem om at skifte password.
2. Ved login sendes brugeren til en side hvor de kan skifte password. Der skal være et link til at bypasse siden så de ikke er tvunget til at skifte password øjeblikkeligt. Den type tvang fører til dårligere passwords. (Ved siden af linket skal der være en nedtælling af hvor mange gange det kan bruges).
3. Så snart brugeren har skiftet password opdateres databasen til det nye format.
Men selv den metode giver ingen garanti for hvor lang tid der går. Selvom du sender email ud til alle brugere vil der stadigvæk være nogle, der ikke reagerer og først et par år senere kommer tilbage til sitet og logger ind igen.
Selvom man kan skifte format er det ikke helt trivielt at håndtere. Derfor bør man bruge noget stærkt i første omgang. MD5 bør ikke bruges til noget nyt, og hvis man allerede bruger den bør man inden udgangen af 2004 have en plan klar for hvordan man udfaser brugen af MD5.
De har annulleret brugernes gamle passwords, men derved har de jo blot givet dem selv et nyt problem. De er nødt til at identificere brugerne på en anden måde. Hvordan finder man ud af om et forsøg på at tilgå en account er legitimt, hvis ikke man kan undersøge om personen kender det tilhørende password?arne_v (17) skrev:Men LinkedIn slap jo hurtigt af med dem.
Nej, men de udgør allerede en trussel imod sikkerheden. Nogle sites anvender et usikkerhedsspørgsmål, som man skal kende svaret på for at kunne anvende funktionen. Så kan man blot vælge et spørgsmål i stil med "what is my password?" og et svar i stil med "Xs1Yt0RfnVgbTqrNI1RFrVyrlLiPn2Xe". Selvfølgelig skal man ikke bruge sit rigtige password som svar på spørgsmålet, bare noget der er lige så svært at gætte. På den måde kan man som bruger beskytte sig imod den svaghed, så skal man bare huske sit password.arne_v (19) skrev:Men er det anderledes end den traditionelle "glemt password" funktionalitet som de fleste web sites har?
Så nemt som det er at nulstille et password på Linkedin vil jeg faktisk mene at for brugere der har valgt et godt password udgør muligheden for uautoriseret nulstilling af password en større risiko end lækkede password hashes.
Det er også hvad Linkedin gør. Men da det er nemmere at skaffe sig adgang til sådan en email end det er at gætte et godt password eller bryde SSL, så udgør det en reel trussel imod sikkerheden.arne_v (21) skrev:traditionelt sendes der en email med et link som skal bruges.
Man kan f.eks. forsøge at få den email sendt et andet sted hen vha. DNS poisoning. Eller man kan forsøge at skaffe sig adgang til email servicen først.
Har man skaffet sig adgang til en brugers email kan man uden videre nulstille brugerens password ved alle services som anvender en så usikker metode til nulstilling af passwords.
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