16. mai ble det full kriseberedskap i Evry etter datalekkasje. Rotårsaken kan påvirke alle norske selskaper

[dizx]

 

Pålogging er fortsatt løsningen.

Og hva, presis, mener du er forskjellen mellom "pålogging" og bruk av post-data til å sende en hemmelig nøkkel? Det blir akkurat det samme. Pålogging er bare sending av brukernavn og passord (den hemmelige nøkkelen) som post-data.

 

 

 

og dersom siden som inneholder den nødvendige POST-dataen for forespørselen er den som indekseres, er man like langt.

I tilfellet med nettbank, som var det jeg svarte på, er man allerede pålogget, så det blir ikke noe problem.

 

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

[Svorsken]

 

 

Pålogging er fortsatt løsningen.

Og hva, presis, mener du er forskjellen mellom "pålogging" og bruk av post-data til å sende en hemmelig nøkkel? Det blir akkurat det samme. Pålogging er bare sending av brukernavn og passord (den hemmelige nøkkelen) som post-data.

 

 

 

og dersom siden som inneholder den nødvendige POST-dataen for forespørselen er den som indekseres, er man like langt.

I tilfellet med nettbank, som var det jeg svarte på, er man allerede pålogget, så det blir ikke noe problem.

 

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

Oavsett vilken semantik du väljer så handlar autenticering om att du skickar "hemlig" data typiskt över HTTP POST från klienten till en server. Om denna datan kommer via en annan server (A) eller direkt från att brukaren skriver in ett username / passord har ingen betydelse. Bägge fallen är precis lika mycket "security by obscurity" som du kallar det för.

 

En del webapplikationer sände tyvärr denna informationen via URL'en istället (HTTP GET), problemet med det är dels att det hamnar i historikken, och nu att Microsoft tydligen anser dina URL'er vara publik information.

 

Uppseendväckande beteende av Edge som borde haft en stor varseltrekant som informerade brukarna vad de faktiskt accepterar när de tackar ja.

[dizx]

 

Oavsett vilken semantik du väljer så handlar autenticering om att du skickar "hemlig" data typiskt över HTTP POST från klienten till en server. Om denna datan kommer via en annan server (A) eller direkt från att brukaren skriver in ett username / passord har ingen betydelse. Bägge fallen är precis lika mycket "security by obscurity" som du kallar det för.

 

En del webapplikationer sände tyvärr denna informationen via URL'en istället (HTTP GET), problemet med det är dels att det hamnar i historikken, och nu att Microsoft tydligen anser dina URL'er vara publik information.

 

Uppseendväckande beteende av Edge som borde haft en stor varseltrekant som informerade brukarna vad de faktiskt accepterar när de tackar ja.

 

 

Klart det har betydning. I mitt eksempel, så vil Microsoft indexsere URL som man videresender til Server B. Bing sin Robot vil så forsøke og sjekke innholdet på den siden. Da vil ikke det fungere, da roboten ikke er innlogget på server A.

Endret 22. mai 2017 av dizx

[8DVX9UOT]

Noen har forsøkt å få windows 10 til å la være å sende data hjem. Ikke så lett

[FrHa]

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

[tommyb]

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Du kan ikke bare tenke ut én måte å implementere det på og så ta din implementasjon og spørre om andre mener seriøst at det skal være sånn. Det finnes mange måter å ordne dette på, og fakturaserveren trenger strengt tatt ikke vite noe om brukeren i det hele tatt, bare at nettbanken går god for ham. En måte å gjøre dette på er med tokens, en annen er at nettbanken går imellom og ingen faktura sendes direkte til sluttbrukeren uten å gå via nettbanken. Og det er bare to muligheter blant mange. Hemmelig URL uten noen som helst form for sikkerhet er altså én måte, men den er ufattelig dårlig. Ingen av mulighetene krever at du sender fødselsnummer til fakturahotellet, og selv om det var sånn kunne man jo hashe det, men det er altså slett ikke en naturlig måte å gjøre det på. 

 

Og jeg forteller deg også at vi altså har designet en slik løsning som er i daglig bruk, så ingen skal fortelle meg at noen trenger å tiltro personnummer til filtjenesten bare for å sjekke om brukeren har rettighet til filen. Men noe må man sette opp som sikkerhetsløsning mellom sluttbruker og fakturahotell, og det er det man tydeligvis ikke har tatt seg tid til (eller forstått hvordan man skal få til, men det tviler jeg på er grunnen). 

Endret 23. mai 2017 av tommyb

[FrHa]

 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Du kan ikke bare tenke ut én måte å implementere det på og så ta din implementasjon og spørre om andre mener seriøst at det skal være sånn. Det finnes mange måter å ordne dette på, og fakturaserveren trenger strengt tatt ikke vite noe om brukeren i det hele tatt, bare at nettbanken går god for ham. En måte å gjøre dette på er med tokens, en annen er at nettbanken går imellom og ingen faktura sendes direkte til sluttbrukeren uten å gå via nettbanken. Og det er bare to muligheter blant mange. Hemmelig URL uten noen som helst form for sikkerhet er altså én måte, men den er ufattelig dårlig. Ingen av mulighetene krever at du sender fødselsnummer til fakturahotellet, og selv om det var sånn kunne man jo hashe det, men det er altså slett ikke en naturlig måte å gjøre det på. 

 

