[Opgelost] BAWP: Frontend- en backendcommunicatie beveiligen

[leendert]

Ik heb nog even verder gezocht welke hostingpakketten ssl ondersteunen.
Maar de basispakketten ondersteunen dit volgens mij nooit. Zakelijke pakketten meestal wel.

je hebt namelijk een eigen ip-adres en ssl toegang nodig dus kom je bij de meeste internetproviders op een dedicated server uit.

De hoster moet dus zorgen voor:
- een dedicated IP-adres
- SSL toegang

Gemiddeld zijn de prijzen daarvoor 10 euro per maand bovenop je standaard kosten.


@ Wazzzaaa:je bent trouwens welkom in het team hoor als je zin hebt

[Rachid]

Ik heb nog even verder gezocht welke hostingpakketten ssl ondersteunen.
Maar de basispakketten ondersteunen dit volgens mij nooit. Zakelijke pakketten meestal wel.

je hebt namelijk een eigen ip-adres en ssl toegang nodig dus kom je bij de meeste internetproviders op een dedicated server uit.

De hoster moet dus zorgen voor:
- een dedicated IP-adres
- SSL toegang

Gemiddeld zijn de prijzen daarvoor 10 euro per maand bovenop je standaard kosten.

Ja, dat is een serieus nadeel Dan heb je uiteraard wel gelijk een getekend certificaat.

@ Wazzzaaa:je bent trouwens welkom in het team hoor als je zin hebt

Ik zou best willen helpen/adviseren met opzetten enzo. Maar ik heb geen tijd om straks ook alles uit te gaan werken.

[leendert]

Ik heb nog even verder gezocht welke hostingpakketten ssl ondersteunen.
Maar de basispakketten ondersteunen dit volgens mij nooit. Zakelijke pakketten meestal wel.

je hebt namelijk een eigen ip-adres en ssl toegang nodig dus kom je bij de meeste internetproviders op een dedicated server uit.

De hoster moet dus zorgen voor:
- een dedicated IP-adres
- SSL toegang

Gemiddeld zijn de prijzen daarvoor 10 euro per maand bovenop je standaard kosten.

Ja, dat is een serieus nadeel Dan heb je uiteraard wel gelijk een getekend certificaat.

Maarja de gebruiker moet dus wel van alles gaan regelen en configureren wat wij eigenlijk niet willen.
De ideale situatie is dat de gebruiker alleen wat bestanden moet uploaden en klaar.

Volgens mij hebben we dus twee mogelijkheden:
- Of we implementeren zelf een encrytie methode zoals RSA (en dat werkt dan in elke situatie)
- Of we laten het aan de gebruiker zelf over of ze de verbinding willen beveiligen of niet....En dat kost dan wat meer moeite en geld voor de gebruiker...

Ik zie zelf geen problemen in het zelf implementeren van RSA. Als we dat verhaal van die sleutel maar goed oplossen en meerdere mensen goed naar de implementatie laten kijken.

SSL zou het mooiste zijn natuurlijk maar dit kost dus wat meer energie + kosten aan de kant van de gebruiker.

Wat vinden jullie?

@ Wazzzaaa:je bent trouwens welkom in het team hoor als je zin hebt

Ik zou best willen helpen/adviseren met opzetten enzo. Maar ik heb geen tijd om straks ook alles uit te gaan werken.

Wil je rechten op onze wiki zodat je mee kan lezen + reageren?

[leendert]

Voordeel van RC4 is dat deze makkelijk te implementeren is (de code stelt echt niet veel voor en is zo over te maken van classes op internet) en ook erg snel is.
Elk bericht wordt versleuteld zowel van als naar de backend.
De sleutel stuur je ook mee met het bericht zodat het andere programma deze kan ontsleutelen (random gegenereerde sleutel) .

Ik vertaal dit even naar gewone mensen taal:
Ik stuur jou geld. Maar omdat ik niet wil dat andere kunnen zien of veranderen wat ik jou stuur. Doe ik het geld eerst in een kluis, en dan stuur ik de kluis op. Tevens stuur ik de sleutel van de kluis mee. Zodat jij de kluis open kan maken.

