mboost-dp1
PBS A/S
Bacon (4) skrev:Jeg ved godt at det skal testes grundigt men, hvorfor skal det overhovedet tage et helt år?
Adgang til alle danskeres netbank og personlige oplysninger?
Hvis det var estimeret til UNDER et år, ville jeg sgu føle mig rimelig usikker. Faktisk synes jeg, at et år er lige i underkanten!
moulder666 (5) skrev:Adgang til alle danskeres netbank og personlige oplysninger?
Hvis det var estimeret til UNDER et år, ville jeg sgu føle mig rimelig usikker. Faktisk synes jeg, at et år er lige i underkanten!
Nu skal vi huske på at det her ikke er raketvidenskab. De skal jo ikke udvikle en "speciel-NEMID-krypteret-token-procedure" eller sådan noget andet bras. Tværtimod bør man anvende i forvejen gennemtestede principper for kryptering, levering og administration af data.
Alt over 1 år er spild af skattekroner...
ITemplate (8) skrev:
Nu skal vi huske på at det her ikke er raketvidenskab. De skal jo ikke udvikle en "speciel-NEMID-krypteret-token-procedure" eller sådan noget andet bras. Tværtimod bør man anvende i forvejen gennemtestede principper for kryptering, levering og administration af data.
Man kan godt anvende " i forvejen gennemtestede principper for kryptering, levering og administration af data." og stadig ende med en udviklingstid på over 1 år uden at det er spild af skattekroner.
Når man tænker på, at dette er noget der skal kobles til flere forskellige bankdatacentraler og nok er DET mest kritiske system i DK, forventer jeg sådan set, at de tester det 1½ gange mere end det strengt taget er nødvendigt.
Det er heldigt at newz.dk har så mange kloge hoveder, så vi kan hjælpe dem! Søg job og kom igang! ;)
#12
Ja, det minder mig om dagene med Real Player ^_^
Sidst jeg installerede Java gik det for hurtigt, og Ask-toolbar kom med - sikke noget skrammel! Det burde markeres som malware.
Præcis ligesom Flashplayer fra Adobe - der vil de have du snuppe McAfee med ...
Ja, det minder mig om dagene med Real Player ^_^
Sidst jeg installerede Java gik det for hurtigt, og Ask-toolbar kom med - sikke noget skrammel! Det burde markeres som malware.
Præcis ligesom Flashplayer fra Adobe - der vil de have du snuppe McAfee med ...
moulder666 (5) skrev:Alt over 1 år er spild af skattekroner...
Det ville være et større spild af skattekroner hvis systemet ikke var testet godt og grundigt igennem.
Hvis nu dine konti bliver nakket igennem et overset hul, så ville det koste en formue (skattekroner) at få dig sikret igen.
Jovist er et hvert system sårbart, men hvis det kan minimeres ved at teste det grundigt, så er der ikke noget der hedder spild af skattekroner.
Laziter (15) skrev:Jovist er et hvert system sårbart, men hvis det kan minimeres ved at teste det grundigt, så er der ikke noget der hedder spild af skattekroner.
Aha. Hvor lang tid tog det at udvikle "Nem ID 0.1"? På trods af det, er passwords ikke CaSe SeNsItIvE bl.a...
#16
Glemte aldrig dengang hvor svigermor skulle ind via NemID, og hun sagde koden til mig XxxxXX hvorefter jeg skrev det hele med småt, og hun sagde "nej det skal være med stort" ... Pffh
Glemte aldrig dengang hvor svigermor skulle ind via NemID, og hun sagde koden til mig XxxxXX hvorefter jeg skrev det hele med småt, og hun sagde "nej det skal være med stort" ... Pffh
Thoroughbreed (17) skrev:#16
Glemte aldrig dengang hvor svigermor skulle ind via NemID, og hun sagde koden til mig XxxxXX hvorefter jeg skrev det hele med småt, og hun sagde "nej det skal være med stort" ... Pffh
What... Er det også password? Troede bare at username ikke var case sensitive. Mit password taster jeg altid med de store bogstaver det nu normalt indeholder. *facepalm*
#0 skrev:Nets oplyser, at de vil have Javascript-versionen klar i andet kvartal af 2014, et bud de er ret sikre på, idet der er gennemført en omfattende estimering og definering af projektet.
"idet der er gennemført en omfattende estimering og definering af projektet"
Hahahahaahhahaaaa
We'll ask for estimates...
Manofsciencemanoffaith (19) skrev:https://www.nemid.nu/dk-da/support/gode_raad_om_si...
Der tillades kodeord helt ned til seks tegn?
woooooooooow det er skidt!
ITemplate (8) skrev:Nu skal vi huske på at det her ikke er raketvidenskab. De skal jo ikke udvikle en "speciel-NEMID-krypteret-token-procedure"
Jeg håber inderligt at du har ret, men jeg forventer faktisk at de selv designer og implementerer noget dybt fejlbehæftet kryptering fra begyndelsen af >_<
Hvis de lavede noget der fungerede, på standard kryptering, så ville der jo ikke være brug for deres ekspertise i dyre service kontrakter, vel?
Selv hvis de tager udgangspunkt i noget fornuftigt, så vil de som minimum bygge en masse halløj ovenpå, i et forsøg på at gemme ting af vejen og se indviklede ud (hvis ikke de ligefrem laver det ekstra indviklet - også for dem selv) samt for at lægge deres egne "strengt nødvendige" sikkerhedsforanstaltninger ovenpå.
#23
Ikke specielt meget, men hvis minimumslængden var 10 tegn, så er entropien på omkring 40 (a-z, 0-9). Hvis DanID så forklarede at et enormt langt password var det sikreste (f.eks. jegelskeratgiveminsønbananmosfordisåkanjegogsåselvfåmiglidtbananmosoggørerentefterhambagefter - entropi 572,3), så var de meget langt med sikkerheden. Store og små bogstaver er kun noget der betyder noget i den menneskelige verden. Password [1] og [2] er stort set ens (og helt ens i NemID), [2] er bare sværere at huske og taste ind. Alligevel bliver din entropi kun hævet 1,4.
[1] ghqpærz875 = entropi 57,8
[2] GhQpÆrZ875 = entropi 59,2
Ikke specielt meget, men hvis minimumslængden var 10 tegn, så er entropien på omkring 40 (a-z, 0-9). Hvis DanID så forklarede at et enormt langt password var det sikreste (f.eks. jegelskeratgiveminsønbananmosfordisåkanjegogsåselvfåmiglidtbananmosoggørerentefterhambagefter - entropi 572,3), så var de meget langt med sikkerheden. Store og små bogstaver er kun noget der betyder noget i den menneskelige verden. Password [1] og [2] er stort set ens (og helt ens i NemID), [2] er bare sværere at huske og taste ind. Alligevel bliver din entropi kun hævet 1,4.
[1] ghqpærz875 = entropi 57,8
[2] GhQpÆrZ875 = entropi 59,2
Man kan jo undres at flere apps får det til at fungere år før de selv gør...
er det ikke snart forældet med tanke på at de fleste kan tilgå bank og e-boks m.m. via apps på de devices som ikke supportere Java ?
jojo, selvfølgelig skal vi da ha en javascript alternativ, men tror bare det bliver forældet inden det når på gaden.
er det ikke snart forældet med tanke på at de fleste kan tilgå bank og e-boks m.m. via apps på de devices som ikke supportere Java ?
jojo, selvfølgelig skal vi da ha en javascript alternativ, men tror bare det bliver forældet inden det når på gaden.
gramps (25) skrev:Store og små bogstaver er kun noget der betyder noget i den menneskelige verden. Password [1] og [2] er stort set ens (og helt ens i NemID), [2] er bare sværere at huske og taste ind. Alligevel bliver din entropi kun hævet 1,4.
[1] ghqpærz875 = entropi 57,8
[2] GhQpÆrZ875 = entropi 59,2
Jeg er ikke sikker på hvordan entropi beregnes, men i forbindelse med brute-force angreb, ville jeg da tro at indførelsen af store bogstaver, burde forøge den tid der skal til at bryde kodeordet gavaldigt.
Med udgangspunkt i ikke-case-sensitive, har man brug for følgende karaktersæt:
"abcdefghijklmnopqrstuvwxyzæøå0123456789"
Hvis det er case-sensitive har man brug for:
"abcdefghijklmnopqrstuvwxyzæøåABCDEFGHIJKLMNOPQRSTUVWXYZÆØÅ0123456789"
...altså 38 karakterer mod 66 karakterer.
Det burde næsten fordoble den tid der kræves for at brute-force sig gennem kodeordet?
Jeg er dog enig i at forlængelse af kodeordet er bedre end blot case-sensitive, men jeg kan ikke se hvorfor det skulle gøre SÅ lidt forskel om det er case-sensitive eller ej?
#28
Entropien regnes netop i bit, +1 til entropi svarer derfor til en fordobling af angrebs tiden.
Det er rigtigt at en kode der både er lang og case-sensitive er bedre. Men jeg tror beslutningen er taget på det grundlag at der er en del brugere som ikke kan overskue caps lock. Hvis man kan undgå en masse service opkald blot på at lade brugeren indtaste et tegn eller 2 mere så må det være en ret nem beslutning. Brugerne opdager det jo alligevel ikke medmindre de tester det eller nærlæser deres side.
Hvis du som bruger føler at din kode er for usikker uden at være case-sensitive er den alligevel usikker om ~18 måneder. Det er på tide at finde en ny :-)
Entropien regnes netop i bit, +1 til entropi svarer derfor til en fordobling af angrebs tiden.
Det er rigtigt at en kode der både er lang og case-sensitive er bedre. Men jeg tror beslutningen er taget på det grundlag at der er en del brugere som ikke kan overskue caps lock. Hvis man kan undgå en masse service opkald blot på at lade brugeren indtaste et tegn eller 2 mere så må det være en ret nem beslutning. Brugerne opdager det jo alligevel ikke medmindre de tester det eller nærlæser deres side.
Hvis du som bruger føler at din kode er for usikker uden at være case-sensitive er den alligevel usikker om ~18 måneder. Det er på tide at finde en ny :-)
OrangeNewton (29) skrev:Hvis man kan undgå en masse service opkald blot på at lade brugeren indtaste et tegn eller 2 mere så må det være en ret nem beslutning.
Helt enig!
Desværre tillader NemID helt ned til kun 6 karakterer!
Men der er dog vist noget med at ens konto bliver blokeret, hvis man har for mange fejlforsøg, så brute-force burde ikke være så brugbart alligevel.
Men jeg mener stadig det er under al kritik, at tillade en SÅ svag kode, til noget så vigtigt og kritisk som NemID.
Man ser nogen gange password-felter som sætter et MAKSIMUM for længden af ens password.
Er det bare mig, eller er den regel ikke bare en lille smule skør?
Er det bare mig, eller er den regel ikke bare en lille smule skør?
tentakkelmonster (31) skrev:Man ser nogen gange password-felter som sætter et MAKSIMUM for længden af ens password.
Er det bare mig, eller er den regel ikke bare en lille smule skør?
Jo, især hvis brugeren ikke informeres om denne begrænsning. Så er det sgu svært.
tentakkelmonster (31) skrev:Man ser nogen gange password-felter som sætter et MAKSIMUM for længden af ens password.
Er det bare mig, eller er den regel ikke bare en lille smule skør?
Som udgangspunkt jo.
Der kan dog være andre grunde i spil, eksempelvis hvis feltet til opbevaring af password i databasen kun er på fx 32 karakterer, giver det ikke mening at man kan indtaste mere end 32 karakterer, da det ville forsage en fejl, eller password ville beskæres.
Det sker desværre, men jeg vil kalde det dårlig kodeskik.
Det er dog umiddelbart kun et problem hvis password opbevares i klartekst, hvilket jeg ikke vil anbefale.
Så hellere opbevare en form for hash af passwordet, gerne med en form for seed, så det ikke så let kan reverses.
gramps (34) skrev:#33
Hvis man ikke hasher kodeordet til en bestemt længde, så gør man noget meget forkert.
Et 5000 tegn langt password kan stadig hashes til 32 bit. Det vil bare tage lang tid.
Helt enig.
Dog ikke i at det vil tage lang tid at hashe 5000 tegn.
Jeg har som forsøg lige hashet 25.000 karakterer lorem-ipsum til MD5, og det tog kun 0.00045 sekunder.
Gjorde det derefter med 25.000 tilfældige karakterer, 10.000 gange - det tog 4.33286 sekunder.
Ikke desto mindre, støder jeg ind imellem på steder der gemmer passwords som klartekst i databasen.
angelenglen (35) skrev:gramps (34) skrev:#33
Hvis man ikke hasher kodeordet til en bestemt længde, så gør man noget meget forkert.
Et 5000 tegn langt password kan stadig hashes til 32 bit. Det vil bare tage lang tid.
Helt enig.
Dog ikke i at det vil tage lang tid at hashe 5000 tegn.
Jeg har som forsøg lige hashet 25.000 karakterer lorem-ipsum til MD5, og det tog kun 0.00045 sekunder.
Gjorde det derefter med 25.000 tilfældige karakterer, 10.000 gange - det tog 4.33286 sekunder (inklusive den tid det tog at generere de 10.000 x 25.000 tegn...).
Ikke desto mindre, støder jeg ind imellem på steder der gemmer passwords som klartekst i databasen.
#35
Ikke alle webservere har den type processorer. Desuden kan en faktor 100 i beregning hurtigt have en betydning hvis man forventer flere tusinde brugere. Hashingen skal jo køre hver gang en bruger skal logge ind eller oprettes. Hvis du kan spare (og her snupper jeg bare tal ud af røven) 10 millisekunder hver gang et kodeord skal behandles, og du har 1000 brugere som logger ind samtidigt, så sparer du 10 sekunder. Hvis du har endnu flere brugere (og man håber vel altid på flere brugere?), så skal de vente endnu længere. En normal bruger har ikke lyst til at vente 10 sekunder på at logge ind. Jeg har heller ikke.
Ikke alle webservere har den type processorer. Desuden kan en faktor 100 i beregning hurtigt have en betydning hvis man forventer flere tusinde brugere. Hashingen skal jo køre hver gang en bruger skal logge ind eller oprettes. Hvis du kan spare (og her snupper jeg bare tal ud af røven) 10 millisekunder hver gang et kodeord skal behandles, og du har 1000 brugere som logger ind samtidigt, så sparer du 10 sekunder. Hvis du har endnu flere brugere (og man håber vel altid på flere brugere?), så skal de vente endnu længere. En normal bruger har ikke lyst til at vente 10 sekunder på at logge ind. Jeg har heller ikke.
Hashing tager så lidt processorkraft, at det er en meget lille del af hvad der tager tid i forbindelse med et login.
Specielt med de meget korte passwords folk typisk har, på under 30 karakterer.
Hvis det tager 10 sekunder at logge ind, har du enten brug for at opgradere din webserver, eller optimere din kode.
Det er nogle gange prisen for succes.
Ps. beklager gentagelsen #36, ved ikke hvad der gik galt der...
Specielt med de meget korte passwords folk typisk har, på under 30 karakterer.
Hvis det tager 10 sekunder at logge ind, har du enten brug for at opgradere din webserver, eller optimere din kode.
Det er nogle gange prisen for succes.
Ps. beklager gentagelsen #36, ved ikke hvad der gik galt der...
#38
Hashing tager kort tid, ja. Men læste du hvad jeg skrev? Hvis du har et stort system med adskillige tusinde brugere (hvilket jeg antager Uplay er og har) og du har tusinde logins samtidigt, så kommer den sidste i køen til at vente 10 sekunder, såfremt hashingen tager 10 millisekunder. Det gælder altid om at minimere CPU-tid, uanset hvem du er og hvor du arbejder; man skal aldrig spilde penge på hardware når man kan tænke sig om når man laver softwaren.
Hashing tager kort tid, ja. Men læste du hvad jeg skrev? Hvis du har et stort system med adskillige tusinde brugere (hvilket jeg antager Uplay er og har) og du har tusinde logins samtidigt, så kommer den sidste i køen til at vente 10 sekunder, såfremt hashingen tager 10 millisekunder. Det gælder altid om at minimere CPU-tid, uanset hvem du er og hvor du arbejder; man skal aldrig spilde penge på hardware når man kan tænke sig om når man laver softwaren.
gramps (39) skrev:#38
Hashing tager kort tid, ja. Men læste du hvad jeg skrev? Hvis du har et stort system med adskillige tusinde brugere (hvilket jeg antager Uplay er og har) og du har tusinde logins samtidigt, så kommer den sidste i køen til at vente 10 sekunder, såfremt hashingen tager 10 millisekunder. Det gælder altid om at minimere CPU-tid, uanset hvem du er og hvor du arbejder; man skal aldrig spilde penge på hardware når man kan tænke sig om når man laver softwaren.
Jamen det er vi da enige om.
Hvad er dit alternativ til hashing så, hvis du mener det er så slemt og tungt?
Jeg mener stadig ikke det tager så lang tid, og da slet ikke i nærheden af 10 ms.
En anden note er at den slags højt belastede system ofte har flere frontend servere til at fordele belastningen på, hvilket hjælper.
Jeg er godt klar over at det netop er at spilde penge på hardware, men det er nu engang en realitet rigtigt mange steder, og ikke kun på grund af tidsforbrug, men også for at sikre høj grad af oppetid og tilgængelighed.
gramps (41) skrev:#40
Selvfølgelig er hashing den bedste mulighed. Men der er ingen grund til at tillade 5000 eller flere tegn hvis det tager unødig CPU-tid.
Og så vil jeg præcisere: De 10 ms var udelukkende et tal som jeg hev ud af røven.
Aaah ok det er de 5000 tegn du ikke kunne lide.
Så giver det hele mere mening.
Jamen så er vi åbenbart enige.
For ja, 5000 karakterer i et password er nok lige langt nok ;-)
Men hvis folk har lyst til et password på 50 karakterer, ser jeg ikke noget problem i det.
Men selv hvis man insisterer på at begrænse længden af passwords, kan man gøre det serverside, frem for ved indtastningen (og stadig hashe).
Jeg stødte engang på et sted hvor man kunne indtaste alt hvad man havde lyst til i password-feltet, men alt over 8 karakterer blev smidt væk serverside - det fik brugerne bare intet at vide om.
Med det resultat at jeg gang på gang indtastede mit 14-cifrede password, hvilket selvfølgelig også virkede.
Indtil jeg fik det med de 8 karakterer at vide, så prøvede jeg at indtaste kun de første 8 cifre af mit password - det virkede sørme også - der følte jeg mig godt nok lidt snydt :-)
Lidt ligesom da jeg fandt ud af at NemID ikke var case-sensitive.
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