Og jeg forteller deg også at vi altså har designet en slik løsning som er i daglig bruk, så ingen skal fortelle meg at noen trenger å tiltro personnummer til filtjenesten bare for å sjekke om brukeren har rettighet til filen. Men noe må man sette opp som sikkerhetsløsning mellom sluttbruker og fakturahotell, og det er det man tydeligvis ikke har tatt seg tid til (eller forstått hvordan man skal få til, men det tviler jeg på er grunnen). 

 

Hva var det med denne løsningen som fikk deg til å tro at det er 'min' løsning ?

Det er slik eFaktura har vært implementert omtrent siden 'tidenes morgen'. du vet - eFaktura fra NETS - som er eid av bankene i Norge...

Det er altså bankene som har laget denne løsningen, og mener det er 'sikkert nok' å kjøre en 'ren hemmelig url' som autentiseres kun ved at 'hemmeligheten' lar seg dekryptere av det sertifikatet som NETS har utstedt (ble vel byttet sist for 3-4 år siden).

 

Og selvsagt - den skal kun være gyldig i 5 minutter...  Men like fullt - en 'ren hemmelig url' som gir direkte autorisasjon til å vise en faktura fra det fakturahotellet dokumentet ligger på.

 

Det er selvsagt mulig å endre på denne løsningen, men det vil kreve ganske mye arbeid fra ganske mange aktører i markedet.  

 

Det er selvsagt mulig å både skrive om med 'tokens' der Nets kaller opp fakturahotellet først for å 'avgi' et token som dette bruker i ettertid til å autentisere url - krever utvikling hos samtlige partnere.

 

Hva mener du egentlig med at 'fakturaen ikke sendes direkte til sluttbrukeren' ? Det sndes ingen faktura til sluttbrukeren i en efaktura-løsning - har du egentlig forsøkt å skjønne hvordan eFaktura fungere i Norge ?

 

Og om du mener at NEST er ignorante og nekter å innse at deres løsning for 'sikkert url-hopp' er 'elendig', får du nesten ta det opp med de direkte... Regner med at du også får noen eFakturaer gjennom året, og innimellom faktisk åpner dokumentet bak betalingskravet i nettbanken - da burde du ha oppdaget at denne løsningen er 'elendig' for lenge siden...

 

Og det er nok sikkert ikke 'vanskelig' å lage en 'sikrere' tjeneste når du har kontroll på alle involverte parter...  Poenget er at dette er blitt ansett som 'sikkert nok' for fakturainformasjon i lang tid, og det kan nå hende at dette endres på grunn av MS sin iver etter å laste ned og lagre nettsider som kun en person har besøkt en eneste gang...

[Raymond Brun]

 

Problemet har sannsynligvis oppstått nettopp fordi Evry har satset på "security by obscurity", å trodd at maskingenererte lenker som ikke er beskyttet på annet vis er sikre.

 

Eksakt! Mange bruker lange maskingenererte URLer som sikkerhet, også hvis du tar et GoogleDoc og åpner det for "alle som har URL'en". Dette har nok vært ganske sikkert i praksis veldig lenge, men nå som Microsoft har begynt å bruke Edge som spion for å crawle alle URLer folk besøker, så er dette alt annen enn trygt.

 

For faktura-hoteller til e-faktura kan jo dette løses temmelig enkelt ved å oppdatere robots.txt så samtlige roboter stenges ute. Enda bedre vil være om faktura-hotellet f.eks. krever inntasting av en pin-kode fra SMS før man får se siden.

Robots.txt sperrer ikke ut, det ber crawler pent vennligst ikke les.

[0laf]

Robots.txt sperrer ikke ut, det ber crawler pent vennligst ikke les.

 

Det er ingenting som sperrer kun roboter, uten å også sperre alle andre som ikke er autentisert.

 

Roboter trenger ikke sjekke robots.txt, det er heller ikke noe problem å endre user_agent slik at det ser ut som en helt vanlig nettleser.

 

Det er likevel temmelig sikkert at Microsoft sine roboter følger det som står i robots.txt, det samme gjelder alle større søkemotorer.

[dizx]

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Se denne videoen: 

[FrHa]

 

Robots.txt sperrer ikke ut, det ber crawler pent vennligst ikke les.

 

Det er ingenting som sperrer kun roboter, uten å også sperre alle andre som ikke er autentisert.

 

Roboter trenger ikke sjekke robots.txt, det er heller ikke noe problem å endre user_agent slik at det ser ut som en helt vanlig nettleser.

 

Det er likevel temmelig sikkert at Microsoft sine roboter følger det som står i robots.txt, det samme gjelder alle større søkemotorer.

 

