Het makkelijkste is om dit met SSL te doen.
Daarmee heb je in ieder geval de encryptie van de
communicatie tussen de client en de server geregeld. Dan zou
je zelfs nog client certificaten kunnen gebruiken zodat je
redelijk zeker weet wie je gebruikers zijn.
De grote vraag is echter hoe veilig is de website zelf? En
hoe publiekelijk toegankelijk moet het worden?

Shameless plug ;-)

Er zijn meerdere methodieken te bedenken, maar het is altijd een
afweging tussen gebruikers gemak en veiligheid.

Het beste is de gebruiker een IPSec tunnel te laten opbouwen met de
server en deze doormiddel van certificaten te beveiliging..
veiligheid : 99.9999%
gebruikersgemak : 0

niet echt handig dus, je moet jezelf ook de vraag stellen, wil je het zelf
uitvinden of moet het reeds bestaan??

Als het reeds moet bestaan is HTTPS een optie, niet geheel veilig daar
inmiddels de gebruikte MD5 al als lek verklaard is, maar wel makkelijk,
iedere browser ondersteund het zo'n beetje en alle servers hebben wel
een plugin ervoor. dat is dus de "snelle oplossing"

Moeilijker maar een stuk veiliger is een eigen encryptor te schrijven welke
een tijd gerelateerde eenheid gebruikt om zijn data te versleutelen. Je kan
dan tussen client en server een tijdwindow afspreken waarbinnen de data
als geldig wordt ervaren. Als je deze klein genoeg maakt dan is het voor
sniffers niet interessant om het packet te spoofen en te injecten want dan
valt het pakket buiten zijn tijdframe. Let hierbij wel op dat het een must is dat beide partijen over een redelijk goed lopende systeem klok beschikken, want anders vallen alle packetten buiten het tijdwindow.
Dit is echter een specialisties werkje waarvoor je de nodige wiskundige
kennis dient te hebben. Dus misschien niet voor iedereen weggelegd om
te doen.

Primair advies zal blijven bij HTTPS, maar als je over de kennis en tijd
beschikt zou ik een eigen cryptor maken, informatie hierover vind je over
het algemeen wel bij google als je zoekt op "asynchonic encryption
algorithm".

Succes ermee

Die reactie van Michel van der Breggen vond ik een beetje
zinloos eigenlijk. Iemand die komt vragen hoe ie de data kan
beveiligen verwacht je toch niet van om zelf een crypto
implementatie te maken? Bovendien vind ik het maar een
gekunsteld idee van je met die time frame shit.. dat klinkt
als university research man.
SSL is veilig genoeg ook.. MD5 staat los van SSL, SSL is een
protocol en geen encryptie, eerder een model waar bestaande
crypto technieken in gebruikt kunnen worden, onderandere MD5
maar OOK SHA-1 of iets dergelijks.
Als laatste nog; het lijkt me niet dat deze persoon zoveel
aan z'n privacy hecht dat je in de sfeer van veiliger dan
SSL moet gaan denken, als je zo begint vraag je dan eerst
maar 's af of je wel over het internet zou moeten functioneren.
En als allerlaatste nog.. een IPSec tunnel met certificaten
is ook weinig veiliger dan SSL, wel leuk voor de fantasie.

Dus het antwoord is; gewoon SSL gebruiken en natuurlijk bij
voorkeur echt door een CA laten certificeren. Als dat teveel
gedoe is moet je maar self-signen en dan een kopie van het
certificaat nog even per mail sturen naar gebruikers, bij
voorkeur met PGP.. Zorgen dat alleen toegang via SSL
mogelijk is en geen andere services draaien.
Client-certificates zijn ook een goeie inderdaad. Daarmee
kun je dus ook zorgen dat alleen geauthoriseerde gebruikers
kunnen verbinden.

de reactie is niet geheel zinloos, de vraag is helder : welke methoden kan
ik gebruiken om mijn data te beveiligen. Er staat nergens in de eerste post
wat het kennis niveau van de persoon in kwestie is. Ik geef des gewenst
dan ook 2 mogelijke technieken aan van data beveiliging.

1. het beveiligen van de verbinding tussen de twee machines
2. het encrypten van de data zelf.

SSL mag dan een protocol wezen, ook deze is niet sterker dan zijn zwakste
schakel. Er dient dus goed te worden gekeken naar de manier waarop
SSL geïmplementeerd wordt in de applicaties zowel aan server als aan
client kant. Hier zal nl tijdens het onderhandelen over de beveiliging de
hoogste gemeenschappelijke beveiliging worden gekozen, en voor
sommige servers en clients ligt deze helaas niet hoger dan MD5 of DES.
Hierdoor mag het principe van SSL wel veilig zijn maar blijkt de
implementatie en daarmee de toepassing ernstig te kort te schieten.
Overigens dient daarnaast de kans op een man-in-the-middle attack in de
gekozen infrastructuur bekenen te worden en daar deze steeds meer op
switched netwerken gebaseerd is, is deze manier van "sniffen" over de lijn
ernstig klein geworden. maar dat is een geheel andere discussie dan
hetgeen hier gevraagd wordt.

De discussie of timeframe encryption een universitaire aangelegenheid is
wil ik best wel een bediscuseren maar daarvoor nodig ik mensen uit een
nieuwe thread op het forum te starten. maar ik verzeker je, dat valt
allersinds mee.

Ik zal mijn advies dan iets helderder omschrijven.

Opzich blijf ik bij SSL maar ik zou adviseren een restrictie op de clients in
te bouwen zodat de webpagina alleen browsers toe laat die minimaal een
SHA1 en 3DES encryptie ondersteunen, hierdoor ben je enigsinds
verzekerd dat de data veilig van client naar server gaat. Welke encryptie
protocolen door een client ondersteund worden vind je meestal terug in de
specificatie of een bijbehorende whitepaper.

Mjah, ik bedoel dat als je het hebt over het zelf bouwen en
implementeren van een eigen crypto toepassing dan vereis je
toch enige kennis, duidelijk niet kennis dat degene die de
vraag stelt heeft. Dat lijkt me nogal logisch.


Jah dat klinkt beter :-)

Een aantal mensen heeft ergens een klok horen luiden.......... SHA1 en
MD5 zijn hashing algortimes. (3)DES is een symetrische encryptie (CBC
block cipher). Een hasing algoritme is GEEN encryptie!

Typo: of had en moeten wezen.