Misschien is dit een oplossing (beter dan mijn vorige voorstel om de sleutel zelf verslueteld mee te sturen):
Bij het genereren van de applicatie zorgen we dat er 5 sleutels gegenereerd worden. Deze moeten aan de kant van de back-end en de font-end in een bestandje terecht komen.
Vervolgens sturen we niet meer de sleutel mee maar alleen het id van de sleutel. Random wordt 1 van de 5 sleutels gekozen.
Zo heb je ten eerste niet altijd dezelfde sleutel (wat volgens mij de zwakte is van WEP) en wordt de sleutel niet meer zelf mee gestuurd maar alleen het id van de sleutel.

[Rachid]

Voordeel van RC4 is dat deze makkelijk te implementeren is (de code stelt echt niet veel voor en is zo over te maken van classes op internet) en ook erg snel is.
Elk bericht wordt versleuteld zowel van als naar de backend.
De sleutel stuur je ook mee met het bericht zodat het andere programma deze kan ontsleutelen (random gegenereerde sleutel) .

Ik vertaal dit even naar gewone mensen taal:
Ik stuur jou geld. Maar omdat ik niet wil dat andere kunnen zien of veranderen wat ik jou stuur. Doe ik het geld eerst in een kluis, en dan stuur ik de kluis op. Tevens stuur ik de sleutel van de kluis mee. Zodat jij de kluis open kan maken.

Misschien is dit een oplossing (beter dan mijn vorige voorstel om de sleutel zelf verslueteld mee te sturen):
Bij het genereren van de applicatie zorgen we dat er 5 sleutels gegenereerd worden. Deze moeten aan de kant van de back-end en de font-end in een bestandje terecht komen.
Vervolgens sturen we niet meer de sleutel mee maar alleen het id van de sleutel. Random wordt 1 van de 5 sleutels gekozen.
Zo heb je ten eerste niet altijd dezelfde sleutel (wat volgens mij de zwakte is van WEP) en wordt de sleutel niet meer zelf mee gestuurd maar alleen het id van de sleutel.

Het is al beter dat je de sleutel nu apart distribueert van hetgeen je versleuteld. Dat je 5 sleutels gebruikt is maar schijnveiligheid. Je doet een poging, maar het wordt er niet echt veiliger op. Je kunt dan net zo goed 1 sleutel gebruiken. Bekende protocollen die zichzelf hebben bewezen, spreken om de zoveel tijd een nieuwe sleutel af (volgens mij WPA ook).

Heb je ook al nagedacht hoe je zoiets in AJAX wilt doen? De javascript wordt gedownload van de server. Wordt de sleutel dan mee gedownload? Beetje schijnveiligheid, eerst stuur je ene sleutel, vervolgens ga je er vrolijk dingen mee encrypten. Als iemand de hele tijd meeluistert kan hij dus die dingen decrypten.

Beveiliging
Ik wil even terugkomen op jullie eerste vraag. Waarom willen jullie eigenlijk beveiliging. En tegen wat wil je je beveiligen?
Je moet een afweging maken tussen wat je belangrijk vind. Security gaat vaak ten koste van een stukje gebruikersvriendelijkheid(denk aan internetbankieren). Het is meestal minder gebruikersvriendelijk om bij je bank in te loggen. Maar de mensen hebben dat er wel voor over gezien ze de veiligheid van hun rekening HEEL belangrijk vinden.

[leendert]

Het is al beter dat je de sleutel nu apart distribueert van hetgeen je versleuteld. Dat je 5 sleutels gebruikt is maar schijnveiligheid.

Oke, dat zou kunnen...
Ik dacht dat het voorspelbaarder wordt als je steeds dezelfde sleutel gebruikt. En dat een mee-luisteraar dus sneller alle berichten kan ontsleutelen.

Heb je ook al nagedacht hoe je zoiets in AJAX wilt doen? De javascript wordt gedownload van de server. Wordt de sleutel dan mee gedownload? Beetje schijnveiligheid, eerst stuur je ene sleutel, vervolgens ga je er vrolijk dingen mee encrypten. Als iemand de hele tijd meeluistert kan hij dus die dingen decrypten.

