03. maj 2005 - 13:29Der er
21 kommentarer og 3 løsninger
Hvem kan knække koden?
Jeg har lavet en login side vha JavaScript. Jeg ved ikke sikkert/usikkert det er. Jeg udlover derfor 100 point til den første som finder passordet som man skal indtaste for at komme videre fra denne side: http://www.mad-design.no/break-me.html, og forteller meg hva de gjorde for at finde passordet.
Det kan den. Ved et kik på koden ser det kraftigt ud til at du anvender en sha1 hashværdi (ac4054ba2fb720629d96d7d75dbbe4a8f3342c99) og denne kan selvfølgelig bruteforces. Hvor langt tid dette kommertil at tage afhænger helt af hvor godt dette password er. Hvis du f.eks. har valgt et engelsk ord, der står i en almindelig ordbog, vil det kunne brute forces på få sekunder, ellers tager det lidt længere tid.
Hvis du vil gøre det svære at knække koden, så skal du på en eller anden måde skjule hashærdien for brugerne. Denne behøver de jo ikke at se, det er nok at applikationen kan foretage kontrollen når brugeren indtaster sit password. Jeg vil tro at dette lettest gøres ved at lave noget server side (ASP eller PHP) hvor sammenligningen foretages af serveren på serveren (evt på et ikke web drev)
Så kan den knækkes, det er et simpelt spørgsmål om hvor meget tid der kan bruges på det. Hvis du sørger for at følgende er gældende for dit password, sikre du at det tager meget lang tid før det lykkedes:
Langt password, gerne 14 tegn eller mere. Dette er vigtigt da de fleste cracke programmer forlanger at man skriver hvor lang man forventer passwordet er. De fleste starter med 8 karaktere, der efter 10 osv. med mere end 14 karaktere tvinger du de flestecracke programmer til at gennemføre 3 eller flere forsøg.
Brug både store og små bogstaver samt tal og specialtegn i dit password.
I øvrigt tror jeg ikke engang man behøver et program til at bryde din kode. Man kan vel kopiere og modificere dit script til at kører i en lykke med kombinationer at karakterer, specialtegn og tal indtil resultatet er det samme som det der allerede står i koden. Nu er jeg ikke nogen kodehaj, men det virker relativt overkommeligt enten med javascript eller f.eks. perl
Når man surfer rundt på nettet skriver alle at den metode ksoren beskriver er alt for dårlig i forhold til serverside password protection. Der er bare ingen som skriver hvorfor serverside password protection er bedre. Er der nogen som kan forklare det, man skal jo i begge tilfælde gætte en kombination av brugernavn og password.
Det er enkelt, spørgsmålet er så om man gider have en pc ståend og ikke lave andet i 3 uger. Pointen er at hvis en hacker vil ind, så skal han nok komme det, og har han set sig tilstrækkeligt gal på dig, så bruger han jo den tid det tager. Da det password er udleveret til alle dine brugere, så er det jo ikke noget du sådan lige skifter, hvorfor det i princippet ikke gør noget at det tager 3 måneden, ind kommer man tilsidst
ludoleg, efter min bedste overbevisning er grunden til at et serverside password tjek er bedre end et clientside tjek, at i et system der kører clientside kan man bare ved at kigge på kildekoden se hvilken hashværdi man skal generere, desuden kan man på koden i dette eksempel lave et kvalificeret gæt på hvordan hashværdien bliver genereret.
Når det kører serverside er denne værdi ikke synlig for crackeren, medmindre han/hun tager helt andre metoder i brug eller programmøren kvajer sig. Desuden er det med serverside muligt at tilføje en "tilfældig" string bag på passwordet, som gør hashværdien betydeligt mere besværlig at genskabe.
Man må leve med at næsten alt man laver på nettet uanset hvor paranoid og sikkerhedsminded man er kan brydes. Det er bare et spørgsmål om tid. Den bedste måde at sikre sig på er ved at tænke sig om og vise så lidt information som muligt til den besøgende.
prom.. dit login er fornuftigt nok. Det kunne være mere sikkert med et serverside tjek, men da du ikke har adgang til det er den løsning du har lavet efter min mening fornuftig.
Det hjælper ikke noget at have filen. sha1 algoritmen er helt offentlig - men det gør det ikke lettere at knække den. Algoritmen kan ikke køres baglæns. Bruger man store og små bogstaver samt tal, er der værktøjer på nettet, der kan knække et 8-tegns ord på 3-400 dage ... who cares? :)
Nej der er ingen udfordring i den opgave det er rent et spørgsmål om tid før det rigtige password kommer frem. Man skal ikke tænke, computeren gør alt arbejdet. Hvis man kunne lærer noget, eller der på anden måde var udfordring i det, så måske
-- men det er vel tåbeligt at udlevere nøglen alligevel ...
-- og tricket med at bruge en simpel http-request til at lave en stort set u-hackeligt beskyttelse kan vel ikke laves bedre !-)
Hvordan i alverden skal en hacker finde frem til en brugernavn/password-kombination, hvis den aldrig har været offentliggjort, og du bruger en tilstrækkelig længde på den ?-)
-- hvis du beder brugere om at bruge 'sikre' brugernavne og 'sikre' password har jeg svært ved at se, hvordan det skal lykkes at afsløre, at en fil hedder 'kj43465%&478jklkJOUukvkT967vU&%¤&%¤HU870987OYUguoyt&/iæoiuOIU79087LIGgo87&hvVCHTReREg.html'
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
