Online reserveringssysteem.... SSL ?

[Verwijderd]

Ik ga over een paar weken een online reserveringssysteem opzetten. In de huidige situatie worden ingevulde formuliertjes per mail verstuurd en daarna verwerkt in een Excel sheet. In de toekomst moeten deze gegevens in een database komen.

Om het probleem van nutteloze info (gebruikers die de database verzieken) had ik in gedachten om een soort van buffer database te gebruiken. Een medewerker kan dan inloggen, de data in de buffer database valideren en eventuele onzin verwijderen. Hierna middels een druk op een validate button de inhoud overhevelen in de werkelijke database. Is deze methode goed, of zijn er goede alternatieven?

Nog een ander probleem is dat er credit card gegevens in de database komen. Dus er zal qua beveiliging wat gedaan moeten worden. Ik heb me laten vertellen dat dit mbv SSL opgelost kan worden, maar hier weet ik gewoon veel te weinig van af. Is dit een beetje te doen? Waar moet ik rekening mee houden? Is SSL te gebruiken icm PHP?

Ik wil het geheel dus op gaan zetten met een MySQL database en PHP. Of kan ik beter terugvallen op ASP en een reeds bestaande Access database?
Ik weet nog niet of de host van de site ondersteuning biedt voor PHP, MySQL, ASP en SSL maar anders wordt eventueel overgestapt op een ander bedrijf dat deze diensten wel aanbiedt.

Wie kan mij over bovenstaande zaken wat duidelijkheid geven?

[chem]

SSL gaat niet je database beveilingsprobleem oplossen. Ga eens goed lezen wat het is
PHP en SSL gaan wel samen: Apache kan SSL draaien en PHP draait als onderdeel van Apache (IIS hetzelfde verhaal ongeveer).

Hoe je dit moet beveiligen? Ja, het standaard verhaal zo'n beetje. Vertrouw nooit input van de user, en zorg dat de bak up to date is, zeker als het een Windows kreng is vol met gaten.
Je kan je PHP zooi nog zo dicht bouwen: als men via een IIS lek naar binnenkomt is al je moeite voor niks.

Verder: nutteloze input valt best mee hoor. Ik heb zelf een webshop en daar krijgen we ook nepbestellingen maar daar is snel de lol van af meestal.

[Verwijderd]

Ik zou als ik zelf zou moeten kiezen voor PHP en MySQL kiezen...opzich redelijk logisch aangezien ik PHP programmeur van beroep ben...maar technisch gezien is PHP ook beter aangezien je PHP vrijwel op elke webserver te gebruiken valt en ASP enkel op IIS (tenzij er een naar third-party oplossingen wordt gekeken als ChillisoftASP kan het dus ook op bv Linux draaien).

Veder denk ik dat PHP/MySQL zich het beste leent voor een applicatie als deze.

SSL is icm met PHP te gebruiken.

Het idee van een tijdelijke/buffer tabel om invoer in opteslaan en te valideren is een zeer goed idee, ik heb soort gelijke oplossingen al vaker gebruikt, en dat
werkt perfect.

Als je trouwens besluit om de applicatie in PHP te ontwikkelen ben ik wel bereid je te helpen indien je vragen hebt, hiervoor ben ik op MSN of per e-mail bereikbaar op [e-mail]

[Glimi]

Op woensdag 15 mei 2002 11:09 schreef skunkah het volgende:
Ik zou als ik zelf zou moeten kiezen voor PHP en MySQL kiezen...opzich redelijk logisch aangezien ik PHP programmeur van beroep ben...maar technisch gezien is PHP ook beter aangezien je PHP vrijwel op elke webserver te gebruiken valt en ASP enkel op IIS (tenzij er een naar third-party oplossingen wordt gekeken als ChillisoftASP kan het dus ook op bv Linux draaien).

Tjah, dat is geen technisch argument he? Da's gewoon een keuze geweest van Microsoft.
Advies voor de topicstarter: Heb je enige ervaring met alles? Nee --> Laat het dan ontwikkelen als het veel geld moet gaan opleveren (een paar weken voor een echt goed script + leertijd is niet veel)
Heb je wel ergens (gedegen?) ervaring mee, kies dan het liefst voor _die_ oplossing. (hoewel access technisch vaak toch niet echt meetelt).
Daarmee bedoel ik dus, ga niet iets nieuws leren voor iets wat goed moet zijn. Als je iets nieuws gaat leren moet je eerst experimenteren enz

[Verwijderd]

Ik heb wel ervaring met PHP en MySQL. Verder heb ik ook een tijdje met ASP icm een Access en ASP icm een SQL Server database gewerkt. Maar daar is het bij gebleven. Mijn voorkeur gaat dus uit naar PHP en MySQL. Moet alleen even uitzoeken of de huidige host van de site het ook ondersteund. Maar goed.

