Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Jo.. Nu var det mere om hvis der sker en fejl hos klienten.. altså at klient ikke har javascript slået til.. så vil den jo sende klientens rigtige password, det er jo ikke så smart..
Jeg skal bare være helt sikker på at klienten ikke kan logge ind hvis script ikke virker.. kan man ikke det ?
Hvis klientens javascript ikke virker, eller er slået fra, så kan han ikke logge ind - er det et problem?
Du ved også godt, at der ikke er synderlig meget sikkerhed i løsninger baseret på javascript. Hvis du vil opnå at et password ikke sendes i klar tekst over nettet, skal du over i løsninger med https://
Ja jeg er godt klar over at ssl er den rigtige løsning.. men hvis "firma" ikke vil betale for det, og alivel gerne vil have bare lidt sikkerhed så kan jeg ikke udmilbart ikke se anden løsning..
Nu ved jeg jo ikke hvad firmaet egentlig vil, men når de "gerne vil have bare lidt sikkerhed", så er det vel til dig at fortælle dem, at der ikke rigtig er noget sikkerhed i det her, og få noteret det, så du ikke har et ansvar for en løsning, der i sidste ende ikke dur.
Jamen det gør den heller ikke.. problemet er mere at den alivel sender det password som brugeren har skrevet.. og det er jo det som skal sikres på bedst vis.. :D
erikjacobsen.. Hvad er så bedst.. at sende password i rå form eller gennem en sha1-nøgle ??
w13.. det er også fint nok at tjekke om sha1(password)==password.. men hvad hjælper det hvis script ikke virker så poster den jo alivel password i rå form!!
Det eneste vi kan levere er små hacks for at prøve at undgå de fleste tilfælde af, at passwordet sendes i klar tekst over nettet. Der vil aldrig være nogen garanti.
Eet hack, der formentlig klarer det når javascript er helt slået fra: Lav password feltet "hidden" med css fra starten, og gør det synligt igen, som det sidste på siden, når din <form> vises. Hvis der er noget galt med javascript på klienten, vil password feltet sandsynligvis ikke blive vist, og dermed kan en almindelig bruger ikke indtaste noget.
Men det er bare et lille hack. Jeg håber Nationalbanken bruger andre metoder ;)
Jamen har du tjekket, om den poster, når man slår JavaScript fra? For så mener jeg ikke, at den burde poste, når du gør det sådan.
Ellers så må du vel ud i at undgå brugen af <form> og så med JavaScript sende formdata videre.
Ellers er der vist ikke så meget andet at gøre. JavaScript er ikke særlig sikkert, og hvis man slår det fra, når man logger sig ind, kan man risikere at få stjålet sine oplysninger.
Jeg tror coder.dk har læst det, men blot vil bekræfte, at det er den "eneste" løsning.
Java og flash virker selvfølgelig kun når de virker, men lider af samme skavank som spørgerens javascript/sha1-metode, det sendte kan opsnappes, og selv sha1 kan så nemt som ingenting brydes, hvis brugeren har valgt et for simpelt password.
Hvis kunden skal have høj sikkerhed, og ikke vil betale for SSL (https://), så må du som professionel udvikler gå tilbage til dem og sige: "Nej, det kan ikke lade sig gøre". (Det sædvanlige forbehold: jeg ved ikke hvad firmaet egentlig har behov for).
Hvis javascript er slået til sendes det krypterede password, hvis det ikke er slået til sendes det ukrypterede. Fint nok så langt.
MEN ... der er altså bare ikke nogen væsentlig øget sikkerhed ved at det sendes krypteret. Hvis der er en hackertype som opsnapper passwordet, krypteret eller ej, så kan hun logge ind siden uden nogen problemer. Om ikke andet kan hun jo simpelthen bare sende det krypterede password (uden at behøve at kende det oprindelige password).
Det eneste beskyttelse der er imod selve opsnapningen er ... ja det er allerede blevet nævnt. :^)
Nielle - i det konkrete tilfælde, ja. Men det er ikke noget problem, som spørgeren henviser til i sit link http://vbhansen.dk/javascript/challenge_response/ , at sørge for man ikke kan lave et replay.
Og ret beset: prisen for at have et SSL-certifikat, med tilhørende serverløsning, der kan klare det, svarer ikke til ret mange udviklertimer. Der er simpelthen penge at spare ved at vælge den rigtige og sikre løsning. Under den forudsætning, at sikkerhed faktisk er vigtigt for firmaet, så ligner hele dette spørgsmål en absurd diskussion.
Ja SSL er helt klart den bedste løsning.. Men nu er det som sådan ikke en offentlig-side som gud og hver mand skal bruge.. Det er kun en side for firma's medarbejder.. Men de skal kunne komme ind på siden hvis de fx. sidder i toget eller på biblioteket.. og hvad logger de af sjove ting.. Så det er kun for at beskytte brugeren's password mod at administrator skal kunne se password med det blåte øje..
Ja.. men så kommer problemet med at medarbejder har mulighed for at logind boksen kan huske deres brugernavn og adgangskode og den mulighed må brugeren ikke have.. Hvis man ikke kan huske sit brugernavn og adgangskode så er det bare synd.. :D
Men nu har jeg lavet det sådan at den ikke viser log ind boksen hvis Javascript ikke er slået til..
sjh >> Hvis du 'låser' din cykel ved at binde den med et stykke sejlgarn, kan du vælge mellem et hav af forskellige knuder - og mange forskellige emner at binde den fast til.
Du kan binde den fast til en sammenkrøllet avis på fortorvet - eller et solidt nedløbsrør i hærdet chromevanadium stål. Du kan binde den fast med en kællingeknude, et dobbelt halvstik med rundtørn om egen part eller et tyrkisk sækkebåndsknob.
Uanset, hvad du gør, 'låser' du den med et stykke sejlgarn, og så er resten rystende ligegyldigt. Sejlgarnets styrke bliver styrken for hele systemet ;o)
og jeg kan også godt se at min løsning ikke er lige så god som SSL.
men, hvis jeg skal vælge mellem at låse min cykel med en lille lås som vil være nem at klippe over.. eller med en stor lås som vil være svær at klippe over..
Så må det vel være den store lås.. altså den krypteringsmåde som tager længer tid at afkrypter. ?
Nuvel, men teknologier som SSL er gennemprøvede og under konstant, global 'test'.
Vores hjemmestrikkede patchwork tæpper er derimod ofte udført med masser af hulmasker, fordi vi ikke besider hackeres viden og erfaring, og fordi vores kreativitet grundlæggende har et andet fokus. Hvis vores eget 'skidt' skal fungere, skal vi tænke foran hackeren - og det er præcis dér, det _altid_ går galt ... for det kan du roligt regne med, det før eller siden gør.
Din opgave er for mig at se ikke at lave dette projekt, men at forklare kunden, at det naturligvis ikke skal laves.
Hvis en gæst på en restaurant insisterer på en salmonellabombe, bestående af en blandet svine-/kyllingetatar med tre rå æggeblommer, bør kokken naturligvis nægte at lave en ret, der med overvejende sikkerhed resulterer i en - i bedste fald - dødsyg kunde. Hvis kokken besidder blot rudimenter af faglig stolthed, vil han naturligvis aldrig få en anden tanke. Ellers ville det jo være umuligt for ham at bevare sin selvrespekt.
Somme tider kan man godt blive lidt forfærdet over, hvor stor forskel der er på kokkes og webfolks faglighed =)
- og "Kunden har altid ret" gælder ikke indenfor webkodning (og mange andre fag). Det kræver nemlig som minimum, at kunden har forstand på det, hun taler om
En ting jeg ikke lige kan se når i snakker om at det vil kunne afkrypters (nemt) er.. Man skal jo også kende "uniqid" for at kunne afkrypter den og den nøgle kender kun serveren. ;)
Lad os sige vi opsnapper kommunikationen fra din <form> til serveren. Derefter prøver vi med simple password (dictionary-attack), om vi kan få samme sha1-værdier. Der giver selvfølgelig ikke gevinst hver gang.
erikjacobsen: Jo.. men det vil du jo også kunne teste på en side med SSL ? Det vil sige man kan tætte sig til et password.. ja det kan man jo alle steder..
På en SSL-side: nej. Det er et ekstra lag af kryptering som reelt gør det umuligt for mig at læse hvad der sendes (hvis krypteringen er valgt tilstrækkelig stærk mellem server og klient: masser af bits).
Hvis jeg har adgang til data før afsendelsen fra browseren, eller efter modtagelsen på serveren, så er SSL selvfølgelig ligemeget.
Nu skal jeg ikke være nysgerrig, ret meget i hvert fald, men det er en lidt sjov problemstilling: "Så det er kun for at beskytte brugeren's password mod at administrator skal kunne se password med det blåte øje". Administratorer glemmer man tit i opstilling af trusler, så det er fint han er med her. Men det spøjse er, at han opfattes som den eneste trussel.
Ja jeg ved godt at man ikke kan læse den data som sendes mellem klient og server men du kan da gå ind på samme side og teste med nogle password og se om der er gevinst..
Det er selfølige ikke kun Administratorer som vil kunne opsnuse data.. men det vil nok være den som har næmest ved at fange dataen da det jo er deres net der benyttes..
og jeg tenker ikke på keylogger.. for så er brugeren jo helt ud og skide :D
Netop, når vi har modforholdsreglerne mod brute force eller dictonary angreb fremme, er din kode et meget godt eksempel på det, jeg skrev før om at 'tænke foran hackeren'.
Lav som minimum _altid_ en forsinkelse på et halvt til et helt sekund i et login script. Det er noget af det mest deprimerende at møde, hvis man forsøger at brute force sig igennem. http://dk2.php.net/manual/en/function.sleep.php
Det er bare én ting ... så mangler du 'kun' de 23.037 andre ting, du bør gøre for at tage højde for hacking af din applikation ;o)
- og hvis du kun kommer i tanker om de 23.036, er det stadig et stykke sejlgarn, du forsøger at tøjre serveren med ... og i morgen er der forøvrigt 23.040 at tage stilling til
Det er lidt ligesom at validere data ved brugerinput. Hvis du tjekker en streng op mod, hvad der er forbudt, er du som regel på spanden. I stedet bør du helt klart definere, hvad der er tilladt og sikre dig, strengen _kun_ består af det. Du skal altid regne med, du ikke kan overskue, hvad der bør forbydes. Igen fordi du ikke kan regne med at kunne 'tænke foran' alverdens kreative hackere.
Ja vi kommer selvfølige ikke uden om at SSL er det bedste at bruge..
Men Jeg vil da heller benytte et log ind system som benytter SHA1 nøgler frem for at benytte en standard form som bare sender den tekst jeg skriver i input-felterne..
Og selv om vi forsøger at være morsomme, så er det faktisk en god sammenligning: jeg har i hvert fald en cykel, der er så gammel og rusten, at lidt sejlgarn vil være rigeligt til at sikre den. Man kan ikke sige at noget er sikkert uden i det mindste at forholde sig til et par ting (minimum):
1) Hvad er truslerne? 2) Hvor meget vil vi ofre af penge og besvær på sikkerhed?
Det ville være formålsløst for mig at låse bemeldte cykel, og derefter forankre den med 2 kædelåse til den eller de nærmeste gadelygter, samt ringe til min ven i PET, der kommer med og passer på den, mens jeg er inde og købe en æske gajol.
Nej, det er utroligt nemt at bryde en SHA1-kryptering, hvis det password der ligger bag er for simpelt. Og hvis man kan lave en replay, er dekryptering ligegyldigt.
Man kan aldrig sige at noget er sikkert, bare fordi man bruger SHA1.
erikjacobsen : "Man kan aldrig sige at noget er sikkert" DET GØR JEG HELLER IKKE! Det samme med SSL <- Man kan aldrig sige at noget er sikkert. Det er SSL heller ikke!
erikjacobsen : Og nu siger du godt nok at det er utroligt nemt at bryde en SHA1-kryptering.. Ja det er det da HVIS man har kendskab til hvordan SHA1 virker.. Prøv du at tag en søgning på MD5 under PHP og se hvor mange som har fattet iden med den!
"Og nu siger du godt nok at det er utroligt nemt at bryde en SHA1-kryptering" - det har jeg nu aldrig sagt. Og "Social Engineering" er et kapitel for sig ;)
Nej.. og nu var det heller ikke lige det mit spørgsmål gik ud på.. men det er da en god ide at I kommer med sådan råd.. det kunne jo være jeg ikke var klar over at der også var noget som hed SSL.. men det gør jeg.. :D
Lige et kort spørgsmål med hensyn til SSL. Kan man købet et SSL certifikat hvis det ikke skal bruges på et domæne, altså et som går på en ip-adresse. ?
Jo, det burde være muligt for en udsteder at lade dit common name være din IP... Du kan i hvert tilfælde godt, hvis du selv udsteder/genererer SSL-certs... Hvis det er til intern brug i et firma, så kan du jo bare selv lave et certifikat - så får de bare en warning hvis du ikke er i deres root... I øvrigt kan der pga måden SSL fungerer på, kun være ét SSL-cert per IP-adresse (på standardporten)...
hæ hæ, Ja jeg skal ikke lokke nogle til at benytter et certifikat som viser warning.. de kunne jo tro at det så er meget normalt at det skal se sådan ud hvis de en gang kommer ind på en snyde side :D
Når det ser kun ud til at det er Ole som vil have point..
Mange tak for jeres store hjælp..
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
