Fandt denne interessante artikel i går, og tænkte det kunne da være vi kunne tage en lille diskussion om hvad folks holdning er til diverse bankers sikkerhed i Danmark.

https://jamiemagee.co.uk/2015/05/06/do-y...h-edition/

(09-05-2015, 11:44)BigJ Skrev: Kommer lidt med et input som jeg syntes er meget relevant, i forhold til sikkerhed med disse banker.

Jeg har her de seneste dage leget en del med DanskeBank MobilBank APP og CoopBank MobilBank APP. Og jeg har derfor fundet ud af at DanskeBank er utterlig crap.

Første gang at jeg undersøgte sikkerheden i DanskeBank så havde de nogle smarte tokens der skulle være "super svære" at generer igen. Problemet var bare, at de tjekkede ikke om de tokens man sendte til deres servers stemte overens.. Jeg sendte gentagende gange tokens som "GGDKBANK", og det gik helt fint igennem. Da jeg så denne uge begyndte at kigge på deres APP igen (efter jeg havde haft kontakt med deres IT afdeling og de havde lukket fejlen), finder jeg så rimelig hurtigt ud af hvordan at de generer diverse ting, og sådan er det jo! Men en ting der kommer bag på mig, er at det eneste der kryptere det CPR nummer og PIN du sender til DK banks servers, er HTTPS. De væger ikke at bruge en symmetric client -> server auth.. Hvilket jeg sku er skuffet over.

Derimod er et godt eksempel på bank sikkerhed CoopBank som bruger alle mulige shit krypteringer som bare gør det pisse træls at arbejde med. Der bliver alt krypteret via. https, samt at de bruger det client server symmetric key forhold. Så selvom at du skulle knække deres cert, så skal du stadigvæk have en privat key for at kunne decrypt den symmetric key der bliver brugt... Altså, selv den velkomstbesked som serveren sender til dig er krypteret.

Håber folk forstår mit indlæg.
TL;DR: DanskeBank is shit.

EDIT: Ved godt det er lidt offtopic ang. SSL. Men syntes det havde et godt skud input til bankernes sikkerhed.

Meget interessant input, med at du havde mulighed for at sende tokens uden de overhovedet tjekkede dem igennem.

Og tja offtopic ved jeg nu ikke. Alt er da tilladt at diskuterer på det.

(09-05-2015, 11:44)BigJ Skrev: Kommer lidt med et input som jeg syntes er meget relevant, i forhold til sikkerhed med disse banker.

Jeg har her de seneste dage leget en del med DanskeBank MobilBank APP og CoopBank MobilBank APP. Og jeg har derfor fundet ud af at DanskeBank er utterlig crap.

Første gang at jeg undersøgte sikkerheden i DanskeBank så havde de nogle smarte tokens der skulle være "super svære" at generer igen. Problemet var bare, at de tjekkede ikke om de tokens man sendte til deres servers stemte overens.. Jeg sendte gentagende gange tokens som "GGDKBANK", og det gik helt fint igennem. Da jeg så denne uge begyndte at kigge på deres APP igen (efter jeg havde haft kontakt med deres IT afdeling og de havde lukket fejlen), finder jeg så rimelig hurtigt ud af hvordan at de generer diverse ting, og sådan er det jo! Men en ting der kommer bag på mig, er at det eneste der kryptere det CPR nummer og PIN du sender til DK banks servers, er HTTPS. De væger ikke at bruge en symmetric client -> server auth.. Hvilket jeg sku er skuffet over.

Derimod er et godt eksempel på bank sikkerhed CoopBank som bruger alle mulige shit krypteringer som bare gør det pisse træls at arbejde med. Der bliver alt krypteret via. https, samt at de bruger det client server symmetric key forhold. Så selvom at du skulle knække deres cert, så skal du stadigvæk have en privat key for at kunne decrypt den symmetric key der bliver brugt... Altså, selv den velkomstbesked som serveren sender til dig er krypteret.

Håber folk forstår mit indlæg.
TL;DR: DanskeBank is shit.

EDIT: Ved godt det er lidt offtopic ang. SSL. Men syntes det havde et godt skud input til bankernes sikkerhed.

TLS burde være tilstrækkeligt. Bankens server skal autentificeres, hvorefter der skal åbnes en sikker tunnel. Applikationen indeholder sandsynligvis bankens certifikat og har mulighed for at tjekke det mod en revocation list, så det er på plads. Der er ikke nogen særlig grund til at kryptere data yderligere.
Det er jo netop idéen bag SSL/TLS teknologierne :)

Jeg går ud fra, at du tænker på dette når du siger symmetrisk client auth. Det er lidt overflødigt, da du benytter DH til at oprette en symmetrisk nøgle, der krypterer al data i din TLS tunnel. Jeg kan ikke se hvorfor du ville lægge en nøgle mere på, især hvis det bare er en der skal hardcodes i applikationen.

For at snakke om artiklen, så er jeg lidt overrasket over, at de ikke engang understøtter TLS 1.2. Det værste er, at det er latterligt nemt at sætte korrekt op. Jeg forstår ikke hvorfor de så ikke har fået styr på det.

