34 BILLION YEARS
--
Indholdet af dette indlæg er blevet redigeret af NSA.

Hov glemte helt at nævne mit eget. Min email kode er vurderet til 3000 år. xD Andre er også meget velkomne til at dele resultater :p
--
Everyone becomes a story, be a good story.

277 TRILLION YEARS - til gengæld er den nem at huske, en lille remse. :D
--
Tjek mit nye system til at få styr på madbudgettet: http://klogpaa.dk[...] - det er gratis!

11 billiarder år. Jeg tror dog, at den der seje computer i Kina kan gøre det hurtigere. =)
--
Indholdet af dette indlæg er blevet redigeret af |Smash|.

Det er ikke kompleksitet, men længde, der afgører sikkerheden.. hejmeddigjeghedderkaj = 410 billion years yuh8hj£x28& = 5 years Selvom det første er simplere end det andet, så er det sværere at cracke. Så enten er den test komplet gak, eller også giver det stof til eftertanke! ;-)
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

Ikke om jeg sku taste mine koder i den boks da -_-
--
Signatur (valgfri)

#6 Lige min tanke. Lyder som noget man kunne finde på facebook. "Lad os lave en test, der måler hvor gode folks koder er og så snupper vi deres koder" Man kan aldrig vide på nettet :D
--

Ikke specielt sikkert åbenbart - 4 dage ....og et af mine andre passwords - 8 måneder
--

Sidst redigeret 21-01-2017 21:30

#7 Her er source code til siden: https://github.com[...]
--

#9 Men der er ingen source til hvordan et givent kodeords sikkerhed beregnes. Går ud fra, at det er et spørgsmål om CPU frekvens gange kerner divideret med 256^kodeordslængde..
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO

#0 Skriv dit password her i tråden, så kan vi andre vurdere om det er sikkert. Det giver en bedring vurdering hvis du også fortæller hvilke logins og services du bruger det til.
--

Bare lige til dem der mener at siden sender dine passwords videre... - det gør den ikke. Fint nok at være skeptisk, men ingen grund til at skrive her hvordan de behandler dit password når nu det tager 2 sek at tjekke selv og konstatere at der ikke bliver sendt noget som helst. Bare lige til reference så kan I åbne udviklerværktøjer med F12, åbne netværksfanen, genindlæse siden for at være helt sikker på at i får det hele med. rydde listen (inden I begynder at skrive password ind) og så tjekke hvad der bliver sendt frem og tilbage... -Det er trods alt ikke raketvidenskab
--
Gæstebruger, opret dit eget login og få din egen signatur.

Man skal ikke ligge så meget i de test. De har ikke så meget med virkeligheden at gøre. Det er simpelthen ikke effektivt nok med det hardware vi har til rådighed i dag. Samt har de fleste sites jo også beskyttelse mod bruteforce, ala hvis du fejler 3 gange i træk bliver din IP banned eller lignende. I stedet skal man prøve ikke at bruge det samme kodeord til forskellige services. Hvis en enkelt service bliver hacket og deres database leaket og passwords dekrypteret, bruger hackerne bare samme login information på andre services.
--
To blaze or not to blaze

#12 Det er ikke sikkert nok til at jeg vil taste mit pw ind på en side jeg ikke har tillid til.
--
Livet på jorden er kun generalprøven før premieren!! Se profil for specs

#12 - De behøver ikke sende dem nogen steder hen. De kan nemt gemmes. Og det er fint nok de har smidt source code op. Men der er ingen garanti for at det er præcis den kode de kører.
--
Bazinga! Problemer med en Admin/Moderator? Spørgsmål vedr. en tråd/et indlæg? - Send en mail til undertegnede. FFHAU!

