mboost-dp1
PBS A/S
"har ifølge Niels Gotfredsen samme sikkerhedsniveau som nuværende kodeform."
Øøøøhhhh. Nej.
Hvis man ændre en kodes krav fra min 6 tegn tal og bogstaver, til min 4 tal. Så går man også fra (29+10)^6 til 10^4 kompleksitet. Og jeg kan ikke se hvordan det IKKE kan påvirke sikkerhedsniveauet.
Selv med 2 faktor validering, så har første faktor mistet noget af sin sikkerhed.
Det er slemt nok at koderne ikke er case-sensitive, så det havde været (29+29+10)^6. Men 39^6 er stadig betydelig bedre end 10^4.
Men heldigvis er det valgfrit, så jeg bibeholde min lange (ikke case-sensitive) kode. Jeg kan nemlig godt finde ud af (den utrolig kompliceret opgave) at taste bogstaver og tal på min mobil...
[edit]
Ikke at forglemme, at jeg faktisk logger på min bank uden brug af papkort. Og kan flytte penge rundt mellem mine egne kontoer. Papkort kommer dog i spil, når der skal overføres til andre.
Øøøøhhhh. Nej.
Hvis man ændre en kodes krav fra min 6 tegn tal og bogstaver, til min 4 tal. Så går man også fra (29+10)^6 til 10^4 kompleksitet. Og jeg kan ikke se hvordan det IKKE kan påvirke sikkerhedsniveauet.
Selv med 2 faktor validering, så har første faktor mistet noget af sin sikkerhed.
Det er slemt nok at koderne ikke er case-sensitive, så det havde været (29+29+10)^6. Men 39^6 er stadig betydelig bedre end 10^4.
Men heldigvis er det valgfrit, så jeg bibeholde min lange (ikke case-sensitive) kode. Jeg kan nemlig godt finde ud af (den utrolig kompliceret opgave) at taste bogstaver og tal på min mobil...
[edit]
Ikke at forglemme, at jeg faktisk logger på min bank uden brug af papkort. Og kan flytte penge rundt mellem mine egne kontoer. Papkort kommer dog i spil, når der skal overføres til andre.
#1: Der er nu en separat kode til min netbank på mobilen - og den kræver stadig nøglekort hvis der skal overføres til andre, men jeg skal aldrig taste min SkørID kode...
Tror også jeg beholder den komplicerede TossetID kode, og så bare kører den anden på mobilen til banken - hvad dælen skal man ellers bruge SkodID til på mobillos?
Tror også jeg beholder den komplicerede TossetID kode, og så bare kører den anden på mobilen til banken - hvad dælen skal man ellers bruge SkodID til på mobillos?
Jeg tænker ikke at kompleksitet er afgørende hvis man har tilstrækkelig sikkerhed mod bruteforce og lign.
Den største risiko for at få stjålet sine login informationer er igennem ting som malware og offentlige interaktioner, hvor password længde nærved ingen betydning har.
Jeg kan ikke se dette som det store sikkerhedsmæssige komprimi.
Den største risiko for at få stjålet sine login informationer er igennem ting som malware og offentlige interaktioner, hvor password længde nærved ingen betydning har.
Jeg kan ikke se dette som det store sikkerhedsmæssige komprimi.
Jeg kunne godt tænke mig at vide hvordan login-boksen ved man skal indtaste tal frem for kodeord; hvis man ikke aktivt selv skal vælge "tal" fem for "tekst" så vil man formentlig kunne bruge systemet til at finde alle aktive cpr numre, der har slået "tal" til (fordi der må være en form for trafik, fra interface til backend - når cpr nummeret er tastet ind)
Med en ekstra få forsøg før de laver en lukning Af forkerte forsøg kan man hurtig lave en målrettet og præcis ekskludering af alle med "tal"-koder fra nemid ...
Edit: mht bruteforce; de har udtalt at de lukker tal-nemid'erne ned hurtigere end normalt - men samtidig har de også sagt at de ekskluderer bestemte "alt for nemme kombinationer" - feks 1234 og 0000. Og måske de fire sidste cifre i ens cpr nummer (?). Så det er formentlig ikke 10000 kombinationer, men snarere ~9900 man har at vælge imellem.
Med en ekstra få forsøg før de laver en lukning Af forkerte forsøg kan man hurtig lave en målrettet og præcis ekskludering af alle med "tal"-koder fra nemid ...
Edit: mht bruteforce; de har udtalt at de lukker tal-nemid'erne ned hurtigere end normalt - men samtidig har de også sagt at de ekskluderer bestemte "alt for nemme kombinationer" - feks 1234 og 0000. Og måske de fire sidste cifre i ens cpr nummer (?). Så det er formentlig ikke 10000 kombinationer, men snarere ~9900 man har at vælge imellem.
arne_v (5) skrev:#4
Ja *hvis* der er "tilstrækkelig sikkerhed mod bruteforce og lign.".
Som eksemplet med iPhone viser, så er det ikke trivielt at implementere.
Mjah, der er vel en stor forskel på sikkerheden over en protokol og sikkerheden ved fysiske adgang.
#6
Mon dog? Det lyder en tand for amatør agtigt.
#7
Helt klart ja.
Men det er ikke et helt normalt kodeord der sendes til server og efter X forkert forsøg så blokeres der.
Per NemID's egen dokumentation så sendes kodeord slet ikke til server. Det bruges kun client side i en protokol med server. En protokol som ikke er offentligjordt (men dog er reverse engineered).
Hvad det betyder for beskyttelse mod brute-force er ihvertfald uklart for mig.
Helt klart ja.
Men det er ikke et helt normalt kodeord der sendes til server og efter X forkert forsøg så blokeres der.
Per NemID's egen dokumentation så sendes kodeord slet ikke til server. Det bruges kun client side i en protokol med server. En protokol som ikke er offentligjordt (men dog er reverse engineered).
Hvad det betyder for beskyttelse mod brute-force er ihvertfald uklart for mig.
Useful (7) skrev:#6
Mon dog? Det lyder en tand for amatør agtigt.
mmm altså, hvis der skal være en automatisk funktion der skifter væk fra tekst og over til pinkode, baseret på hvilket cpr-nummer man har indtastet, så må der være en form for kommunikation med serveren, der slår det ene eller anden fra i nemid-login-feltet.
Hvis pinkoden er noget man selv skal vælge aktivt i en fane f.eks. (det kunne jo være den gamle tekst-kode fortsætter med at virke - og man kan logge ind med begge), vil de stadig stå med problemet at man kan få spærret sin nemid (som jeg forstår det), baseret på for mange forkerte indtastning (eftersom de spærrer pinkoden hurtigere).
Det kan så være de laver systemet så det er pinkoden de blokerer, og ikke selve nemid adgangen; og det vil nok være den smarteste løsning af dem alle.
Problemet er så selvfølgelig, at hvis man virkelig gerne ville invalidere nemid, ikke med DDoS, men samtlige brugere, så ville man fyre samtlige cprnumre igennem et bot-netværk, med 4-5 random pinkoder til hver. Men ok.. det kunne man så også formentlig med det normale system :-)
_tweak (9) skrev:Useful (7) skrev:#6
Mon dog? Det lyder en tand for amatør agtigt.
mmm altså, hvis der skal være en automatisk funktion der skifter væk fra tekst og over til pinkode, baseret på hvilket cpr-nummer man har indtastet, så må der være en form for kommunikation med serveren, der slår det ene eller anden fra i nemid-login-feltet.
Men hvor får du det fra?
Hvorfor er der et behov for at sende en besked, om at koden ikke indeholder 6 tegn eller mere, og kun indeholder tal?! Det kan jeg slet ikke følge. Den skal vel for fanden da bare tage imod et input og sende det afsted som altid?
Hvis du snakker om hvad type indput "appen" skal være sat til som standard, skulle følge hvad slags kode man har, er vi tilbage i "amatør agtigt" for hvem fanden ville da være så dum?
#10 De eksempler der har været i pressen, har vist et andet interface til pinkode-versionen. Det er muligt det ikke er mockups der kommer fra NETS selv. Jeg er enig i de bare skal tage imod et input - de kan sagtens nøjes med det samme; men som sagt, der har været mockups af noget andet.
Med app'en - mener du "nemid-standard-login-skærmen"? Og jeg er helt enig i at vi er ovre i amatøragtig tilgang, hvis interfacet skifter automatisk.
Men det vil give mening hvis man kan skifte mellem tekst og pinkode, manuelt - pinkode lukker dig hurtig ude ved få forkerte; tekst er som vi kender det i det.
Med app'en - mener du "nemid-standard-login-skærmen"? Og jeg er helt enig i at vi er ovre i amatøragtig tilgang, hvis interfacet skifter automatisk.
Men det vil give mening hvis man kan skifte mellem tekst og pinkode, manuelt - pinkode lukker dig hurtig ude ved få forkerte; tekst er som vi kender det i det.
Arrrh hvad... det må være mere sikkert fordi det er nyt... jeg må straks ændre min DumID kode til en 4 cifret kode fordi Det er da smart..... bl bl bl
Ja det er ret sjovt. Både Windows 10 logon og facebook understøtter 4 cifret koder nu :)
Det sikreste ville være en SMS med en kode i stedet for papkort.
Så du logger ind med brugernavn og password og så får du SMS.
Det er det samme de store virksomheder såsom google bruger. 2 faktor validering og det er det sikreste :)
Det sikreste ville være en SMS med en kode i stedet for papkort.
Så du logger ind med brugernavn og password og så får du SMS.
Det er det samme de store virksomheder såsom google bruger. 2 faktor validering og det er det sikreste :)
#17: Rent teknisk set kan en SMS opsnappes. Papkortet er rent faktisk det mest sikre, så længe folk ikke scanner det ind eller lignende.
Kan godt være at "de store" bruger sms, men det er nok fordi de også tager højde for den administrative byrde. Dem som har det så sikkert som muligt anvender destruerbare engangskoder på papir, eller andet let ødelagt materiale.
Kan godt være at "de store" bruger sms, men det er nok fordi de også tager højde for den administrative byrde. Dem som har det så sikkert som muligt anvender destruerbare engangskoder på papir, eller andet let ødelagt materiale.
#16:
Den grundlæggende præmis med nemID med papkort er ok... det er ting som ingen case og kun 4 cifre der er problemet...
Dette gør at nemID pt kun er 1 faktor (papkort)...
Prøv i stedet en af flg. Muligheder....
A)
Papkort + større krav til koden...
Koden skal være minimum på 6 tegn...
Koden skal være CASE sensitive...
Koden skal indeholde tegn fra alle 4 tegn grupper...
Tegn grupperne er:
1) store bogstaver
2) små bogstaver
3) tal
4) special tegn (ie. Punktum osv.)
En 4 cifret pin som endda ikke er case sensitive og som oftest kun består af tal er alt for usikker
Kombinationer: 10^4
Dette kan til nøds gå på en enhed hvor man ikke så nemt kan benytte Brute force som eksempelvis en pin kode til en gammel Nokia telefon... specielt fordi telefonen så låser hvis koden indtastes forkert 3 gange og så kræver en langt mere avanceret kode...
B)
SKAL man absolut have 4 cifret kode uden case på nemID så
BØR man have en slags PUK kode som minimum skal overholde de krav jeg har listet ovenfor...
Indtastes nemID kode forkert 3 gange så låses kontoen indtil den mere restriktive "PUK" kode er indtastet
Den grundlæggende præmis med nemID med papkort er ok... det er ting som ingen case og kun 4 cifre der er problemet...
Dette gør at nemID pt kun er 1 faktor (papkort)...
Prøv i stedet en af flg. Muligheder....
A)
Papkort + større krav til koden...
Koden skal være minimum på 6 tegn...
Koden skal være CASE sensitive...
Koden skal indeholde tegn fra alle 4 tegn grupper...
Tegn grupperne er:
1) store bogstaver
2) små bogstaver
3) tal
4) special tegn (ie. Punktum osv.)
En 4 cifret pin som endda ikke er case sensitive og som oftest kun består af tal er alt for usikker
Kombinationer: 10^4
Dette kan til nøds gå på en enhed hvor man ikke så nemt kan benytte Brute force som eksempelvis en pin kode til en gammel Nokia telefon... specielt fordi telefonen så låser hvis koden indtastes forkert 3 gange og så kræver en langt mere avanceret kode...
B)
SKAL man absolut have 4 cifret kode uden case på nemID så
BØR man have en slags PUK kode som minimum skal overholde de krav jeg har listet ovenfor...
Indtastes nemID kode forkert 3 gange så låses kontoen indtil den mere restriktive "PUK" kode er indtastet
CBM (20) skrev:det er ting som ingen case og kun 4 cifre der er problemet...
Dette gør at nemID pt kun er 1 faktor (papkort)...
...
En 4 cifret pin som endda ikke er case sensitive og som oftest kun består af tal er alt for usikker
Kombinationer: 10^4
Dette kan til nøds gå på en enhed hvor man ikke så nemt kan benytte Brute force som eksempelvis en pin kode til en gammel Nokia telefon... specielt fordi telefonen så låser hvis koden indtastes forkert 3 gange og så kræver en langt mere avanceret kode...
Jeg havde allerede kommentaret lidt på emnet:
arne_v (8) skrev:
Men det er ikke et helt normalt kodeord der sendes til server og efter X forkert forsøg så blokeres der.
Per NemID's egen dokumentation så sendes kodeord slet ikke til server. Det bruges kun client side i en protokol med server. En protokol som ikke er offentligjordt (men dog er reverse engineered).
Hvad det betyder for beskyttelse mod brute-force er ihvertfald uklart for mig.
Men nu har jeg så googlet lidt og fundet:
https://www.version2.dk/artikel/danid-ja-det-er-mu...
Ifølge den artikel så låser NemiD i 8 timer efter 5 forsøg og efter 5 nye forsøg skal der ny kode til.
Har du googlet anden information frem?
#21: det har jeg ikke men mon ikke koden på en eller anden facon benyttes til at verificere koden på pap kortet?
Hvis koden du indtaster på din klient ikke sendes til server i nogen form, så er vi vel tilbage til 1 faktor sikkerhed da klient siden altid skal betragtes som værende usikker?
Fx login systemer til hjemmesider. .. der er "sensitive" oplysninger som password altid gemt i en database
Edit:
Super fint at den låser efter 5 forsøg så er det netop som pin og puk koder
Alligevel ville det have en opdragende effekt at sætte højere krav til koden.
Ligeledes har det en skadelig effekt på folks password vaner når de må nøjes med case insensitive og kan klare sig med 4 tegn/tal
Hvis koden du indtaster på din klient ikke sendes til server i nogen form, så er vi vel tilbage til 1 faktor sikkerhed da klient siden altid skal betragtes som værende usikker?
Fx login systemer til hjemmesider. .. der er "sensitive" oplysninger som password altid gemt i en database
Edit:
Super fint at den låser efter 5 forsøg så er det netop som pin og puk koder
Alligevel ville det have en opdragende effekt at sætte højere krav til koden.
Ligeledes har det en skadelig effekt på folks password vaner når de må nøjes med case insensitive og kan klare sig med 4 tegn/tal
CBM (22) skrev:
Hvis koden du indtaster på din klient ikke sendes til server i nogen form, så er vi vel tilbage til 1 faktor sikkerhed da klient siden altid skal betragtes som værende usikker?
Nej.
Det er relativt almindeligt ikke at sende password til server. Og det antages ihvertfald at det ikke reducerer sikkerheden.
Eksempler: Kerberos (bl.a. Windows domain login) og MySQL.
Disse er dokumenterede i modsætning til NemID.
CBM (22) skrev:
Fx login systemer til hjemmesider. .. der er "sensitive" oplysninger som password altid gemt i en database
Forhåbentligt gemmes password ikke i databasen, men kun en hash med salt af det.
CBM (22) skrev:
Super fint at den låser efter 5 forsøg så er det netop som pin og puk koder
Alligevel ville det have en opdragende effekt at sætte højere krav til koden.
Ligeledes har det en skadelig effekt på folks password vaner når de må nøjes med case insensitive og kan klare sig med 4 tegn/tal
Hvis erfaringen med NemID resulterer i at man bruger samme sikkerhedsniveau som NemID så ville det være et enormt fremskridt.
Hvis erfaringen med NemID resultarer i at:
* man bibeholder 1 faktor løsning med kun password
* man bruger NemID's password policy
så er den gal.
Forhåbentligt er der ikke så mange der vælger at skyde sig selv i foden på den måde.
#23:
Hvis fru Hansen har koden 1234 til nemid som nok er den første man vil prøve så har hun i praksis kun 1 faktor sikkerhed via papkort. Samme hvis en ung knøs scanner sit papkort ind og ligger det et usikkert sted.
De har måske teoretisk 2 faktor sikkerhed...javist men det er på line med den teoretiske sikkerhed i kinesiske biler.
At gemme password i en database kan vel også dække over andet end at gemme passwords i clear text? :-)
#24:
Jeg kunne godt være bange for at folk bliver "opdraget" af "nemid" til at deres password policy er sikker...
De siger selv det ikke påvirker sikkerheden og folk har sikkert tillid til deres offentlige udsagn.
Når det er sagt så er der heldigvis mange steder hvor mobilen bruges til at indføre 2 faktor sikkerhed
Edit: moderne android ordbøger....grrrrr
Hvis fru Hansen har koden 1234 til nemid som nok er den første man vil prøve så har hun i praksis kun 1 faktor sikkerhed via papkort. Samme hvis en ung knøs scanner sit papkort ind og ligger det et usikkert sted.
De har måske teoretisk 2 faktor sikkerhed...javist men det er på line med den teoretiske sikkerhed i kinesiske biler.
At gemme password i en database kan vel også dække over andet end at gemme passwords i clear text? :-)
#24:
Jeg kunne godt være bange for at folk bliver "opdraget" af "nemid" til at deres password policy er sikker...
De siger selv det ikke påvirker sikkerheden og folk har sikkert tillid til deres offentlige udsagn.
Når det er sagt så er der heldigvis mange steder hvor mobilen bruges til at indføre 2 faktor sikkerhed
Edit: moderne android ordbøger....grrrrr
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