mboost-dp1
Flickr - bongo vongo
Adagio (50) skrev:Det er rigtigt nok, men det vil så altid være sikrere at smide ET tegn mere OG sørge for at der er forskel på store og små bogstaver
Ja, og endnu sikrere at have mindst en million tegn.
Sikkerhed er et kompromis. På et eller andet tidspunkt bliver det for dyrt eller besværligt at gøre det sikrere. Det skal være sikkert NOK.
Her har man valgt at et A er et A, uanset om det er stort eller småt, for det er der mange der forventer. Og så har man set bort fra en række specialtegn, da de kommer med sine problemer. Med de tegn der så er tilbage, har man valgt en minimumlængde som er lang nok. Og det er bla. vurderet ud fra at der ikke er mulighed for at brute force uden adgang til de hashede passwords, og de hashede password er temmeligt godt beskyttede, og skulle man få fat i dem er de formentligt hashet bedre end man gør på de fleste hjemmesider. (Dvs. med salt osv.)
myplacedk (51) skrev:Ja, og endnu sikrere at have mindst en million tegn.
Sikkerhed er et kompromis. På et eller andet tidspunkt bliver det for dyrt eller besværligt at gøre det sikrere.
Det vil ikke gøre det dyrere at sætte systemet op til at den kan se at der er forskel på a og A og det vil ikke være mere besværligt at bruge, så den undskyldning holder altså ikke en meter
Adagio (52) skrev:Det vil ikke gøre det dyrere at sætte systemet op til at den kan se at der er forskel på a og A
Det er korrekt, jeg generaliserede for at vise hvor normalt det er.
Adagio (52) skrev:og det vil ikke være mere besværligt at bruge,
...siger du. Ikke alle er enige. Mange mener at "A" og "a" er samme bogstav, og forventer at kodeord også virker sådan. Da NemID ikke er noget man bare lige kan fravælge, er man nødt til at tage hensyn til alle.
Adagio (52) skrev:og det vil ikke være mere besværligt at bruge,
myplacedk (53) skrev:Mange mener at "A" og "a" er samme bogstav, og forventer at kodeord også virker sådan.
Det er slet ikke naturligt at der er forskel på store og små bogstaver ved sammenligning.
I de fleste non-computer sammenhænge f.eks. ordbøger og leksikoner anses de for ens.
For kommandoer og filnavne i de fleste styresystemer anses de for ens. Undtagelsen er *nix.
For navne i de fleste programmeringssprog anses de for ens. Undtagelsen er C familien (C, C++, Java, C# etc.).
Lalalalalalala ... eller noget :)arne_v (56) skrev:Der findes f.eks. et non-*nix styresystem fra et firma i Redmond USA som har opnået en vis udbredelse på PC'ere.
Det meste af det fiktive OS er vel også skrevet i C familien og NTFS er vist case sensitive. Men det er en hel anden snak, NemID bør se forskel på A og a.
dub (57) skrev:og NTFS er vist case sensitive
NTFS kan supportere case sensitivitet, men under Windows er det ikke case sensitivt - kun case preserving.
dub (57) skrev:NemID bør se forskel på A og a.
Det er der visse gode tekniske grunde til.
Men pointen er at en masse mennesker er vant til at det ikke er tilfældet.
Der er lavet en prioritering mellem lidt ekstra sikkerhed og at gøre det nemt for dem som ikke helt har styr på om caps lock er on.
Hvis passwordet nogensinde når frem til SQL niveauet, så er systemet lavet forkert. Det skal jo netop sendes igennem en hash funktion før det overhovedet sammenlignes. På det tidspunkt skal der fortages en case sensitive sammenligning, fordi ellers vil det blot betyde at man ignorerer ca. en ud af hver 39 bits i hash værdien.doctorx (48) skrev:Strengsammenligning på MS SQL-server
Det kunne man sagtens håndtere med et case sensitive password.arne_v (58) skrev:Der er lavet en prioritering mellem lidt ekstra sikkerhed og at gøre det nemt for dem som ikke helt har styr på om caps lock er on.
For eksempel kunne man prøve med det password, som blev indtastet, og tilsvarende hvor samtlige bogstaver er ændret mellem store og små. Hvis passwordet f.eks. indeholdte 6 bogstaver ville det sige, at 2 ud af de 64 muligheder for valg af store og små bogstaver blev accepteret. Det burde være mere sikkert end at acceptere alle 64.
Desuden kan man jo ikke nødvendigvis bruge de almindelige funktioner i ens programmeringssprog til at konvertere imellem store og små bogstaver, da det ikke er til at vide hvordan de håndterer æ, ø, og å. At lave en generel funktion, som virker på alle sprog er ikke muligt, f.eks. er afbildningen mellem store og små bogstaver ikke 1:1 på tysk.
#63
Problemet stikker dybere end caps lock. Det betyder også fx. at de nogle gange starter med stort bogstav, nogle gange med småt.
Der er ingen grund til at gøre det mere kompliceret end de har gjort det: Lav det case insensitive, og forøg længden med ét tegn.
Hver gang man gør software mere kompliceret, så tager det længere tid at kode, mere tid at teste, flere fejl der skal rettes, mere tid at gen-teste osv. Og det er jo et temmeligt følsomt område som bare SKAL virke. Og så skal det være nemt at forstå. Derfor: Simpelt, funktionelt og sikkert.
Problemet stikker dybere end caps lock. Det betyder også fx. at de nogle gange starter med stort bogstav, nogle gange med småt.
Der er ingen grund til at gøre det mere kompliceret end de har gjort det: Lav det case insensitive, og forøg længden med ét tegn.
Hver gang man gør software mere kompliceret, så tager det længere tid at kode, mere tid at teste, flere fejl der skal rettes, mere tid at gen-teste osv. Og det er jo et temmeligt følsomt område som bare SKAL virke. Og så skal det være nemt at forstå. Derfor: Simpelt, funktionelt og sikkert.
kasperd (63) skrev:Desuden kan man jo ikke nødvendigvis bruge de almindelige funktioner i ens programmeringssprog til at konvertere imellem store og små bogstaver, da det ikke er til at vide hvordan de håndterer æ, ø, og å. At lave en generel funktion, som virker på alle sprog er ikke muligt, f.eks. er afbildningen mellem store og små bogstaver ikke 1:1 på tysk.
Skal det gøres helt tigtigt så skal man bruge en case insensitiv comparison ikke en to lower case og en case sensitiv comparison.
De fleste programmerings sprog understøtter so ein ding.
myplacedk (64) skrev:
Der er ingen grund til at gøre det mere kompliceret end de har gjort det: Lav det case insensitive, og forøg længden med ét tegn.
Hver gang man gør software mere kompliceret, så tager det længere tid at kode, mere tid at teste, flere fejl der skal rettes, mere tid at gen-teste osv.
Umiddelbart vil jeg tro at det kræver mere kode at lave en case insensitiv sammenligning end en case sensitiv. Ikke meget men en lille bitte smule.
Som jeg forklarede i indlæg #63, så kan man ikke gøre det på den gåde med mindre man begår den absolut utilgivelige fejl at gemme kodeordet i klartekst. Hvis man rent faktisk bruger en hash til passwordet, så er man nødt til at konvertere til store (eller små) bogstaver før man hasher.arne_v (65) skrev:Skal det gøres helt tigtigt så skal man bruge en case insensitiv comparison ikke en to lower case og en case sensitiv comparison.
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