mboost-dp1
Flickr - bongo vongo
Gennem mit arbejde har efterhånden set mange kodeord, hvor jeg bare tænker HVORFOR når jeg ser dem.. nogle er simpelthen så lette at knække, uden nogle fiksfakserier, man skal bare kende personen en smule og så forsøge sig lidt frem..
Min kode er et antal tilfældige cifre som har en relevans til mig, men er så langt fra hvad folk nogensinde ville tænke på.. efterfulgt af nogle bogstaver, igen med en snæver relevans til mig... Og den har virket i 6-8 år nu, så et eller andet må jeg ha gjort rigtigt? :)
Udemærket titel, kan nikke genkendende til mange af punkterne
Min kode er et antal tilfældige cifre som har en relevans til mig, men er så langt fra hvad folk nogensinde ville tænke på.. efterfulgt af nogle bogstaver, igen med en snæver relevans til mig... Og den har virket i 6-8 år nu, så et eller andet må jeg ha gjort rigtigt? :)
Udemærket titel, kan nikke genkendende til mange af punkterne
Jeg kan godt forstå man ønsker at undgå lignende situationer som den vi så i December og noget af problematikken kunne have været undgået hvis folk havde anvendt stærkere passwords, MEN jeg synes alligevel artiklen falder lidt til jorden.
Det er nogle fine råd hvis det er koden til ens netbank man skal vælge, men her taler vi altså om en newz.dk profil.
Jeg har et password jeg bruger til den her slags profiler, der på ingen måde er kritiske eller vigtige og det primære for mig er at det password er let at huske.
Har man administratoradgang til et site bør man selvfølgelig ikke benytte det samme password man har oplyst til en masse andre siteudbydere (man kan jo reelt ikke se om ens password ligger hashed i databasen, ikke at jeg tror det ikke er tilfældet på newz, men der er massere af sider hvor det ikke er) og ej heller bør man bruge til ens email eller andre vigtige oplysninger - og ens netbank kode bør selvfølgelig ligeledes være unik og bør ikke benyttes i andre sammenhænge.
Vigtigheden af brugerkontoen er altså ret afgørende for hvor stærkt passwordet bør være. Jeg har et par få stærke passwords, som jeg bruger til vigtige ting og så har jeg et standardpassword som jeg bruger til alle de her lettere ligegyldige brugerkontier jeg har på allemulige websites.
Min brugerkonto på newz, må jeg nok desværre indrømme hører til sidstnævnte kategori - skulle den blive hacket, er det værste der kan ske at folk kan skrive indlæg og indsende nyheder i mit navn - jeg overlever nok.
Det er nogle fine råd hvis det er koden til ens netbank man skal vælge, men her taler vi altså om en newz.dk profil.
Jeg har et password jeg bruger til den her slags profiler, der på ingen måde er kritiske eller vigtige og det primære for mig er at det password er let at huske.
Har man administratoradgang til et site bør man selvfølgelig ikke benytte det samme password man har oplyst til en masse andre siteudbydere (man kan jo reelt ikke se om ens password ligger hashed i databasen, ikke at jeg tror det ikke er tilfældet på newz, men der er massere af sider hvor det ikke er) og ej heller bør man bruge til ens email eller andre vigtige oplysninger - og ens netbank kode bør selvfølgelig ligeledes være unik og bør ikke benyttes i andre sammenhænge.
Vigtigheden af brugerkontoen er altså ret afgørende for hvor stærkt passwordet bør være. Jeg har et par få stærke passwords, som jeg bruger til vigtige ting og så har jeg et standardpassword som jeg bruger til alle de her lettere ligegyldige brugerkontier jeg har på allemulige websites.
Min brugerkonto på newz, må jeg nok desværre indrømme hører til sidstnævnte kategori - skulle den blive hacket, er det værste der kan ske at folk kan skrive indlæg og indsende nyheder i mit navn - jeg overlever nok.
#2 sguft:
Der er jo intet i vejen for, at den kode, man anvender til alle mulige knap så vigtige ting, i sig selv er stærk. Og hvis du netop bruger den samme adgangskode til alle de ligegyldige ting, bør den være mulig at huske alligevel. Der er ingen grund til at adgangskoden er direkte ringe, når den også anvendes mange steder. Det er bare at gøre sig selv endnu mere sårbar.
Der er jo intet i vejen for, at den kode, man anvender til alle mulige knap så vigtige ting, i sig selv er stærk. Og hvis du netop bruger den samme adgangskode til alle de ligegyldige ting, bør den være mulig at huske alligevel. Der er ingen grund til at adgangskoden er direkte ringe, når den også anvendes mange steder. Det er bare at gøre sig selv endnu mere sårbar.
(1)
Hvordan kan et stærkt password hjælpe hvis det kan lykkes en hacker at stjæle en liste med passwords? Så er styrken på de passwords de så måtte få derfra da ret irrelevant som jeg ser det...
Det er desværre også noget, der er gået ud over jer brugere, da det er lykkedes dem at få fat i en ældre brugerliste med dertilhørende adgangskoder.
Hvordan kan et stærkt password hjælpe hvis det kan lykkes en hacker at stjæle en liste med passwords? Så er styrken på de passwords de så måtte få derfra da ret irrelevant som jeg ser det...
#3: Selvfølgelig skader det ikke, jeg mener blot det er lidt overkill at opfordre alle brugere til at skifte til stærke passwords, på baggrund af hændelsen i December.
Derudover er min pointe også lidt at mit password formentlig ligger i cleartext i databaserne på en frygtelig masse sites, fordi mange ikke hasher disse og så kan det jo være nok så stærkt hvis disse kompromiteres eller det viser sig at man ikke kan stole på ejerne bag siden.
Man kan altså lige så godt acceptere at det password man bruger til kontoer på allemulige lettere ligegyldige sider på nettet, som udgangspunkt ikke ER sikkert og den forholdsregel man bør gøre sig er derfor ikke at anvende det til noget der så at sige IKKE er ligegyldigt, f.eks. ens webmail.
Derudover er min pointe også lidt at mit password formentlig ligger i cleartext i databaserne på en frygtelig masse sites, fordi mange ikke hasher disse og så kan det jo være nok så stærkt hvis disse kompromiteres eller det viser sig at man ikke kan stole på ejerne bag siden.
Man kan altså lige så godt acceptere at det password man bruger til kontoer på allemulige lettere ligegyldige sider på nettet, som udgangspunkt ikke ER sikkert og den forholdsregel man bør gøre sig er derfor ikke at anvende det til noget der så at sige IKKE er ligegyldigt, f.eks. ens webmail.
#5 nej netop ikke når det er md5 hashed.. hvis ens kodeord er übersvagt og f.eks. står som nr. 1 på en liste over ofte brugte passwords, så er din kode knækket allerede der..
En kode, der med allerhøjeste sandsynlighed ikke bliver brugt af nogle andre, er over 8 tegn og indeholder tegn, bogstaver og tal, vil ikke blive knækket som en pind, ligesom "letmein" ville være blevet
En kode, der med allerhøjeste sandsynlighed ikke bliver brugt af nogle andre, er over 8 tegn og indeholder tegn, bogstaver og tal, vil ikke blive knækket som en pind, ligesom "letmein" ville være blevet
God idé. Jeg arbejder selv med at sikre systemer, og når man så hører hvad folk finder på at skrive har man lyst til at flå håret ud. Jeg håber at folk tager sig sammen efter det der.
Jeg har selv indført regler og validering, for at tvinge brugere til at udvide "alfabetet" i deres paswords, samt undgå dictionary hacks.
#6 Sjovt, for folk lynchede mig i en tidligere diskussion, da jeg yttrede min bekymring for netop den slags angreb, på mindre komplekse hashes, som f.eks. MD5.
Jeg har selv indført regler og validering, for at tvinge brugere til at udvide "alfabetet" i deres paswords, samt undgå dictionary hacks.
#6 Sjovt, for folk lynchede mig i en tidligere diskussion, da jeg yttrede min bekymring for netop den slags angreb, på mindre komplekse hashes, som f.eks. MD5.
#7
Det har du selvfølgelig ret i. Ligger adgangkoderne i plaintext er der ikke meget at gøre ved det. Og newz.dk-kontoen er måske ikke den vigtigste i verden.
Men ikke desto mindre synes jeg, at artiklen har sin berettigelse, da den lærer folk forskellen på gode og dårlige adgangskoder helt generelt. Du kan jo sagtens bruge artiklen til f.eks. at vælge dig en e-mail-adgangskode, netbank-adgangskode, osv.
Det har du selvfølgelig ret i. Ligger adgangkoderne i plaintext er der ikke meget at gøre ved det. Og newz.dk-kontoen er måske ikke den vigtigste i verden.
Men ikke desto mindre synes jeg, at artiklen har sin berettigelse, da den lærer folk forskellen på gode og dårlige adgangskoder helt generelt. Du kan jo sagtens bruge artiklen til f.eks. at vælge dig en e-mail-adgangskode, netbank-adgangskode, osv.
Tja, bruger SuperGenPass (søg på google) + 4 niveauer af masterpasswords. Dermed har jeg et unikt password til alle sider jeg besøger, skal kun huske fire passwords og alle alle passwords jeg bruger er på mindst 10 tegn. Kom frisk og bryd den :-p
Ud over det: fin artikel der kort og præcist forklarer hvorfor stærke passwords er et must.
Ud over det: fin artikel der kort og præcist forklarer hvorfor stærke passwords er et must.
#10: Helt enig, som jeg sagde tidligere er det en fin guide hvis det er adgangskoden til noget vigtigt man skal vælge.
Det jeg studsede lidt over var vinklingen i forhold til newz.dk brugerkonti :)
Faktum er jo nok at rigtig mange af os netop anvender det samme login og password rigtig mange steder - med mere eller mindrer tillid til folkene bag de her forskellige sites. Og det er jo ligeyldigt at newz hasher ens password, hvis Pers Debatforum ikke gør eller det viser sig at man ikke kan stole på Per - så er ens newz-login reelt også kompromiteret - uanset hvor mange forholdsregler newz så har taget for at beskytte det.
Derfor mener jeg det giver mere mening at tænke på det som sikkerhedszoner, hvor man sørger for at benytte forskellige logins til hver zone.
Det jeg studsede lidt over var vinklingen i forhold til newz.dk brugerkonti :)
Faktum er jo nok at rigtig mange af os netop anvender det samme login og password rigtig mange steder - med mere eller mindrer tillid til folkene bag de her forskellige sites. Og det er jo ligeyldigt at newz hasher ens password, hvis Pers Debatforum ikke gør eller det viser sig at man ikke kan stole på Per - så er ens newz-login reelt også kompromiteret - uanset hvor mange forholdsregler newz så har taget for at beskytte det.
Derfor mener jeg det giver mere mening at tænke på det som sikkerhedszoner, hvor man sørger for at benytte forskellige logins til hver zone.
Det kan varmt anbefales at tage et kig på
http://passwordmaker.org/
Der er Extensions og utils til praktisk taget alle browsere, og det er supernemt at generere lange og komplekse passwords til ethvert site, og man skal selv kun huske på et enkelt masterpassword (der bruges i hashingen af ens password)
Har brugt det i FireFox længe, og det fungerer prima.
http://passwordmaker.org/
Der er Extensions og utils til praktisk taget alle browsere, og det er supernemt at generere lange og komplekse passwords til ethvert site, og man skal selv kun huske på et enkelt masterpassword (der bruges i hashingen af ens password)
Har brugt det i FireFox længe, og det fungerer prima.
vfr4:LO9 er da kun et stærkt kodeord under forudsætning af, at kriminelle kun kan finde på at snuppe dit password online. Deruover mangler artiklen helt klart det afspekt sguft påpeger. Det er nødvendigt at differentiere sikkerhedsaspektet, fordi overflødigt for mange sikre passwords samtidigt øger risikoen for du glemmer dele af dem, og eller blander dem sammen.
Jeg vil nu ikke side at det er en god ide med "simple mønstre" på tastaturet som der nævnes i artiklen, så vil "qwerty" jo også være et stærkt kodeord, nogle crackere tager jo også højde for det når de laver deres "dictionary" også de mindre brugte "mønstre".
For en god ordens skyl vil jeg også lige nævne at vi i det danske alfabet har 29 tegn og ikke 28 som nævnes i artiklen (i den gamle alfabets remse med "28 skal der stå" er der ikke w med), men det er jo ikke så viktigt for forståelsen.
For en god ordens skyl vil jeg også lige nævne at vi i det danske alfabet har 29 tegn og ikke 28 som nævnes i artiklen (i den gamle alfabets remse med "28 skal der stå" er der ikke w med), men det er jo ikke så viktigt for forståelsen.
God artikel. Har lige regnet mig frem til at det vil tage over en million år at bruteforce adgangskoden til min mail. Så mangler jeg bare nogle hemmelige mails :-S
Der står i artikel, at en computer kan "hashe" 1.000.000 i sekundet. Er der nogle der kan underbygge denne påstand og af hvilken kaliber er den computer? Er det baseret på tal fra en 2,0 GHz P4 er det måske væsentligt mere idag og har man et botnet bag sig med 10.000.000 computere der hver kan lave 100.000.000 "hashes" i sekundet er situationen jo pludselig en hel anden.
Nogen der kender en ca sammenhæng mellem CPU og "hashes" pr sekund?
/EmailFX
Der står i artikel, at en computer kan "hashe" 1.000.000 i sekundet. Er der nogle der kan underbygge denne påstand og af hvilken kaliber er den computer? Er det baseret på tal fra en 2,0 GHz P4 er det måske væsentligt mere idag og har man et botnet bag sig med 10.000.000 computere der hver kan lave 100.000.000 "hashes" i sekundet er situationen jo pludselig en hel anden.
Nogen der kender en ca sammenhæng mellem CPU og "hashes" pr sekund?
/EmailFX
#17: Vi lavede en del beregninger på netop det i denne tråd som også blev lavet på baggrund af newz.dk hacket:
http://newz.dk/forum/tagwall/kunsten-at-knaekke-et...
Man kan sige det er forum versionen af den artikel :)
http://newz.dk/forum/tagwall/kunsten-at-knaekke-et...
Man kan sige det er forum versionen af den artikel :)
#15
Mønstrene kan naturligvis være for simple. "qwerty" vil f.eks. heller ikke være særlig stærk ift. afsnittene om gætbare adgangskoder og hashing.
Men man kan sagtens finde mønstre, der er så simple, at man kan huske dem, og alligevel er særdeles stærke. "vfr4:LO9" var bare et meget simpelt eksempel for demonstrationens skyld.
#17
Det var mere eller mindre bare et tal jeg greb ud af luften. Jeg syntes, at kunne huske tallet fra en adgangskodetråd på Newz et sted.
Som du selv siger med botnets, så skal man ikke tage tiden alt for bogstaveligt, da der jo er forskel på regnekraften på forskellige computere/cluster netværk. Hensigten var at omregne til tid for at vise hvor stor forskel en lille detalje i koden kan gøre, så man kunne sammenligne måneder med år i stedet for stort tal med stort tal.
Mønstrene kan naturligvis være for simple. "qwerty" vil f.eks. heller ikke være særlig stærk ift. afsnittene om gætbare adgangskoder og hashing.
Men man kan sagtens finde mønstre, der er så simple, at man kan huske dem, og alligevel er særdeles stærke. "vfr4:LO9" var bare et meget simpelt eksempel for demonstrationens skyld.
#17
Det var mere eller mindre bare et tal jeg greb ud af luften. Jeg syntes, at kunne huske tallet fra en adgangskodetråd på Newz et sted.
Som du selv siger med botnets, så skal man ikke tage tiden alt for bogstaveligt, da der jo er forskel på regnekraften på forskellige computere/cluster netværk. Hensigten var at omregne til tid for at vise hvor stor forskel en lille detalje i koden kan gøre, så man kunne sammenligne måneder med år i stedet for stort tal med stort tal.
#17
Som der står er 1.000.000 en antagelse, du vil ikke kunne regne ud vor lang til det vil tage en computer at bryde din kode da det kommer an på hvordan computeren prøver at bryde den og hvor kraftig computeren er. du kan jo ikke vide om der ved f.eks. et bruteforce angreb startes med f.eks. 0000 og tælles op eller 9999 og tælles ned (vis det eksempelvis er en 4 cifret pinkode der skal brydes)
Som der står er 1.000.000 en antagelse, du vil ikke kunne regne ud vor lang til det vil tage en computer at bryde din kode da det kommer an på hvordan computeren prøver at bryde den og hvor kraftig computeren er. du kan jo ikke vide om der ved f.eks. et bruteforce angreb startes med f.eks. 0000 og tælles op eller 9999 og tælles ned (vis det eksempelvis er en 4 cifret pinkode der skal brydes)
Jeg har 2 kommentare til noget af det folk har skrevet..
1: At newz ikke kræver en stærk kode, ja det er rigtigt nok, men problemet er jo at mange folk bruger den samme kode overalt, der var en del der var kede af at havde mistet deres mail osv. deres steamaccounts, det betyder jo bare at de har brugt ens koder overalt, artiklen viser som førsteprioritet at det faktisk kan være nemt at huske en svær kode, hvem kan ikke huske sætningen "10 SMÅ mus" hvor små er med stort? den er meget svær at bryde og er extrem nem at huske.. så hvis man har 5 af den slags er man på sikker jord..
2: Online password programmer stoler jeg desværre ikke på, jeg stoler kun på mig selv med mine koder :) og slet ikke et online program.. :)
1: At newz ikke kræver en stærk kode, ja det er rigtigt nok, men problemet er jo at mange folk bruger den samme kode overalt, der var en del der var kede af at havde mistet deres mail osv. deres steamaccounts, det betyder jo bare at de har brugt ens koder overalt, artiklen viser som førsteprioritet at det faktisk kan være nemt at huske en svær kode, hvem kan ikke huske sætningen "10 SMÅ mus" hvor små er med stort? den er meget svær at bryde og er extrem nem at huske.. så hvis man har 5 af den slags er man på sikker jord..
2: Online password programmer stoler jeg desværre ikke på, jeg stoler kun på mig selv med mine koder :) og slet ikke et online program.. :)
Mange dictionaries til angreb indeholder også leet speak versioner af ord. Sansynligvis fordi mange (nørder) tror de er sikre passwords. Det er derfor at vildlede folk at skrive at leet speak passwords er brugbare, for det er de ikke.
Dette ville man vide hvis man havde brugt bare 2 min på google med "leet password" som søgestreng.
Se f.eks. http://www.netchico.com/security/pwsec.php
Passworded "vfr4:lo9" falder for samme logik som "qwerty". Eksemplet er måske rimeligt og i hvert fald en tand bedre, men man bør undgå alle passwords som er SÅ nemme at taste ind.
Man kan være sikker på at for alle passwords, som er idiotisk nemme at taste ind, også findes en idiotisk nem algoritme som kan bruges til at hacke dem med.
Hvis man skal skrive en artikel om passwords... så bør man nok sørge for at have sine facts på plads og undgå alle former for semi-dårlige passwordmetoder.
DET' EN OMMER!
Dette ville man vide hvis man havde brugt bare 2 min på google med "leet password" som søgestreng.
Se f.eks. http://www.netchico.com/security/pwsec.php
Passworded "vfr4:lo9" falder for samme logik som "qwerty". Eksemplet er måske rimeligt og i hvert fald en tand bedre, men man bør undgå alle passwords som er SÅ nemme at taste ind.
Man kan være sikker på at for alle passwords, som er idiotisk nemme at taste ind, også findes en idiotisk nem algoritme som kan bruges til at hacke dem med.
Hvis man skal skrive en artikel om passwords... så bør man nok sørge for at have sine facts på plads og undgå alle former for semi-dårlige passwordmetoder.
DET' EN OMMER!
#22
Du overser den detalje, at leet speak er et polymorfisk sprog, hvilket betyder, at du kan skrive de samme ord på en million forskellige måder. Men kigger vi kun på de mest almindelige versioner har du ret i, at de kan være sårbare overfor dictionary attack, hvilket nok burde have været nævnt. Så jeg giver dig delvist ret i dette kritikpunkt.
Og ja, "qwerty" er principielt i samme kategori som "vfr4:lo9". Som nævnt tidligere i denne tråd, så er "vfr4:lo9" blot et simpelt eksempel for at demonstrere princippet. I praksis bør man naturligvis vælge mere komplicerede mønstre, som stadig er nemme at huske.
Du overser den detalje, at leet speak er et polymorfisk sprog, hvilket betyder, at du kan skrive de samme ord på en million forskellige måder. Men kigger vi kun på de mest almindelige versioner har du ret i, at de kan være sårbare overfor dictionary attack, hvilket nok burde have været nævnt. Så jeg giver dig delvist ret i dette kritikpunkt.
Og ja, "qwerty" er principielt i samme kategori som "vfr4:lo9". Som nævnt tidligere i denne tråd, så er "vfr4:lo9" blot et simpelt eksempel for at demonstrere princippet. I praksis bør man naturligvis vælge mere komplicerede mønstre, som stadig er nemme at huske.
Jeg vil opfordre newz.dk til at bruge salt's når de gemmer folks kodeord, det vil gøre det væsentligt sværre at lave dictionary cracking.
Kort fortalt bliver der tilføjet en tilfældig streng til alle passwords, før de bliver hashet. f.eks. kodeord = "password", salt = "Ku!l45", så bliver salt + koderod hashet md5("Ku!l45password").
Salten skal selvfølgelig gemmes i databasen også, men det betyder at et dictionary opslag ikke kan udføres, da salten er sat foran alle passwords (med mindre der generes en ny dictionary for hvert af saltene - hvilket vil være meget tidskrævende).
Mere her http://en.wikipedia.org/wiki/Salt_(cryptography)
Kort fortalt bliver der tilføjet en tilfældig streng til alle passwords, før de bliver hashet. f.eks. kodeord = "password", salt = "Ku!l45", så bliver salt + koderod hashet md5("Ku!l45password").
Salten skal selvfølgelig gemmes i databasen også, men det betyder at et dictionary opslag ikke kan udføres, da salten er sat foran alle passwords (med mindre der generes en ny dictionary for hvert af saltene - hvilket vil være meget tidskrævende).
Mere her http://en.wikipedia.org/wiki/Salt_(cryptography)
#25: Saltet skal da ikke gemmes i databasen, så er man jo ligevidt hvis man får den kompromiteret newz-style eller misforstod jeg hvad du mente med dette?
Reelt bør saltet heller ikke ligge på webserverne. Skal det være rigtig godt, skal man have en Account-server, som der kun er LAN-adgang til fra Webserverne - med en firewall imellem. Den skal så indeholde saltet og udbyde en service der kan generere hashen ud fra et password, samt validere logins.
Ligeledes bør det være delt op på databaseniveau, så loginoplysninger ligger i en seperat database, selvfølgelig med en reference til en tilsvarende tabel i den normale database der indeholder alle de ligeyldige oplysninger på en bruger. Denne seperate database er det så kun Account-serveren der har adgang til. Så selv om man får kompromitteret webserverne og derigennem får adgang til databasen, så kan man højest få adgang til brugersettings og lign.
Men jaja, det koster penge at lave denne struktur og det vil nok være overkill i forhold til et site som newz.dk, men så burde December-stuntet tilgengæld ikke kunne gentage sig :)
Reelt bør saltet heller ikke ligge på webserverne. Skal det være rigtig godt, skal man have en Account-server, som der kun er LAN-adgang til fra Webserverne - med en firewall imellem. Den skal så indeholde saltet og udbyde en service der kan generere hashen ud fra et password, samt validere logins.
Ligeledes bør det være delt op på databaseniveau, så loginoplysninger ligger i en seperat database, selvfølgelig med en reference til en tilsvarende tabel i den normale database der indeholder alle de ligeyldige oplysninger på en bruger. Denne seperate database er det så kun Account-serveren der har adgang til. Så selv om man får kompromitteret webserverne og derigennem får adgang til databasen, så kan man højest få adgang til brugersettings og lign.
Men jaja, det koster penge at lave denne struktur og det vil nok være overkill i forhold til et site som newz.dk, men så burde December-stuntet tilgengæld ikke kunne gentage sig :)
Det vigtigste er vel at man bruger et unikt password på sine emails.
Det er jo ikke verdens undergang hvis det er nogen der får adgang til en forum konto (som newz.dk), men hvis de derimod får adgang til din email, har de stort set adgang til alle de sider man er registreret på.
Det er jo ikke verdens undergang hvis det er nogen der får adgang til en forum konto (som newz.dk), men hvis de derimod får adgang til din email, har de stort set adgang til alle de sider man er registreret på.
Jeg kan ligesom #11 give min varmeste anbefaling af SuperGenPass.
Du skal kun huske ét password, men alligevel er alle dine passwords forskellige.
Så hvis nogen hacker en side kan de ikke bruge passwordet på en anden side.
Og hvis folk får adgang til din computer har de heller ikke adgang til dine passwords (medmindre din browser husker dem)
Og samtidig får du et sikkert password der ikke kan angribes af dictionary attacks.
Helt sikkert en stor anbefaling værd!
Du skal kun huske ét password, men alligevel er alle dine passwords forskellige.
Så hvis nogen hacker en side kan de ikke bruge passwordet på en anden side.
Og hvis folk får adgang til din computer har de heller ikke adgang til dine passwords (medmindre din browser husker dem)
Og samtidig får du et sikkert password der ikke kan angribes af dictionary attacks.
Helt sikkert en stor anbefaling værd!
Fin artikel - Gør det rimelig nemt for menigmand at forstå hvorfor sikre, lange passwords er vigtige.
Selv bruger jeg til min computer og mail et 19-karakterer langt password med små og store bogstaver, samt tal, så jeg ligger ikke søvnløs om natten over det ^^
Til alle de ligegyldige sites bruger jeg bare et 6-karakterer langt password, udelukkende af små bogstaver, men det gør mig heller ikke urolig, da det kun bliver brugt til sites jeg ikke er særlig aktiv på, eller bruger jævnligt.
Selv bruger jeg til min computer og mail et 19-karakterer langt password med små og store bogstaver, samt tal, så jeg ligger ikke søvnløs om natten over det ^^
Til alle de ligegyldige sites bruger jeg bare et 6-karakterer langt password, udelukkende af små bogstaver, men det gør mig heller ikke urolig, da det kun bliver brugt til sites jeg ikke er særlig aktiv på, eller bruger jævnligt.
Jeg arbejder i et stort firma, hvor de forskellige systemer har forskellige regler for hvad et gyldigt password er. Nogen af disse systemer har endda en maksumimslængde for godkendte passwords (hvilket iøvrigt er mig en gåde!)
Resultatet er, at folk umuligt kan huske deres logins til alle disse systemer, og derfor typisk har deres passwords skrevet ned på små gule sedler og lign. Og hvad gør det lige for sikkerheden? - Vi ses på grillen, morfar! ;)
Resultatet er, at folk umuligt kan huske deres logins til alle disse systemer, og derfor typisk har deres passwords skrevet ned på små gule sedler og lign. Og hvad gør det lige for sikkerheden? - Vi ses på grillen, morfar! ;)
#26 sguft:
Som forfatteren af det indlæg, du svarer på, også nævner, tjener det alligevet et formål at anvende salt, selvom man ikke begiver sig ud i det setup, du nævner. Medmindre man virkelig er ihærdig for at opnå adgang, bruger man formentlig alene dictionary attack og rainbowtabeller, og så har det altså en væsentlig værdi, da de sjældent er lange nok til at inkludere kombinationer med en salt. Det betyder, at man enten skal begive sig i gang med at brute force (eller udføre et dictionary attack) pr. konto. Det betyder også, at man nok fokuserer på privilegerede konti alene, og hvis disses brugere så anvender stærke adgangskoder, får man intet ud af angrebet.
Som forfatteren af det indlæg, du svarer på, også nævner, tjener det alligevet et formål at anvende salt, selvom man ikke begiver sig ud i det setup, du nævner. Medmindre man virkelig er ihærdig for at opnå adgang, bruger man formentlig alene dictionary attack og rainbowtabeller, og så har det altså en væsentlig værdi, da de sjældent er lange nok til at inkludere kombinationer med en salt. Det betyder, at man enten skal begive sig i gang med at brute force (eller udføre et dictionary attack) pr. konto. Det betyder også, at man nok fokuserer på privilegerede konti alene, og hvis disses brugere så anvender stærke adgangskoder, får man intet ud af angrebet.
Ved godt det ikke er optimalt men hvis nogle folk har problemer med at huske deres adgangskoder kan man evt skrive det i en sms på ens telefon og gemme den i kladder... SELVFØLGELIG uden at skrive "password til newz.dk" i beskeden... bare dit password og ikke andet. Telefonen kan selvfølgelig blive stjålet men hvordan skulle de vide hvad HvAlEr=Stor3! betyder og hvor det er til :)
#37 De fleste sony Ericsson telefoner har faktisk en udmærket kodehusker til ligepræcis sådan et formål. Det smarte er, at hvis man skriver en kode, så får man ikke at vide om den er rigtig, men telefonen generere nogle tilfældige koder. virkelig genialt fundet på :)
#diverse
Jeg synes at der er lidt usikkerhed omkring dictionary, tabeller etc..
Som jeg skrev i den tråd jace citerer:
Dictionary attack kan både være 1A og 1B.
Med brute force vil man typisk mene en 2A.
Rainbow er en speciel form for 2B, hvor man sparer plads idet man ikke behøver gemme alle plain-hash kombinationerne.
Jeg vil ikke kalde Rainbow for et dictionary attack.
Udfra de passwords der blev publiceret så er det rimeligt at antage, at TGG brugte 1A eller 1B.
Jeg synes at der er lidt usikkerhed omkring dictionary, tabeller etc..
Som jeg skrev i den tråd jace citerer:
Du kan teste passswords på 2 forskellige måder:
1) finde en liste med 100000-1000000 typiske passwords
2) systematisk generere alle mulige kombinationer af en given
længde udfra et givet tegnsæt
Du kan angribe på 2 måder:
A) udregne hash af passwords løbende
B) bruge en stor database med plain-hash og slå op i den
Dictionary attack kan både være 1A og 1B.
Med brute force vil man typisk mene en 2A.
Rainbow er en speciel form for 2B, hvor man sparer plads idet man ikke behøver gemme alle plain-hash kombinationerne.
Jeg vil ikke kalde Rainbow for et dictionary attack.
Udfra de passwords der blev publiceret så er det rimeligt at antage, at TGG brugte 1A eller 1B.
Jeg bruger selv Gibson Research Corporation (GRC) til at lave sikre password.
Brug det direkte link: Ultra High Security Password Generator
På siden beskriver Steve ganske godt teknikken bag et sikkert password, så det vil jeg undlade.
Brug det direkte link: Ultra High Security Password Generator
På siden beskriver Steve ganske godt teknikken bag et sikkert password, så det vil jeg undlade.
#26
Nej, man er ikke ligevidt selvom salt ligger i databasen. Brug af salt umuliggør brug af færdige tabeller og brug af forskellig salt per bruger gør brute force vanskeligere.
Det øger heller ikke sikkerheden at smide salt et andet sted. Hackerne har formentligt adgang til databasen via web applikationen. Web applikationen skal i sagens natur have adgang til salt.
En decideret account server øger heller ikke sikkerheden per automatik. Man har bare flyttet problemnet fra en server til en anden server. Der er (forhåbentligt) også kun LAN adgang til den generelle database server. I praksis er der dog nogle fordele ved modellen, da man nemmere kan checke koden, logge adgang o.s.v. til en lille database med et så specifikt formål.
Nej, man er ikke ligevidt selvom salt ligger i databasen. Brug af salt umuliggør brug af færdige tabeller og brug af forskellig salt per bruger gør brute force vanskeligere.
Det øger heller ikke sikkerheden at smide salt et andet sted. Hackerne har formentligt adgang til databasen via web applikationen. Web applikationen skal i sagens natur have adgang til salt.
En decideret account server øger heller ikke sikkerheden per automatik. Man har bare flyttet problemnet fra en server til en anden server. Der er (forhåbentligt) også kun LAN adgang til den generelle database server. I praksis er der dog nogle fordele ved modellen, da man nemmere kan checke koden, logge adgang o.s.v. til en lille database med et så specifikt formål.
#36: Jojo, det jeg nævner er at tage den til ekstremer, men det er noget i den stil der skal til hvis man virkelig ønsker at sikre kritiske brugerdata - det kunne eksempelvis også inkludere folks email-adresser, som næsten er mere kritiske end de hashede passwords.
Problemet med at gemme salted i databasen eller på webserveren er at bliver de kompromiteret og crackeren får adgang til dette - ja, så er eksempelvis dictionary attacks tilbage i spillet igen og så er det ret let at få fat i alle brugerkonti der anvender svage kodeord.
Har man derimod ikke det anvendte salt, ja så er man altså rimelig dårligt stilled :)
Problemet med at gemme salted i databasen eller på webserveren er at bliver de kompromiteret og crackeren får adgang til dette - ja, så er eksempelvis dictionary attacks tilbage i spillet igen og så er det ret let at få fat i alle brugerkonti der anvender svage kodeord.
Har man derimod ikke det anvendte salt, ja så er man altså rimelig dårligt stilled :)
#43: Jeg er enig i at forskellige salts pr. bruger er det man bør anvende - evt. i kombination med et fælles salt. Problemet med det brugergenerede salt er dog at den unikke oplysning for hver bruger typisk også ligger i brugertabellen sammen med password-hashen - det betyder dog at man skal angribe ét login ad gangen med et dictionary attack, så det er en klar forbedring, har man adgang til et størrer botnet kan den opgave dog ret nemt paralelliseres.
Jeg tror du misforstod et eller andet omkring det setup jeg talte om.
Hackerne har ganske rigtigt typisk adgang til databasen via et hul i webserveren, eksempelvis at folk ikke har fået opdateret PHP eller lign. Dvs. både masterdatabasen og webserveren er kompromitteret i dette tilfælde.
I normale setups vil der kun være 1 database indeholdende en brugertabel og password-hashen vil ligge i denne.
Salted vil typisk ligge i en config-fil på webserveren, eftersom den skal bruge det til at generere nye hashes og validere passwords ved login.
Da begge disse via ovenstående hul er kompromitteret er der altså fri adgang til både salted og brugernes hashede passwords, samt emailadresser.
I det setup jeg taler om er der nu 2 databaser, med hver sin brugertabel (som selvfølgelig har en 1-1 reference mellem brugerne).
Webserveren tilgår udelukkende masterdatabasen, som ikke indeholder hashede passwords eller emailkonti og webserveren har ikke adgang til det anvendte salt.
Account-servicen tilgår kun account-databasen og stiller funktioner tilrådighed for webserverne til at validere et passwordhash (ved brugerlogin) og til at generere passwordhashes som servicen knytter til brugeren i account-databasen (når brugerne ændrer deres passwords). Kun denne account-server kender til salted.
Da account-servicen ikke kan tilgåes udefra, udgør den ikke et entry-point og dermed ikke en trussel på samme måde som webserveren - derudover skal man dumme sig gevaldigt for at kode de par funktioner servicen skal tilbyde webserverne på en måde så account-servicen kan kompromiteres.
I det førnævnte eksempel med PHP-hullet vil webserveren og masterdatabasen stadig være kompromiteret, men account-serveren og account-databasen vil ikke være det. (En lille detalje er iøvrigt at det er vigtigt masterdatabasen og accountdatabasen ikke er opsat med samme brugerlogin, da login til masterdatabasen vil være nødvendigt at have liggende på webserveren)
Jeg håber det var mere forståeligt, et diagram havde nok sagt mere end 1000 ord i det her tilfælde :)
Jeg tror du misforstod et eller andet omkring det setup jeg talte om.
Hackerne har ganske rigtigt typisk adgang til databasen via et hul i webserveren, eksempelvis at folk ikke har fået opdateret PHP eller lign. Dvs. både masterdatabasen og webserveren er kompromitteret i dette tilfælde.
I normale setups vil der kun være 1 database indeholdende en brugertabel og password-hashen vil ligge i denne.
Salted vil typisk ligge i en config-fil på webserveren, eftersom den skal bruge det til at generere nye hashes og validere passwords ved login.
Da begge disse via ovenstående hul er kompromitteret er der altså fri adgang til både salted og brugernes hashede passwords, samt emailadresser.
I det setup jeg taler om er der nu 2 databaser, med hver sin brugertabel (som selvfølgelig har en 1-1 reference mellem brugerne).
Webserveren tilgår udelukkende masterdatabasen, som ikke indeholder hashede passwords eller emailkonti og webserveren har ikke adgang til det anvendte salt.
Account-servicen tilgår kun account-databasen og stiller funktioner tilrådighed for webserverne til at validere et passwordhash (ved brugerlogin) og til at generere passwordhashes som servicen knytter til brugeren i account-databasen (når brugerne ændrer deres passwords). Kun denne account-server kender til salted.
Da account-servicen ikke kan tilgåes udefra, udgør den ikke et entry-point og dermed ikke en trussel på samme måde som webserveren - derudover skal man dumme sig gevaldigt for at kode de par funktioner servicen skal tilbyde webserverne på en måde så account-servicen kan kompromiteres.
I det førnævnte eksempel med PHP-hullet vil webserveren og masterdatabasen stadig være kompromiteret, men account-serveren og account-databasen vil ikke være det. (En lille detalje er iøvrigt at det er vigtigt masterdatabasen og accountdatabasen ikke er opsat med samme brugerlogin, da login til masterdatabasen vil være nødvendigt at have liggende på webserveren)
Jeg håber det var mere forståeligt, et diagram havde nok sagt mere end 1000 ord i det her tilfælde :)
#25 Der er flere der har svaret for mig, det gør en forskel fordi det vil kræve at man lavede en ny dictionary for hver bruger, hvis der er en tilfældig salt foran.
#40 Det var også det jeg mente, men når jeg læser det igen kan jeg godt se at det kunne være svært at tyde. Men ja, en unik tilfældig streng pr bruger.
#40 Det var også det jeg mente, men når jeg læser det igen kan jeg godt se at det kunne være svært at tyde. Men ja, en unik tilfældig streng pr bruger.
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