#14 Fair nok... Du får alligevel ikke noget super godt info ud af den, og det giver højst en falsk tryghed når det kommer til stykket... Hvor lang tid det tager at brute force et password afhænger direkte af den hashing algoritme der er brugt, og når der bliver lækket data er hashingen ofte så svag at man stort set kunne have undladt den uden at det var blevet specielt meget ringere. Stærkt password + svag hashing = hurtig at bryde Middel password + stærk hashing = middel tid at bryde Stærkt password + stærk hashing = umulig at bryde lige nu Bemærk at jeg skriver lige nu, hvis ikke de services vi bruger regelmæssigt forbedrer hashing af passwords (gøres idag ofte ved at øge antallet af iterationer, dvs man hasher fx 1000 gange eller mere for at sørge for at det tager 1000 gange så lang tid at forsøge at bryde den) bliver tiden det tager at bryde dem jo kortere efterhånden som bedre hardware bliver tilgængeligt. Som en anden har sagt er det vigtigste egentlig bare at man ikke bruger det samme password overalt, for når dit password kommer i forkerte hænder, og regn med at det sker, så kan det være ligegyldigt på den service hvor "hackerne" allerede har fået hele databasen, men så får de i det mindste ikke adgang til din mail, facebook osv
--
Gæstebruger, opret dit eget login og få din egen signatur.

#15 Koden kører i din browser, så de kan gemme det i din browser, og du kan gå ind og se præcis hvad de har gemt i din browser. - hvis det skulle gemmes på deres server, var de nødt til at sende det, så simpelt er det egentlig. Det er så fint nok med kildekoden, faktum er at det der ligger på github faktisk ikke viser hvordan det bliver gjort, så det er ikke pokkers interessant om det rent faktisk er den kode de kører med... (kildekoden viser blot at de kalder ned i et andet bibliotek, som man måske kan finde hvis man gider grave videre)
--
Gæstebruger, opret dit eget login og få din egen signatur.

#17 Man kan vel godt pakke det lidt ind, så det ikke er åbenlyst, at man høster de indtastede passwords.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#0 Når du skriver "min kode" så lyder du som om at du kun har en??? Password-hygieine handler i høj grad om at minimere fallout hvis en service du bruger f.eks. opbevarer din kode usikkert. Uanset "sikkerheden" i kompleksiteten af din kode, kan du ikke gardere dig mod et en af dine yndlingsservices har fået skrevet deres password-opbevaringsmekanisme af en script-kiddie der med hans egne ord er "rimelig skrap til sikkerhed". Jeg er stødt på bruger-databaser hvor alles kode stod i klartekst :S Ideelt set bør du have unikke autogenerede koder til alle services så fallout=0 og så opbevare dem krypteret (i f.eks. en password-manager) med en kode som ikke anvendes og aldrig er blevet anvendt andre steder.. og DEN kode må meget gerne have høj entropi, for det er den eneste kode du nogensinde skal huske :)
--

Sidst redigeret 21-01-2017 23:18

#18 Man kan måske godt gøre det mindre åbenlyst, det krævede stadig bare at man kiggede efter det. Grundlæggende skal det jo sendes til serveren, men det kan selvfølgelig maskeres lidt mere end at lave et post request med det indtastede password... Den eneste måde jeg kan komme i tanke om at man kunne maskere det bare lidt, ville være hvis man gemte alle de afprøvede passwords i en cookie, og så håbede på at du gik ind på siden igen en anden gang uden at den cookie var blevet slettet... - ikke super genialt... - den henter nogle billeder, man kunne smide password med som querystreng, men det ville bare også blive meget synligt i netværksfanen... Det der er forvirringen er at folk har en tendens til at tro at når de sidder på et website så sker alt hvad de laver på sidens server, men faktisk sker meget af det i på din maskine, og alt hvad der sker på din maskine skal altså sendes til serveren hvis den skal have adgang til det, på den ene eller den anden måde.
--
Gæstebruger, opret dit eget login og få din egen signatur.

3 sextillion years - cool ord
--

32 et'taller giver 79 TRILLION YEARS Så jeg ved skam ikke hvor meget jeg "stoler" på denne tester. Koden jeg fik i folkeskolen til computerene, giver 25 NANOSECONDS Koden jeg brugte da jeg var ny på nettet er (2000ish) 2 HUNDRED MILLISECONDS Koden jeg brugte efterfølgende er 42 MINUTES Koden jeg bruger i dag er på sørgelige 8 Måneder... Jeg må til at finde på et nyt kodeord :)
--
Overclocked Haswell-Pascal Inside!
--

Sidst redigeret 22-01-2017 00:17

4 untrigintillion years for min gmail konto 64 charactere random store/smaa bogstaver og tal. jeg klare mig fint
--
Gæstebruger, opret dit eget login og få din egen signatur.