Ik ben dus absoluut niet bekend met SSL. Maar een kennis van me vertelde dat dat toch voor een groot gedeelte de beveiliging van met name de Credit Card nummers op zou moeten lossen. Al krijg ik hier dus te horen van niet. Hoe kan ik dat probleem opvangen. Of is dat gewoon een kwestie van een beveiliging bij de host ?

[Janoz]

SSL is alleen een beveiliging van de communicatie, niet van de gegevens op je site.

[Glimi]

SSL versleutelt alleen het verkeer van en naar je webserver, wat betekend dat niemand het crditcard# kan sniffen als de persoon deze invoert.
Validatie ed. heb je hier niet mee gedekt! Daar moet je SET voor gaan gebruiken. Maar dat is _echt_ schreeuwend duur (vorig jaar nov. iig)

[Verwijderd]

OK SSL dus voor de communicatie.
Maar wat is er te doen tegen het beveiligen van de CC nummers in de database. Of is dat eigenlijk veilig genoeg?? Het aangedragen SET is geen oplossing, omdat het qua prijs gewoon niet haalbaar is. Iemand alternatieven ???

[Glimi]

Op woensdag 15 mei 2002 12:19 schreef MiKe_V het volgende:
OK SSL dus voor de communicatie.
Maar wat is er te doen tegen het beveiligen van de CC nummers in de database. Of is dat eigenlijk veilig genoeg?? Het aangedragen SET is geen oplossing, omdat het qua prijs gewoon niet haalbaar is. Iemand alternatieven ???

Het enigste wat ik kan bedenken is het via RSA, DES oid versleutelen in je DB en de key buiten de db houden. Echter ik zou toch echt ff gaan informeren bij visa of mastercard, misschien hebben ze daar een goeie oplossing voor (zoals misschien aandraven van een cc in een hash? ik zeg maar wat), want er zijn echt niet veel mensen met SET (het is echt duur!)

[Verwijderd]

Nee ok, niet te duur nee. Maar er zullen toch heus wel meer mensen zijn die een dergelijk systeem opgezet hebben. In ieder geval een online database met gegevens die veilig moeten staan?

Of is het risco gewoon niet groot...

[chem]

je kan het ook door een anader laten doen, zoals bv BIBIT (.com)

[HansMij]

Het robleem van de database is dat mensen niet op je MySQL-server moeten kunnen komen. Dit kan door uitsluiten poort 3306 (MySQL) open te gooien, als je PHP erop draait moet poort 80 (HTTP) en 443 (HTTPS voor SSL) ook open.

Dit kan een probleem opleveren.

Verder zou je in MySQL kunnen instellen wie erin moet kunnen (Alleen jouw Apache dus) dat IP kun je in MySQL opgeven en dan heb je je gegevens redelijk veilig.


suck6

[Verwijderd]

Dus dan heb je eigenlijk hetvolgende:

De credit card nummers worden opgeslagen in de online database. Eenmaal in de database ligt de verantwoording voor de beveiliging van de gegevens bij de host van de website die ook de database op zijn server heeft staan. Een eventuele hacker is dus de zorg voor de host?
Het enige waar ik dan rekening mee moet houden is het verzenden van de gegevens naar de database toe en dat gebeurd dus met SSL?

Zie ik het zo dan goed?

[Verwijderd]

Schop... Kan iemand hier iets meer over vertellen ????

[Glimi]

Op woensdag 22 mei 2002 15:45 schreef MiKe_V het volgende:
Dus dan heb je eigenlijk hetvolgende:

De credit card nummers worden opgeslagen in de online database. Eenmaal in de database ligt de verantwoording voor de beveiliging van de gegevens bij de host van de website die ook de database op zijn server heeft staan. Een eventuele hacker is dus de zorg voor de host?
Het enige waar ik dan rekening mee moet houden is het verzenden van de gegevens naar de database toe en dat gebeurd dus met SSL?

Zie ik het zo dan goed?

Ik zou daar niet op rekeken. JIJ hebt die creditcard nummers vertrouwlijk toegespeeld gekregen. JIJ bent ook degene die er verantwoordelijk voor is en ze geheim moet houden. Je kan NIET je verantwoordelijkheid op de host afschuiven. Lees de kleine lettertjes in het contract dat je met hem hebt nog even door zou ik zeggen!

[Annie]

1. Als je geen onzin gegevens in je database wil zorg dan voor een systeem dat een gedegen referentiele integriteit kan verzorgen. En transaction support is ook wel handig.
Ik bedoel: dat gebruikers af en toe onzin plaatsen is niet zo erg (dat filter je er later uit), maar als je door een corrupte database ineens reserveringen mist zit je met een probleem.

2. Sla geen creditcard gegevens op in je database (nergens voor nodig). Sterker nog; als ik weet dat jij m'n CC gegevens opslaat kan je er zeker van zijn dat ik nooit wat bij je bestel.