Poenget i akkurat denne saken er vel at det betyr ikke noe som helst hva som står i robots.txt, eller om denne finnes i det hele tatt. Crawleren har fått en URL fra EDGE eller IS, og den går direkte på denne uten å se om det finnes noen 'hint' til hva en robot generelt skal gjøre på dette domenet.

[FrHa]

 

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Se denne videoen: 

 

Hva har denne med saken å gjøre ? For å få dette 'sikkert' med bruk av nettbank-url'er, så må det enkelt og greit sørges for at tidsstyringen erstattes eller bygges ut med at signaturen kun kan benyttes en eneste gang...  Man behøver da ikke ikke implementere noe kjempeopplegg med en massiv installasjon av SSO-løsninger som skal implementeres av samtlige fakturahoteller i landet ? I denne saken (og andre saker der det er stor vartiasjon av server-typer som skal ta imot den sikre url'en) vil det definitivt enkleste være å implementere engangsbruk av den sikre URL'en.  Og dersom den feiler eller ikke er 'slått på', så vil BING hente innholdet uansett (mulig at BING tar hensyn til 'nocache'/'noindex' osv i header på selve dokumentet og dermed ikke lagrer det, men den vil uansett hente det ned først)

[dizx]

 

 

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Se denne videoen: 

 

Hva har denne med saken å gjøre ? For å få dette 'sikkert' med bruk av nettbank-url'er, så må det enkelt og greit sørges for at tidsstyringen erstattes eller bygges ut med at signaturen kun kan benyttes en eneste gang...  Man behøver da ikke ikke implementere noe kjempeopplegg med en massiv installasjon av SSO-løsninger som skal implementeres av samtlige fakturahoteller i landet ? I denne saken (og andre saker der det er stor vartiasjon av server-typer som skal ta imot den sikre url'en) vil det definitivt enkleste være å implementere engangsbruk av den sikre URL'en.  Og dersom den feiler eller ikke er 'slått på', så vil BING hente innholdet uansett (mulig at BING tar hensyn til 'nocache'/'noindex' osv i header på selve dokumentet og dermed ikke lagrer det, men den vil uansett hente det ned først)

 

 

Det er ikke noe kjempeopplegg og pålegge fakturahotellet og sjekke om brukeren faktisk er pålogget i den løsningen man kom fra. Det krever en liten webservice. 

[FrHa]

 

 

 

 

Nei, pålogging er pålogging. Det vil si at server A (nettløsningen du logget inn via), redirecter deg til server B med en lenke som inneholder et kryptert brukernavn og timestamp. Server B bruker denne informasjonen, sender en forespørsel til server A for å sjekke om du virkelig er logget inn. 

Hvordan tenker du deg at dette skal foregå når du er pålogget i nettbanken din, denne ber en server hos Nets om en 'signert' url for å åpne opp et dokument i et fakturahotell.

Da er det minst tre 'servere' involvert, og de to stedene 'brukernavnet' finnes er kun hos Nets og i Nettbanken (fødselsnummer er din brukerid).

Mener du seriøst at alle fakturahotell-tjenester skal opprette en fullstendig brukerdatabase med samtlige fødselsnummere ? Hvordan skal de kunne få den informasjonen når faktura-utsteder ikke har lov til å bruke den, men kunn har en egen 'intern' efaktura-id som de sender fakturaen til (det er Nets som 'kobler efakturaid med fødselsnummer)...

 

 

Se denne videoen: 

 

Hva har denne med saken å gjøre ? For å få dette 'sikkert' med bruk av nettbank-url'er, så må det enkelt og greit sørges for at tidsstyringen erstattes eller bygges ut med at signaturen kun kan benyttes en eneste gang...  Man behøver da ikke ikke implementere noe kjempeopplegg med en massiv installasjon av SSO-løsninger som skal implementeres av samtlige fakturahoteller i landet ? I denne saken (og andre saker der det er stor vartiasjon av server-typer som skal ta imot den sikre url'en) vil det definitivt enkleste være å implementere engangsbruk av den sikre URL'en.  Og dersom den feiler eller ikke er 'slått på', så vil BING hente innholdet uansett (mulig at BING tar hensyn til 'nocache'/'noindex' osv i header på selve dokumentet og dermed ikke lagrer det, men den vil uansett hente det ned først)

 

 

Det er ikke noe kjempeopplegg og pålegge fakturahotellet og sjekke om brukeren faktisk er pålogget i den løsningen man kom fra. Det krever en liten webservice. 

 

Man stoler på at brukeren er pålogget når man kommer med en URL som kun kan være signert av Nets i løpet av de siste 3 minuttene, man er for øvrig ikke pålogget hos Nets, men i den enkelte nettbank, så jo, det vil være et ganske stort opplegg som må på plass.

Dessuten vil det ikke hjelpe å sjekke akkurat dette - han er pålogget - det vet vi siden det kommer en signert URL som kun kan valideres av Nets egne programmer som kjører i hvert enkelt fakturahotell. Det som må til for at en aggressiv robot ikke kan hente ut informasjonen, er at hver enkelt signatur må lagres slik at den ikke kan benyttes mer enn en gang.