(09-05-2015, 15:41)BigJ Skrev: Ang. symmetrisk nøgle, så TROR jeg at det er det jeg taler om. Syntes den side mangler lidt i forhold til hvad jeg har set.. Så beskriver det lige yderligere hurtigt.
Client genererer en symmetrisk nøgle, hvorefter at den bliver krypteret med et public certifikat og sendt til serveren. Nu ved serveren så hvilken nøgle den kan forvente at få beskeder med (Hvis det gav mening).

Det er også den korte udgave af hvad TLS gør :) Desuden er der ikke nogen voldsomme problemer med det. Der er ikke så frygteligt mange protokolmæssige exploits. Der er BEAST og POODLE som begge er afhængige af at din server understøtter noget der er egentlig er blevet erstattet for noget tid siden.
BEAST kan mitigeres ved at forbyde CBC cifre (til fordel for GCM, som har eksisteret i et pænt stykke tid), og POODLE kræver bare at du deaktiverer SSL3 (til fordel for TLS1, TLS1.1 og TLS1.2).
Med andre ord skal du tilføje to linjer til din webservers konfiguration (Taget direkte fra Shellsec):

Næsten alle andre exploits du har hørt om, har været relateret til OpenSSL, ikke selve protokollen.
Min pointe er at TLS ikke fejler noget, hvis man bare følger lidt med i nyhederne og bruger 2 minutter på at opdatere konfigurationen hvert andet år. SSLLabs er et godt værktøj til at følge med i, hvad der er anbefalet.

Lige for at få en ting på det rene. Når du siger symmetrisk, er du så sikker på, at du ikke mener asymmetrisk? Det ville jeg bedre forstå når nu du nævner private nøgler. Desuden er det den sikre løsning, også selv hvis det kun bruges til tokens, og ikke bare generel datasikring.

Som du beskriver det der, så ja.
Både klienten og serveren har adgang til den symmetriske nøgle, f. eks. AES.
Serveren har adgang til det nøglepar der udgør den asymmetriske del, altså den offentlige, samt private nøgle, f. eks. RSA. Klienten har kun kendskab til den offentlige nøgle, og kan derfor kun kryptere, og derved ikke dekryptere data. Dekryptering ville kræve den private nøgle, og kun serveren har adgang til denne.
Alt efter hvilke data der skal krypteres, vil den asymmetriske løsning være nok.
Hvis du reverser eller debugger klienten, har du jo adgang til AES nøglen før den bliver krypteret, og så skulle det være en smal sag at finde ud af hvilke data der bliver sendt.

(09-05-2015, 20:21)BigJ Skrev: Well... Det er vel en blanding af begge dele nu hvor at jeg læser op på det (i må lige bære over med mig, er ret ny på det her område).

Men en symmetrisk nøgle er noget du tilføjer til en string, for at gøre at kun den rigtige person kan læse den. Altså fx.
Altså dette må vel os kunne være en kryptering af en tekst? Fx. noget indenfor AES.

Men for at begge skal kunne læse denne kryptering, kræver det så at modparten har nøglen, altså i dette tilfælde serveren. Udvekslingen af den nøgle bliver så gjort via det asymmetriske, altså via. et offentligt og privat certifikat.
Source: https://support.microsoft.com/en-us/kb/246071

Altså et eksempel er fx.
Klient genererer symmetrisk nøgle som bruges til kryptering
Klient krypterer symmetrisk nøgle med det offentlige certifikat
Klient sender den krypteret symmetriske nøgle til serveren
Serveren dekryptere den symmetriske nøgle med det private certifikat

Nu har begge servers den symmetriske nøgle der bliver brugt til at krypterer dataen.

I følge det, så må det vel være en blanding af begge ting? Eller er jeg helt forkert på den? :)

En simpel forklaring er noget i den her stil:
Symmetrisk betyder at nøglen du krypterer med er den samme som den du dekrypterer med (f.eks. en adgangskode/passphrase).
Asymmetrisk betyder at nøglerne er forskellige (public/private keypairs).

Problemet er at asymmetrisk kryptering er ineffektivt. Hvis du kender til tidskompleksitet og store-O notationen, så kan du evt. læse dette og sammenligne RSA (asymmetrisk) med AES (symmetrisk):
http://crypto.stackexchange.com/question...algorithms
Løsningen er, at man bruger asymmetrisk kryptering til at kryptere nøglen til en symmetrisk krypteret datastrøm, da du så kun skal køre nøglen igennem RSA, hvorefter du bruger AES for resten af forbindelsen.

Jeg kan kun sige SUK!! Jeg har med nogle af bank centralernes it at gøre dagligt. Det er lige som de andre store centraler. Det skal se stort og flot ud, udadtil. Internt bliver det ene efter det andet forsømt. If only I could tell. If only you knew!
Der bliver sparet for meget.., ikke fordi økonomien egentlig halter, men fordi nogen gerne vil have flere penge i lommen.