Beveiliging tussen Flash en Web Service

[tomk94]

Hallo allemaal,

Ik ben bezig met een groot project in Flex, wat erg goed beveiligd moet gaan worden. Ik ben nu aan het na denken over hoe ik mijn klanten dit kan garanderen . Ik kom helaas niet uit sommige vraagstukken.

Situatie

Zoals ik al gezegd heb ben ik bezig met een project in Flex. Een klant moet in een web interface inloggen en kan in die web interface diverse taken uitvoeren. Deze taken mogen absoluut niet door iemand anders worden gelezen.

Oplossing en vraag

Om de veiligheid te garanderen wil ik zoiezo een SSL verbinding hebben. Daarnaast versleutel ik elk wachtwoord voordat ik deze verzend.

Nou bedacht ik me dat bijvoorbeeld een virus ervoor kan zorgen dat de verbinding tussen de Flex web applicatie ook 'omgeleid' kan worden. Zodat het virus in bezit komt van diverse gegevens. En deze kan verspreide over het wereld wijde web. Ik heb er nu al een tijd over gedacht hoe ik dat tegen kan gaan, maar helaas kan ik hier geen manieren voor bedenken.

Ik hoop dat jullie tweakers hier een oplossing voor hebben.


Met vriendelijke groeten,

Tom

[Gerco]

Als er gevoelige gegevens (zoals passwords) op een client bekend zijn en die client is besmet met een virus of andere malware is er helemaal niets wat jij daaraan kan doen. Het heeft geen zin om daarvoor beveiliging te verzinnen, als dat mogelijk was zou DRM ook werken.

De enige oplossingen zijn dus:
1. Trusted clients gebruiken;
2. Geen passwords e.d. op de client hebben.

Oplossing 1 kun je bereiken door de client dicht te timmeren. Komt neer op een livecd of een client PC waarop de gebruiker geen rechten heeft om niet goedgekeurde software te draaien. Als de gebruiker admin rechten heeft kun je iedere hoop op beveiliging laten varen.

Oplossing 2 kun je bereiken door one-time passwords te gebruiken, bijvoorbeeld door gebruik te maken van RSA SecurID tokens of Yubikeys. Dan is de geheime informatie nooit op de client computer aanwezig, die zit in de token en het password wat je applicatie ontvangt is nooit twee keer hetzelfde. Dat kan dus rustig gejat worden want het werkt maar één keer.

[ Voor 39% gewijzigd door Gerco op 02-05-2010 17:44 ]

[H!GHGuY]

100% veilig bestaat niet. Eerst en vooral kun je vereisen van je klanten dat ze hun eigen werkstations beveiligen met bvb een anti-virus pakket e.d. Daarnaast kun je nooit garanderen dat de gegevens, in niet geëncrypteerde vorm, niet af te luisteren vallen.

Je kan echter de techniek die banken toepassen gebruiken:
- Je zendt een challenge
- Samen met een pin-code en nog wat gegevens vorm je er een authenticatie-sleutel mee.
Verder gebruik je SSL zoals je zelf al aangaf. SSL bemoeilijkt/verhindert een man-in-the-middle attack en de authenticatie (server-side via SSL/certificate, client-side via pin/inloggegevens) zorgt voor non-repudiation/authentication.

[tomk94]

bedankt voor jullie reacties.

ik dacht al dat het niet mogelijk was. een livecd vindt ik niet wat te ver gaan voor iets wat gebruikersvriendelijk moet zijn:P. Dat challenge idee ga ik zeker gebruiken!!

[Gerco]

tomwebfreak schreef op zondag 02 mei 2010 @ 18:55:
Dat challenge idee ga ik zeker gebruiken!!

Weet wel dat dat alleen zin heeft als je de response niet op de client computer genereert. Waar H!GHGuY op doelt is bijvoorbeeld een signeercode bij (Rabobank) internetbankieren. Je toetst de challenge in op je "rekenmachientje", dan je pincode. Dat apparaatje genereert dan een code (de response).

Zo'n systeem heeft dus alleen zin wanneer je er aparte hardware bij betrekt. De gebruiker op zijn computer een pincode en challenge code laten invoeren voegt helemaal niets toe (behalve complexiteit, maar het wordt er niet veiliger op).

[Gomez12]

Tja, afhankelijk van hoe veilig je het wilt maken kan je wel enkele dingen na-apen van de banken...

