Gå til innhold

Se når du kan kaste ut Java fra nettbanken


Anbefalte innlegg

Bare et skjema over SSL... du har virkelig ikke peiling.

Vennligst kom med seriøse responser, ikke kvalme.

Du har heller ikke klart å svare på det som ingen andre over her har klart heller; hvorfor skal JavaScript brukes (eller andre teknologier for den del) når det er unødvendig?

 

Over til sikkerhet. Du mener Javascript på klientsiden introduserer risiko for injection? Hvorfor det? Du kan ta fint kjøre javascript injection selv om sia ikke har javascript fra før? Tror du folk kjører uten javascript for tia?

Selvfølgelig har de ikke implementert kryptering i Javascript. Hvorfor skulle noen gjøre det? hva i all verden er det slags utviklermiljø du er i?

Javascript brukes til å behandle svar man får fra back-end og tilpasse flyt for bruker.

Dette koker igjen ned til hvorfor er det ønskelig med en JavaScript-løsning? Nemlig at butikker og andre tjenester ønsker å gjøre verifiseringen til en integrert del av sine tjenester, som åpner for muligheter for injection, manipulering utenfra osv. Dette er faktisk det ene punktet den gamle løsningen hadde en fordel, nemlig at appleten var beskyttet mot manipulasjon (bortsett fra at apleten kunne erstattes av en falsk en). Kreativiteten og mengden av potensielle former for misbruk av JavaScript har eksplodert de siste par årene, og det er ingen tvil om at JavaScript er en arena som må få drastiske sikkerhetstiltak i årene som kommer. På et tidspunkt blir det nødvendig med mer en "nedlåst" modus for kritiske operasjoner som bank, kjøp osv.

 

Det skal sies at ren HTML ikke er 100% trygt heller, men det er den beste løsningen vi har så langt. Det hadde vært en stor forbedring om skjema-funksjonaliteten ble en integrert del av alle nettlesere(med egen standard selvsagt) som var helt separert og utilgjengelig fra DOM, men det blir bare ønsketenkning på nåværende tidspunkt.

  • Liker 1
Lenke til kommentar
Videoannonse
Annonse

Håpløst. Det går veldig greit å implementere plattformuavhengige løsninger i java. Det er heller ikke umulig å tillate sertifiseringer av java "sessions" gjennom diverse implementeringer av java compilere. Som for eksempel Bouvet omsider fikk til for DnBs løsning, ved å nettopp unngå Windows-spesifikk syntaks - som i utgangspunktet heller ikke skal brukes.

 

I tillegg er det fullstendig kurant, om banken eller kundene tør å bruke det, å lage en fallback-løsning uten java ved siden av.

 

Den som fant på ideen om at Java er det verste som finnes må være en skikkelig godt betalt konsulent, med andre ord. Like nedrullet som Hardware-redaksjonen er de i hvert fall helt tydelig. Samme runden som kom med "sikkerhetsbrister" i Java. Ingen kunne spørre en person som visste noe om sikkerhet om å klare opp hva slags sikkerhetsproblemer du ikke kan bli kvitt, under noen omstendighet, med en web-basert løsning. Eller for eksempel å ta en runde på hva slags sikkerhetsproblemer java kurerer for godt.

 

Men det er vel bare paranoide fjols som vil ha sikkerhet med kontoer, personinformasjon og penger på internett nå om dagen, skjønner vi.

 

Det er virkelig det verste som har skjedd de siste par årene. Konsulenter argumenterer implisitt at sikkerhet er ment til å stoppe venner og kjente fra å logge seg inn på sin egen maskin. Og fint lite annet. Til gjengjeld skal gjerne sentrale register med alle mail-adresser, telefonnummer, kontonummer, brukerhistorie, søkehistorie, ip-adresse, osv. lagres for å gjøre alt "enklere" for brukerne.

 

Om folk visste hvor enkelt det er akkurat nå å "miste" personlig informasjon, så ville de steilet. Og å inkludere kontonummer og tilgang til nettbank gjennom bbs i dette mer åpne universet er tullete.

Lenke til kommentar

De av oss uten katastroferæva bank har aldri behøvet Java for innlogging. Leve Skandiabanken!

Skandiabanken har sine store svakheter, spesielt på lånesøknader. Skandiabanken ønsker tydeligvis at andre banker skal gjøre drittjobben, for derretter at man skal flytte lånet når alt møkkearbeidet er gjort av andre banker.

Lenke til kommentar

 

Skjønner ikke hva DnB snakker om, de har jo tilbudt innlogging uten Java, med kodebrikke, i mange år allerede.

Det er ikke det artikkelen handler om.

 

Har du lest artikkelen? Den inneholder ordet java 26 ganger, oftest i variasjoner av "java-fri", "kaste ut java", "kvitte deg med java" osv, inkludert i overskrift og ingress. Den vinkles som om det er BankID 2.0 som skal muliggjøre dette, men dettte har som sagt allerede mulig i mange år hos DnB.

 

Poenget HW.no går glipp av er at det ikke er innlogging i nettbanken som har vært problemet, men betaling via nettbutikker, som bruker Netaxept/BankID, som igjen krever Java.

  • Liker 2
Lenke til kommentar

 

Bare et skjema over SSL... du har virkelig ikke peiling.

Vennligst kom med seriøse responser, ikke kvalme.

Du har heller ikke klart å svare på det som ingen andre over her har klart heller; hvorfor skal JavaScript brukes (eller andre teknologier for den del) når det er unødvendig?

 

 

 

Om du ønsker det er det kanskje lurt å roe ned sin egen retorikk? Det er ikke måte på hvor inkompetente du maler andre som i ditt første innlegg i tråden.

 

AtW

Lenke til kommentar

Har vi glemt en bank her Sparebank 1 da? har vi noe info på når eller om de evt bytter om?

 

Kan hende de er utelatt pga. de er for dyre for kunden å benytte?

 

Nei, jeg bare tøyser. Selvfølgelig er de dyre, men de var ikke nevnt, og de er relativt store om bankmarkedet. Spesiellt i Rogaland tror jeg dette om kunde-"penetrasjon" gjelder.

 

I forretningsmarkedet så gjelder selvfølgelig Sparebank1 som aktør, for privatmarkedet, eh nei tror det finnes billigere og like greie eller bedre banker.

Lenke til kommentar

 

 

Skjønner ikke hva DnB snakker om, de har jo tilbudt innlogging uten Java, med kodebrikke, i mange år allerede.

Det er ikke det artikkelen handler om.

 

Har du lest artikkelen? Den inneholder ordet java 26 ganger, oftest i variasjoner av "java-fri", "kaste ut java", "kvitte deg med java" osv, inkludert i overskrift og ingress. Den vinkles som om det er BankID 2.0 som skal muliggjøre dette, men dettte har som sagt allerede mulig i mange år hos DnB.

 

Poenget HW.no går glipp av er at det ikke er innlogging i nettbanken som har vært problemet, men betaling via nettbutikker, som bruker Netaxept/BankID, som igjen krever Java.

 

Artikkelen handler om Java-fri BankID 2.0 som overliggende tema. At en del banker har egne innlogginger uten Java er ikke det samme. BankID kan brukes på kryss av banker og på andre systemer. BankID har også et definert høyere sikkerhetsnivå, som blant annet er godkjent til personsensitive data (i.e. resepter).

 

EDIT: Men ja, det kunne vært mer presist i artikkelen. De fleste har et Java-fritt alternativ å logge seg inn med allerede.

Endret av RattleBattle
  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...