Nee, daar had ik inderdaad niet aan gedacht.
Ik heb in verschillende artikelen op internet gezien dat ze gewoon de sleutel versleuteld dmv een hashfunctie meesturen...dit schijnt gewoon veilig te zijn...maar snappen doe ik het nog niet helemaal.

Beveiliging
Ik wil even terugkomen op jullie eerste vraag. Waarom willen jullie eigenlijk beveiliging. En tegen wat wil je je beveiligen?
Je moet een afweging maken tussen wat je belangrijk vind. Security gaat vaak ten koste van een stukje gebruikersvriendelijkheid(denk aan internetbankieren). Het is meestal minder gebruikersvriendelijk om bij je bank in te loggen. Maar de mensen hebben dat er wel voor over gezien ze de veiligheid van hun rekening HEEL belangrijk vinden.

We willen de data versleutelen omdat er dus ook zakelijke applicaties mee gebouwd moeten gaan kunnen worden. In dat geval wil je volgens mij niet dat alle gegevens onversleuteld over het internet gaan.

[Ronnie]

Wie draait eigenlijk de server met de BAWP applicatie? Zijn jullie dat, of is dat het bedrijf dat een applicatie in BAWP geschreven heeft

In het 2e geval is het volgens mij het bedrijf dat voor de certificaten/beveiligde verbinding zorgt. BAWP zijn taak is het dan alleen nog maar om aan de hand van het certificaat het bericht te ontcijferen.

De clients hoeven alleen maar de certificaten van bedrijf (XYZ) te accepteren, als de IT afdeling van het bedrijf dit al niet op de bedrijfslaptops heeft gedaan.

Of heb ik het nu mis (ben ook niet zo goed in beveiliging etc)

[Rachid]

We willen de data versleutelen omdat er dus ook zakelijke applicaties mee gebouwd moeten gaan kunnen worden. In dat geval wil je volgens mij niet dat alle gegevens onversleuteld over het internet gaan.

Ik stel voor om datgene te doen wat iemand anders al eerder had voorgesteld. Een optie om SSL te gebruiken. Iemand die het zakelijk gebruikt heeft meer belang bij veiligheid. Dus zeker ook wel wat geld over voor veiligheid!

[leendert]

We willen de data versleutelen omdat er dus ook zakelijke applicaties mee gebouwd moeten gaan kunnen worden. In dat geval wil je volgens mij niet dat alle gegevens onversleuteld over het internet gaan.

Ik stel voor om datgene te doen wat iemand anders al eerder had voorgesteld. Een optie om SSL te gebruiken. Iemand die het zakelijk gebruikt heeft meer belang bij veiligheid. Dus zeker ook wel wat geld over voor veiligheid!

Dat is ook wat mij na deze discussie het beste lijkt. Zelf niets doen aan versleuteling, als de gebruiker het zo belangrijk vind kunnen ze zelf SSL regelen...

[commandoline]

Ik ben op zich akkoord.

Wel zie ik nog dit probleem:

- Je verstuurt authenticatiegegevens onversleuteld. Dan kan iemand dus door het verkeer in de gaten te houden, het hele systeem afbreken. Dat geldt nu ook voor bijv. onbeveiligde e-mail, maar dan kun je door slechte beveiliging alleen je eigen account vernielen, en niet alle accounts op de server. Wij werken wel met één centrale DB.

Goed rechtenmanagement lijkt me dus belangrijk, en het is misschien de moeite waard om verwijderde/veranderde info te bewaren voor een bepaalde tijd, als die verstreken is en de backend word gebruikt kan die automatisch worden opgeruimd.

Om dit topic af te ronden:
@Leendert, wil jij de wikipagina over de frontend/backendcommunicatie bijwerken? Jij hebt op dit moment het beter in je hoofd dan mij, en bent technisch ook beter op dit gebied.

@Wazzzaaa, ten eerste bedankt voor je hulp. Ten tweede wil ik nog even herhalen dat je altijd welkom in het team bent, maar als je het daarvoor te druk hebt is dat natuurlijk logisch.