mboost-dp1
PBS A/S
Jeg har aldrig forstået hvorfor det er nødvendigt at anvende Java til det.
Kan det gøres mere sikkert ved at gennemtvinge Java end hvis man kommunikerer asynkront vhja. javascript og standard webforms? (async POST af forme har længe været muligt med fx. jQuery)
For mig virker det trodsalt bare til at være et brugernavn/password der skal sendes første gang og anden gang brugernavn/password/kode.
Er der nogen specielle krypteringer man kan anvende i Java som ikke er tilgængelig via Javascript, eller hvor ligger problemet?
Kan det gøres mere sikkert ved at gennemtvinge Java end hvis man kommunikerer asynkront vhja. javascript og standard webforms? (async POST af forme har længe været muligt med fx. jQuery)
For mig virker det trodsalt bare til at være et brugernavn/password der skal sendes første gang og anden gang brugernavn/password/kode.
Er der nogen specielle krypteringer man kan anvende i Java som ikke er tilgængelig via Javascript, eller hvor ligger problemet?
mfriis (1) skrev:Kan det gøres mere sikkert ved at gennemtvinge Java
Jeg ved ikke lige om det er mere sikkert, men der er andre faktorer end den umiddelbare tekniske sikkerhed.
Appletten har nogle features som de fleste aldrig opdager, men som er relevant ved fx. visse support-sager eller når man skal efterforske anmeldelser.
I see, så i tilfælde af "indbrud" har man noget maskininfo om skurken?
mht Support så ville jeg da mene at en stor del af deres problemer netop stammer i at det er en Java løsning. Var det JavaScript baseret skulle man vel bare sikre at brugeren kører en nyerere browser samt tillader javascript.
mht Support så ville jeg da mene at en stor del af deres problemer netop stammer i at det er en Java løsning. Var det JavaScript baseret skulle man vel bare sikre at brugeren kører en nyerere browser samt tillader javascript.
mfriis (1) skrev:Jeg har aldrig forstået hvorfor det er nødvendigt at anvende Java til det.
En af årsagerne er, at det giver DanId mulighed for at snage i din computer.
Desuden er det vældigt ironisk, at noget der skal anses som værende sikkert, nemlig NemID, anvender et af de programmer, der har absolut flest sikkerhedsproblemer (Java).
mfriis (4) skrev:mht Support så ville jeg da mene at en stor del af deres problemer netop stammer i at det er en Java løsning. Var det JavaScript baseret skulle man vel bare sikre at brugeren kører en nyerere browser samt tillader javascript.
Ork nej. Der er MASSER af henvendelser som slet ikke er relateret til Java.
Jeg har ingen tal på hvad der er mest typisk, men der er masser af folk derude som har svært ved at forstå forskellen på fødselsdato og CPR-nummer, engangkode og kodeord osv. Der kommer henvendelser om meget alvorlige sikkerhedsfejl, fordi folk kigger på en demo-netbank og ser et fremmed navn.
Der er også en del som bliver forvirret fordi NemID er ret dårlige til kommunikation. De bruger jo fx. en hel A4-side på at sige "Din engangs-kode er ********", og det væsentligste er ikke engang markeret.
Grunden til Java-applet'en er at de har benytter sig af en protokol der hedder Secure Remote Password: http://en.wikipedia.org/wiki/Secure_Remote_Passwor...
Graffen (8) skrev:Grunden til Java-applet'en er at de har benytter sig af en protokol der hedder Secure Remote Password: http://en.wikipedia.org/wiki/Secure_Remote_Passwor...
Der er da tilsyneladende en javascript-implementation ifølge wikipedia:
The Javascript Crypto Library includes a Javascript implementation of the SRP protocol, open source, GPL licensed.
#1: Der er rigtig mange diskussioner om dette emne. En af de bedre er her: http://www.version2.dk/artikel/danid-derfor-bruger... hvor DanId fortæller deres begrundelse for at bruge Java.
Helt generelt kan man dog sige at sikkerhedsprincipperne i login vha adskilte medier (begrundelsen for NemID's eksistens) sagtens kan løses uden Java. Dog kan DanId's løsning (NemID) ikke implementeres i Javascript. Det vil kræve komplet redesign.
Ang Javascript: Javascript og Java har ikke meget tilfælles andet end navnet. Og mulighederne er derfor heller ikke de samme.
--
Werner
Helt generelt kan man dog sige at sikkerhedsprincipperne i login vha adskilte medier (begrundelsen for NemID's eksistens) sagtens kan løses uden Java. Dog kan DanId's løsning (NemID) ikke implementeres i Javascript. Det vil kræve komplet redesign.
Ang Javascript: Javascript og Java har ikke meget tilfælles andet end navnet. Og mulighederne er derfor heller ikke de samme.
--
Werner
Justin (12) skrev:endnu en til listen
IC4
Rejsekortet
Nem-Id til mobilen
Amanda
Polsag
Den digitale tinglysning
Tårnfalken
Vi er så dygtige i Danmark...
dan1el (15) skrev:Surprise...
Hallo, er det Nordea's mobile app udviklere ? hvordan fik i det der NemID til at fungere på jeres mobile app ? hvis i nu giver os kildekoden, så får i rabat på næste års support...ok ? fint, tak skal i have, så har vi en mobil løsning imorgen !!
Det er fordi de snyder, og det er alt for nemt nemt for Center for digital signatur hos Digitaliseringsstyrelsen, de er ganske sikker på af der må findes en mere besværligmåde af gøre det på
Bankerne hooker selv direkte op til deres egne systemer, og de kan derfor snildt blot lave en ekstra indgang der er skræddersyet mobiladgang. Anderledes er det for Nets (selvom de også er bankerne) idet en NEM-ID løsning på mobilen skal virke til f.eks. SKAT, Borger.dk osv. Dvs. den skal passe til de eksisterende arkitekturer; så egentlig burde politikerne ikke kræve at Nets får taget sig sammen, men rettere give et vink med en vognstang til de offentlige myndigheder (og sig selv!) om at opdatere de eksisterende systemer.
Det er som sådan jo ikke Nets fejl (kun lidt, da de selv har valgt Java løsningen fra starten af) at SKAT, KL etc. ikke har penge til at holde deres digitale løsninger opdaterede.
Det er som sådan jo ikke Nets fejl (kun lidt, da de selv har valgt Java løsningen fra starten af) at SKAT, KL etc. ikke har penge til at holde deres digitale løsninger opdaterede.
dan1el (15) skrev:Hallo, er det Nordea's mobile app udviklere ?
Nordea og alle de andre banker har IKKE implementeret NemID åp mobilerne. De (vi) har lavet et grumt hack som ved første øjekast ser ud til at virke, men ikke holder i længden. Og det hack kan i øvrigt kun bruges af bankerne.
Én af konsekvenserne du som bruger nemt kan se er at du ikke kan logge ind med dit selvvalgte NemID-brugernavn. Du kan heller ikke bruge dit NemID kodeord.
En del af pointen med NemID er at man logger ind på NemID, hvorefter NemID fortæller det du logger ind på at du er god nok. Dvs. det site får aldrig fx. dit kodeord.
Mobil-hacket bankerne bruger i dag fungerer helt anderledes, der er det banken du logger ind på. Så tjekker de bare dit nøglekort med NemID, og det er det. Den løsning vil være ret uheldig at bruge bredt, for så er du tilbage til at bruge et nyt kodeord til hver ting du logger ind på.
Det er i øvrigt også imod aftalen mellem bankerne og DanID. Efter Danske Bank gjorde det alligevel er der kommet en dispensation, som gælder indtil der er en ordentlig løsning.
Kort sagt: Det er gaffa-tape, ikke en løsning der kan bruges permanent.
myplacedk (19) skrev:...
Kort sagt: Det ergaffa-tape, ikke en løsning der kan bruges permanentden helt forkerte løsning man har valgt fra starten af.
There I fixed it for ya! ...
#0 jeg er så træt af, at man gang på gang skal læse at et (semi-)offentligt IT projekt endnu engang ikke kan holde en tidsplan. Det er helt fantastisk så meget de kan formå at fucke de her systemer op.
Vi er et land der prøver at leve højt på at vi er veluddannede og dygtige folk, der skal leve af vores viden.. Hvorfor er det så så svært at lave sin research, undersøge de forskellige muligheder, se hvilke der lever op til de projekt-krav man har sat til at starte med, begynde at udvikle en løsning og anvende scrum eller lignende til at tilpasse løsningen undervejs?
Kom nu ind i kampen!
Kenman (20) skrev:There I fixed it for ya! ...
Først: Den gaffa-tape løsning som du tilsyneladende ikke mener man skulle have valgt, er ikke noget DanID har fundet på. Det er Danske Bank der hellere ville have en dårlig NemID-løsning end at beholde deres egen løsning. De andre banker var så mere eller mindre nødt til at følge med.
At NemID-på-mobil ikke er klar endnu har intet at gøre med hvilken løsning de valgte i starten. Det skyldes først og fremmest at de i starten på en eller anden måde blev enige om at det ikke var relevant. (WTF?)
Hvad der så gør at det tager så lang tid efter de er kommet i gang har lidt-til-intet med den eksisterende løsning at gøre. (Jeg ved noget om hvad det så er, men jeg tror ikke det er offentligt.)
Hvad der gør at de melder deadlines ud de ikke kan overholde har da især intet med teknikken at gøre. Og de ville i øvrigt ikke have været hurtigere færdige hvis de ikke havde meldt en deadline ud. Det er dårlig kommunikation, men så heller ikke mere. (Nåh jo, tegn på at de er dårlige til at tage en god beslutning og holde sig til den, men der kan være gode årsager til at ændre mening undervejs.)
Kun halvvejs en joke.. men kunne de ikke kontakte blizzard og få dem ind som konsulent, de har da gjort det meget godt med deres authenticator (til alle mobile platforme) ;)
Ved godt der er forskel.. meeeen,, tanken er nu meget sjov.
Ved godt der er forskel.. meeeen,, tanken er nu meget sjov.
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