Simpele begin is om de authenticatie ook afhankelijk te laten zijn van een extern apparaat.

Wat ik laatst tegenkwam ( en wat ik wel grappig bedacht vond ) was :
- in 1e instantie moest je separaat je 06-nr opgeven
- Na het inloggen ( met gewoon naam + wachtwoord ) kreeg je dan een code via sms die je ook weer moest opgeven.

[H!GHGuY]

Gerco schreef op zondag 02 mei 2010 @ 23:54:
[...]

Weet wel dat dat alleen zin heeft als je de response niet op de client computer genereert. Waar H!GHGuY op doelt is bijvoorbeeld een signeercode bij (Rabobank) internetbankieren. Je toetst de challenge in op je "rekenmachientje", dan je pincode. Dat apparaatje genereert dan een code (de response).

Zo'n systeem heeft dus alleen zin wanneer je er aparte hardware bij betrekt. De gebruiker op zijn computer een pincode en challenge code laten invoeren voegt helemaal niets toe (behalve complexiteit, maar het wordt er niet veiliger op).

Zoals Gerco zegt. Het heeft enkel toegevoegde waarde met een extern device. SSL heeft intern an sich al challenge-auth methodes (met een nonce) dus dit er zomaar bovenop implementeren voegt weinig toe.

[tomk94]

bedankt voor al jullie reacties,

het gebruik van extra hardware vindt ik net wat te ver gaan. Het idee om een code naar een mobiel te sturen lijkt mij erg goed. Ik ga hier ook zeker naar kijken.

Nogmaals bedankt

Tom

[Gerco]

Een mobiele telefoon is ook een extern device en voldoet dus prima aan de vereisten van extra hardware. Waar het om gaat is dat de geheime code niet ontstaat op de client computer en dat de code die wel door de client computer gaat maar één maal gebruikt kan worden.

Het versturen van een, per transactie, unieke code via SMS en die laten invoeren op de client computer is dus een prima oplossing (zie diverse banken die hetzelfde doen).

Alhoewel het dan niet mogelijk is voor malware om genoeg informatie te stelen om zelfstandig het systeem te misbruiken, is het met deze oplossing nog steeds prima mogelijk om de gebruiker om de tuin te leiden door op de achtergrond een extra transactie (overboeking) toe te voegen aan de data die naar de server verstuurd gaat worden (of een bestaande transactie te wijzigen).

[ Voor 30% gewijzigd door Gerco op 08-05-2010 15:43 ]

[Gomez12]

Gerco schreef op zaterdag 08 mei 2010 @ 15:39:
Alhoewel het dan niet mogelijk is voor malware om genoeg informatie te stelen om zelfstandig het systeem te misbruiken, is het met deze oplossing nog steeds prima mogelijk om de gebruiker om de tuin te leiden door op de achtergrond een extra transactie (overboeking) toe te voegen aan de data die naar de server verstuurd gaat worden (of een bestaande transactie te wijzigen).

Hangt van je precieze wensen qua security af.
Maar het beeld wat je hier schetst is voor ongeveer 95% van de toepassingen simpel af te vangen door extra text toe te voegen aan de sms.

Geef de gebruiker aan ( in de sms ) welke transactie er plaats gaat vinden als hij deze code gebruikt, dan leg je alle controles voor piggy-backing / MitM etc bij de gebruiker.

Je moet er alleen even opletten dat de extra text ook enkel extra text is en geen onderdeel uitmaakt van je gegenereerde code.

Als ik 9 euro wil overmaken en ik krijg een controle sms waarin staat : gebruik deze code om 10.009 euro over te maken in 2 transacties code : xxxxxxx.
Dan ben ikzelf verantwoordelijk voor het feit dat ik de 2e transactie doe...

[H!GHGuY]

Waar ik me eigenlijk zorgen over maak is dat de TS, naar mijn aanvoelen, niet thuis is in security en de klant een secure oplossing wil. Ik zou toch ook even durven voorstellen om een externe security consultant te overwegen om je hierin te helpen. (Nee, ik ben geen security consultant en ik bied mijn diensten dus ook niet aan.)

[lordgandalf]

Ik vraag me zoiezo af waarom men iets wat secure moet zijn remote wil benaderen . Zet bij je klant een bak neer met de applicatie das een stuk veiliger.
Daarnaast waarom de keuze voor flex lijkt me niet mega verstandig okee het ziet er leuk uit maar om flash in een webapp te gebruiken brrr.