Metoden er nærmest standard.

Med linkedin er der en lille krølle - man kan nemlig registrere flere email adresser og alle får en notifikation når password ændres.

traditionelt sendes der en email med et link som skal bruges.arne_v (#21)

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.

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.

Nu ved jeg faktisk ikke hvordan LinkedIn håndterer glemt password, men traditionelt sendes der en email med et link som skal bruges.

Men er det anderledes end den traditionelle "glemt password" funktionalitet som de fleste web sites har?arne_v (#19)

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.

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.

Men er det anderledes end den traditionelle "glemt password" funktionalitet som de fleste web sites har?

Men LinkedIn slap jo hurtigt af med dem.arne_v (#17)

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?

Der er naturligvis ekstra problemer i forbindlese med eksisterende passwords.

Men LinkedIn slap jo hurtigt af med dem.

Industry standard idag er brug af salt og SHA2 (SHA-224/256/384/512).arne_v (#11)

Korrekt. Brugen af salt er den foranstaltning som gør den største forskel. Valget af hashfunktion er også relevant men ikke afgørende.

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.arne_v (#11)

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.

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.arne_v (#14)

Så simpelt er det desværre ikke. En passende konstruktion lagrer oplysninger om algoritme, parametre og hashværdi i en database.

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.

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 man jeg edit/delete posts...
Basic stuff, men som sagt, bare fordi det kunne være sjovt at prøve.

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.