btw. skunkah:
Nu niet meer zoveel onzin uitkramen graag (drugs are bad, m'kay).

[Glimi]

Op maandag 27 mei 2002 23:05 schreef Annie het volgende:
2. Sla geen creditcard gegevens op in je database (nergens voor nodig). Sterker nog; als ik weet dat jij m'n CC gegevens opslaat kan je er zeker van zijn dat ik nooit wat bij je bestel.

Hoe wil je dit gaan doen dan? Laten uitprinten door de server? (dan moet je wel een vette verbinding in je kantoor hebben), laten mailen naar je? (onveilig!) of SET? (heb je die kosten ooit gezien )

Ik kan in ieder geval geen andere optie bedenken, plz correct me if wrong

[dawuss]

Een goed geconfigureerde linux bak met goed geconfigureerde mySQL server is volgens mij toch echt enorm veilig. Dan moet je nog zorgen dat je PHP geen foutjes bevat, waardoor ze in de database kunnen komen. Misschien een idee om een user aan te maken in MySQL die alleen creditcard nummers mag schrijven en niet mag lezen. In dat geval kan alleen iemand die een andere username en wachtwoord heeft op de MySQL server de creditcardgegevens lezen.

[Annie]

Op maandag 27 mei 2002 23:30 schreef Glimi het volgende:
(heb je die kosten ooit gezien )

zegt het spreekwoord: "voor een dubbeltje op de eerste rang zitten" iets?

[raptorix]

Op maandag 27 mei 2002 23:30 schreef Glimi het volgende:

[..]

Hoe wil je dit gaan doen dan? Laten uitprinten door de server? (dan moet je wel een vette verbinding in je kantoor hebben), laten mailen naar je? (onveilig!) of SET? (heb je die kosten ooit gezien )

Ik kan in ieder geval geen andere optie bedenken, plz correct me if wrong

Ik heb ook paar jaar lang online shops gehad, database is mooi maar absoluut niet veilig, ik liet creditcard nummers naar me toe mailen, en deze gingen gewoon netjes in een los databaseje wat niet aan internet gekoppelt was, wil je het echt in je database dan kan moet je eigenlijk een crypto component gaan gebruiken alhoewel dat ook niet helemaal uitsluit dat je in de gegevens kan komen.

Als ik je zo hoor ontbreekt het je aan fundamentele kennis, 2 opties geef opdracht uit handen, danwel besteed uit aan een payment service, BIBIT is echt reuze goedkoop en makkelijk te implementeren.

[oh,when?]

Op dinsdag 28 mei 2002 01:29 schreef raptorix het volgende:

...database is mooi maar absoluut niet veilig, ik liet creditcard nummers naar me toe mailen...

Sorry, maar dat vind ik dus zeer krom. Ik geef toe dat creditcard nummers in een online database niet echt verstandig is, maar om creditcard nummers gewoon naar je toe te laten mailen is net zo onveilig.

Op dinsdag 28 mei 2002 01:29 schreef raptorix het volgende:
BIBIT is echt reuze goedkoop en makkelijk te implementeren.

I second that

[igmar]

OK SSL dus voor de communicatie.
Maar wat is er te doen tegen het beveiligen van de CC nummers in de database. Of is dat eigenlijk veilig genoeg?? Het aangedragen SET is geen oplossing, omdat het qua prijs gewoon niet haalbaar is. Iemand alternatieven ???

Ik heb ooit een extensie geschreven voor PostGreSQL die de data versleuteld in de database opsloeg. Je kan de codering ook eventueel in PHP doen (mcrypt extensie), of door bv MySQL laten afhandelen. MySQL is redelijk modulair, dus die extensie zou geen echt zware hoofdbrekens moeten opleveren.

RedHat biedt de CCVE, een engine die als enig levensdoel heeft het valideren van creditcard gegevens. Misschien daar eens na kijken, al weet ik niet of het ook werkt ism Nederlandse banken.

[Verwijderd]

Ik heb de opdracht ook niet. Iemand heeft mij gevraagd om iets uit te zoeken. Op een bestaande website kun je je inschrijven voor een evenement. Allerlei gegevens moeten worden ingevuld. Op dit moment worden dus ook naam van kaarthouder, nummer en type gewoon in een edit veldje ingevoerd en via een submit naar dat bedrijf gestuurd. Daar typt een medewerker de gegevens in op een Excel sheet. Dus het gebeurd dan al op een onveilige manier.
Nu willen ze de zaak gaan vergemakkelijken. De gegevens moeten gewoon rechtstreeks in een database komen. Aan mij de vraag wat en hoe. Ik heb alleen weinig tot geen verstand van de beveiliging van die gegevens.

Wat kan ik hier het beste mee doen...