#14 Du blander lidt ting sammen. Du behoever ikke afkode hashingen hvis du bryder koden direkte ved login fasen med brute force. Hashing beskytter dig ikke imod bruteforce angreb der. hashing beskytter password imod at blive brugt andre stedet. hvis du bare brute forcer password derudover er det irrelevant hvilken hashing metode der er bare login fasen. Da login software jo netop hasher det for dig. det er i det tilfaelde at du har fundet et hul i serveren til at hive password listen ud at hashing saa beskytter imod folk der bruger det samem password here og der. Det er derfor der skal bruges salt i hashing fasen der er unikt saaledes at nar der blive brugt samme password paa server 1 og server2 at hashet ikke er det samme. men det er korrekt det er en god ide ikke at genbruge passwords
--
Gæstebruger, opret dit eget login og få din egen signatur.

Min gmail kode vil tage 182 SEXDECILLION YEARS (ifølge måleren).. Jeg har ingen anelse om det er mere end dit #23 haha.
--
Everyone becomes a story, be a good story.

Man overraskes af og til af folks naivitet. Siden beder dig om dit password og folk giver det gladeligt. Det manglede blot: få sendt resultatet til din email, facebook eller eboks med nøglekort ;) Lad vær, for mig at se er det blot en online wordlist generator hvor inputtet kan sælges videre på det sorte marked. Til de der allerede har indtastet kode, få den hellere skiftet eller brug 2-faktor i det midste.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#24 Det er ikke helt rigtigt, for en stor del af pointen med en god algoritme til password hashing er at den skal være så langsom at det begrænset antallet af kombinationer du kan prøve. Serveren hasher på fuldstændig samme måde som du ville gøre hvis du havde password listen,bortset fra at serveren nok også har andet og lave, og ikke er optimeret til password hashing (når man brute forcer bruger man faktisk normalt grafikkortet idag) -forhåbentlig er det en teknisk detalje dog, for det er jo en sikkerhedsbrist hvis man tillader brute force igennem sin login formular. En stærk hashing algoritme vil altså uanset om det gøres på serveren eller du har fået fat i password listen gøre at det tager meget længere tid at prøve mange kombinationer, og det beskytter jo selvsagt hvis dit password er stærkt nok til at det ikke bliver gættet lige med det samme.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Haha, sjov tråd. Som om der er nogle herinde der sidder og taster 40-70 vilkårlige karakterer ind hver gang de skal ind på deres mail. Eller I har måske fået Google til at huske koden for jer via auto-fill?
--
Note: "DJ" har ikke noget med "disc jockey" at gøre :D Det er bare tilfældigvis, forbogstaverne fra mit mellem og efternavn.

Hmm.. Baloney1 er åbentbart ikke et godt kodeord. "Used to be just Baloney, but then they make you add nuuumber.... Ygh... "
--
"Facts are meaningless - you could use facts to prove anything that's even remotely true!" - Homer J Simpson.

#27, Ved at HASH har kun til formål ikke at ligge password i klartekst. Det er en envejs-algoritme, så med HASH værdien kan du ikke som udgangspunkt finde passwordet. Du kan dog sende wordlist i skyen og generere Rainbow tables af den givende HASH algoritme. Så er du tilbage ved udgangspunktet, da der så vil være et match. Du skal indsætte et SALT for at forhindre bruteforce af HASH og naturligvis afvise mange logins. Det hjælper dog intet ved databasen bliver lækket som er set mange gange det sidste års tid. Det input brugerne ved given password hjemmeside, kan herefter sendes i skyen for at generere Rainbow tables. Disse kan køres op imod lækket databaser med hash-værdier og ved match er brugeren komprimiteret ;)
--
Gæstebruger, opret dit eget login og få din egen signatur.

#30 Din viden er forældet, hash og salt er langt fra nok i dag og ranbow tables er nærmest uddøde. Salt har iøvrigt kun værdi når en hel database er lækket, for uden salt vil man med det samme spotte at folk med ens password har ens hash, det ændrer intet så længe databasen ikke er lækkert... -det er vel at mærke helt generelt, værdien af hashing af passwords er reelt kun til stede når databasen er lækket.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#31, HASH har nu også en stor værdi internt i virksomheden, da du ikke kan se password i klar tekst og dermed bedre kan sikre dine systemer. Mennesket er nu engang det svageste led ;) Så hvad mener du der bruges i dag, hvis en database er lækket og kun er brugt HASH? Vil du beregne HASH værdien på egen server? Hvilken ny teknologi er kommet til? :)
--
Gæstebruger, opret dit eget login og få din egen signatur.

