Hallo.
Außnahmseise mal keine Contenido Frage... Es geht um SSL Verschlüsslung. Ein Shopbetreiber möchte gegen Einwilligung einer Einzugsermächtigung Waren verkaufen. Die Frage ist nun, ob es Vorschriften oder Empfehlungen gibt, Bankdaten, die von den Kunden bei ihrer Einwilligung angegeben werden (Kto, BLZ usw.), per SSL zu verschlüsseln.
Ist das gesetzlich vorgeschrieben? Wo könnte man sich darüber informieren? Oder ist das sogar völliger Blödsinn und man kann das mit einem normalen Formular erledigen?
Vielen Dank und Grüße,
wolfer
Keine Contenido Frage - aber vielleicht trotzdem fragen? SSL
Re: Keine Contenido Frage - aber vielleicht trotzdem fragen?
So, ich habe nun doch eine Seite mit Infos gefunden:wolfer hat geschrieben:Hallo.
Außnahmseise mal keine Contenido Frage... Es geht um SSL Verschlüsslung. Ein Shopbetreiber möchte gegen Einwilligung einer Einzugsermächtigung Waren verkaufen. Die Frage ist nun, ob es Vorschriften oder Empfehlungen gibt, Bankdaten, die von den Kunden bei ihrer Einwilligung angegeben werden (Kto, BLZ usw.), per SSL zu verschlüsseln.
Ist das gesetzlich vorgeschrieben? Wo könnte man sich darüber informieren? Oder ist das sogar völliger Blödsinn und man kann das mit einem normalen Formular erledigen?
Vielen Dank und Grüße,
wolfer
Bankeinzug über das Internet
Beim Bankeinzug über das Internet wird das Kundenkonto sofort belastet. Kontodaten sollten nie unverschlüsselt über das Internet versendet werden. Eine Verschlüsselung mit dem 128-Bit-SSL-Verfahren sollte als Mindestvoraussetzung gelten. Noch größere Sicherheit bietet das SET-Verfahren. Außerdem können Inkassosysteme (s.u.) als Mittler zwischen Kunde und Händler geschaltet werden.
Gesehen unter: http://www.vetion.de/internet/detail.cf ... nfo_id=811
Falls noch jemand anderes oder mehr weiß, freue ich mich natürlich über Beiträge.
Du meinst, lieber alle Angaben im Plaintext übertragen, statt mit SSL eine Punkt-zu-Punkt-Verschlüsselung vorzunehmen ...?Oder ist das sogar völliger Blödsinn und man kann das mit einem normalen Formular erledigen?

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Hallo HerrB,HerrB hat geschrieben:Du meinst, lieber alle Angaben im Plaintext übertragen, statt mit SSL eine Punkt-zu-Punkt-Verschlüsselung vorzunehmen ...?Oder ist das sogar völliger Blödsinn und man kann das mit einem normalen Formular erledigen?![]()
Gruß
HerrB
ich meine nichts. Ich habe keine Ahnung von dem Thema und versuche Infos zu sammeln. Und eine mögliche Alternative am Anfang war Plaintext, ja. Aber mittlerweile sehe ich, dass das keine Alternative ist, da überall Verschlüsslung empfohlen wird. (Worauf du, glaube ich, hinaus willst

ABER: Was ich mich noch gefragt habe: Verschlüsselt wird doch nur der Weg zwischen User auf der https Seite und dem Server. Der Rückweg aber (also eine generierte Mail vom Server an den Shopbetreiber) wäre doch wieder unverschlüsselt oder sehe ich das falsch? Und wenn das wirklich so wäre, was für einen Sinn macht dann die "Hinweg Verschlüsslung"?) Oder löst man das in der Praxis anders?
Gruß,
wolfer
da die meisten websites auf einem shared hosting (virtual server) betrieben werden, ist es nahezu unmöglich, hier eine sichere zahlungslösung anzubieten. ich würde dir empfehlen, ein zahlungsportal zu verwenden. in der schweiz stehen dazu z.b. saferpay und datatrans zur verfügung. die kosten was, bieten allerdings alle erforderliche sicherheit.
daneben gibt es ja die möglichkeit, rechnung zu stellen (mit oder ohne vorkasse) oder per nachnahme zu liefern. dort hat man kein sicherheitsproblem.
daneben gibt es ja die möglichkeit, rechnung zu stellen (mit oder ohne vorkasse) oder per nachnahme zu liefern. dort hat man kein sicherheitsproblem.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)