#32 Mig bekendt er det ikke ny teknologi, men blot gamle ting man er begyndt at bruge anderledes. Bcrypt vinder frem, men mig bekendt anbefaler man stadig at bruge PBKDF2 med HMAC-SHA256... -og så kan jeg se at man idag siger 128 bit salt, 256 bit subkey og 10000 iterationer. Rainbow tables blev outdated dels fordi man begyndte at bruge salt, som du selv er inde på, og dels fordi man idag altid bruger (hvis man ellers gør det bare halvt ordentligt, vi skal ikke tage fejl af at langt de fleste sider på nettet har skod elendig sikkerhed) en "adaptive" algoritme hvor man kan øge antallet af iterationer og så faktisk også fordi at vores hardware er blevet så hurtig at hvis hash algoritmen er svag og der intet salt er, tager det ingen tid at knække, mens rainbow tables fylder enormt meget. (Husk på rainbow tables er baseret på at man har et password til samtlige mulige salts, hvilket dybest set kun virker ved svage algoritmer der har et begrænset antal outputs) -man knækker vel at mærke normalt ikke alle passwords, men det vil typisk være noget i retningen af at man på næsten ingen tid har 80% og så kan man vurdere derfra hvor stor en andel man mener er værd at få i forhold til hvor lang tid de sidste tager.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Sorry, jeg skrev samtlige mulige salts, jeg mente naturligvis samtlige mulige hashes... -det andet var noget sludder
--
Gæstebruger, opret dit eget login og få din egen signatur.

Mine passwords er så sikre at jeg har programmer til at huske dem ;)
--

Arbejder med rigtig mange logins og koder til dagligt og har lige været på et fint IT-grundsikkerhedskursus i hvordan man undgår at gøre det for nemt for de kriminelle. Det meste er jo rationelt hvis man i forvejen er teknologisk uddannet med alligevel :-) - Jo længere passwordet er jo bedre (bruger selv minimum 10 karakterer) - Brug alle tænkelige karakterer (tegn, store og små bogstaver og tal) - Brug ikke noget andre ved om dig (alder, fødselsdato, navne, fødested osv) - Brug evt en password manager eller nogle huskeremser baseret på noget kun du ved for at kunne huske dine passwords Tastede ikke mine passwords ind men nogle der ligner. 118 billion years. :-D
--
Trust me.. I'm an engineer

Testen modsiger sig selv, og er latterlig. Nu prøved ejeg ikke mit eget password men et med lignende længde. Det ser ud til den vurderer ud fra længde, og ikke kompleksitet som folk også er inde på her. It would take a computer about 3 THOUSAND YEARS to crack your password. This is a very common pattern and would be cracked very quickly. Jeg synes ikke 3000 år er meget hurtigt.
--
Nu uden signatur :O
--

Sidst redigeret 22-01-2017 14:44

Ved ikke helt hvor mange år det er, men det lyder af mange "1 SEXTILLION YEARS"
--

#24 Jeg blander ikke ting sammen. Du læste bare min kommentar forkert.
--
To blaze or not to blaze

#37 Komplekse kodeord er svære at gætte sig frem til for et menneske. "123abc" er let at gætte ift "a5Gx$m". Når det kommer til et "brute force" cracking forsøg, er det længden af kodeordet (eller den benyttede HASH), der afgører sikkerheden - uanset kompleksiteten, og derfor er de to ovennævnte kodeord i den forbindelse lige (u)sikre. At én computer skal bruge 3000 år på at cracke en kode, er ikke ensbetydende med at det er den tid, det som minimum tager. Supercomputere, eller netværk af flere computere der samarbejder, kan knække koden meget hurtigere. 3000 computere skal bruge et år, 30000 skal bruge ca. en måned etc. Så tallet kan udelukkende bruges til at finde ud af, hvor sikkert et password er ift. et andet ifm. et brute force angreb foretaget af én computer - ikke en skid andet :)
--
http://xlinx.dk[...] i7 2600K, 16GB PC3-12800, GA-X68XP-UD4 R1, GTX 560Ti HAWK, 250GB 840 EVO
--

Sidst redigeret 22-01-2017 15:10

#40 Det var også min tanke, Nitroblast :p Men det tror jeg folk har i baghovedet
--
Everyone becomes a story, be a good story.

It would take a computer about336 sextillion yearsto crack your password
--

#37 Kompleksitet spiller ingen rolle i et brute force-angreb på dit kodeord.
--

#24 Det er korrekt at det skal tage en hvis tid at bryde hashing . men du misser pointing hvis du vil brute force password bryder du ikke hashet. Hvis jeg sider og brute forcer kodeord ind paa hol.dk saa laver hol.dk jo hashing for mig. hashing er ikek for at bruteforce adgang. hashing er til for at sikre kodeorde kan sive ud. og i det tilfadle skal vi have en haard hash. For login bruteforce og en sloev hash kan det samme udfore med en langsommer login server. det det ene din langsomerm ash goer her at at goere bruteforce af kodeord langsommer paa serveren.. det er med andre ord ikke et load det kommer hos mig men hos hol.dk. men har jeg hevet en hashet password liste ud. og skal bryde den igennem hos mig for at finde password jeg kan bruge andre stedet saa ligger loadet hos mig. #30 Det er noget sluder at sige salt kun er vigtige ved en hel data base uden salt kan vi blot sammenligne hashet med i tabel over typiske brugte idiot password og muligvisis finde dne hurtige her. salt kommer ind og goer at der nu skal alve en tabel over for all komibnation af salt de vi paa forhaand ikke kender saltet. saa entne skal du lave et have a forbedrels mht til salted/hashed password eller ogsaa skal vi hive listen ned og derved ogsaa salte og saa begynder et lege hashing Igen det er et spoergsmal om at flytte loadet rundt til at man ikke kan vare forbedret det er dog korrekt at slat naar det er unikt per bruge ogsaa hjaelper paa at man ikke kann se hvilket folk der har det samme password saa nemt og samtidigt ikek bruge dne viden ti lat udrene at netop det hash er nok et idiot password. Kort fortalt salt: goer det vaenselig tunger bare at verifire imod et hash og se om man har "Gaettet" passwordet under hashet hvad enten det er en database elelr bare et password
--
Gæstebruger, opret dit eget login og få din egen signatur.

#5 Det er lidt sjovt. Jeg har lavede lige testen i Password Depot, som også estimerer hvor hurtigt en kode kan brydes. Der er resultaterne: hejmeddigjeghedderkaj = 186 years yuh8hj£x28& = 138 million years
--
http://hamdentykke.dk[...]

It would take a computer about 3 MILLION YEARS to crack your password
--
Yep

det virker mere som om, at det er længden af ens kode der er afgørende, og ikke så meget om det er fyldt med tal, tegn og så videre... pt bliver de fleste logins jo alligevel "hacket" af andre, fordi ens kode er nem at gætte, eller fordi systemets database er blevet hacket (ligesom yahoo fik hacket en million brugeres email og passwords for ikke så længe siden) - eller hvis man har været en hat og fået en keylogger eller lign. og hacking og keylogging er lidt ligeglade med om ens kode er "nem at gætte" eller "sikker"
--

Dit password er useless hvis du bruger det på mere end 1 site. Hvis site A bliver knækket eller ikke er secure har de også adgang til site B. Derfor er det også anbefalet at man bruger forskellige Usernames. Så kan de ikke så nemt koble ens bruger sammen til adskillige sites. Problemet er bare idag, at en username ofte også er ens Email, hvilket betyder man skal have mange emails for at kunne bruge forskellig til alle steder man logger ind. Personlig er jeg oppe på en slant email / passwords jeg skal huske.
--
Yep

#38 Det danske navn er trilliard eller 10^21 (1 000 000 000 000 000 000 000) eller ettusinde år gange én million år gange én million år gange én million år. Altså ret mange år. Flere år end du når at tælle, inden du dør, hvis du starter nu. Der var også en reklame for Merlin(?) engang. De havde en million-milliard gode råd - Det lyder af mange, men det giver kun en billiard. For at ramme en trilliard er du altså nødt til at gange en milliard med en billion (eller en million million). Al den snak om tid er dog ligegyldigt, fordi der er altid en asiat der er smartere end dig. Så hvis ikke deres fantastisk hurtige computer får tvunget sig adgang, ja så finder de bare ud af at få din kode på en anden måde.
--
Indholdet af dette indlæg er blevet redigeret af |Smash|.

Min kode "abe123456" var ikke sikker nikke nej
--