Bitte mal die Sicherheit beurteilen
Kalle
- programmiertechnik
0 MudGuard0 Magic Mike0 Maddin0 Henryk Plötz
Hallo,
für einen Versandhandel soll die Zahlung unter anderem per Banklastschrift möglich sein.
Jedoch möchte ich die Konto-Nr. und Bankleitzahl nicht im Klartext aus einem Formular posten.
Idee 1 (ohne Javascript):
Die Ziffern werden zwischen anderen "versteckt". Der User muss Pluszeichen durch seine Ziffern ersetzen. Die Position der Pluszeichen wird im Ernstfall bei jedem Abruf neu bestimmt.
Idee 2 (mit Javascript):
Die eingegebene Kontonummer (a) wird codiert, indem ihr ein Code (b) gegenübersteht. Ziffer für Ziffer wird nun a von b abgezogen. Natürlich auch hier: Bei jedem Aufruf ein neuer Code.
Hiert die Testseite: [URL]http://www.weinverzeichnis.de/lastschrift.htm[/URL]
Das ist nicht absolut wasserdicht, aber doch wohl ganz tauglich ?
Kalle
Hi,
Jedoch möchte ich die Konto-Nr. und Bankleitzahl nicht im Klartext aus einem Formular posten.
Idee 1 (ohne Javascript):
Die Ziffern werden zwischen anderen "versteckt". Der User muss Pluszeichen durch seine Ziffern ersetzen. Die Position der Pluszeichen wird im Ernstfall bei jedem Abruf neu bestimmt.
Unsicher, da vom User abhängig.
Idee 2 (mit Javascript):
Die eingegebene Kontonummer (a) wird codiert, indem ihr ein Code (b) gegenübersteht. Ziffer für Ziffer wird nun a von b abgezogen. Natürlich auch hier: Bei jedem Aufruf ein neuer Code.
Unsicher, da von clientseitiger Technologie abhängig.
Schon mal von https gehört?
Ich würde NIE Bank- oder Kreditkartendaten über http angeben.
Das ist nicht absolut wasserdicht, aber doch wohl ganz tauglich ?
Das ist nicht absolut wasserdicht und daher absolut untauglich.
cu,
Andreas
Moin Kalle,
Hiert die Testseite: [URL]http://www.weinverzeichnis.de/lastschrift.htm[/URL]
Ich kann dazu nur sagen: www.autsch.de
Das macht doch IMHO niemand mit.
regds
mike
Idee 1 (ohne Javascript):
Die Ziffern werden zwischen anderen "versteckt". Der User muss Pluszeichen durch seine Ziffern ersetzen. Die Position der Pluszeichen wird im Ernstfall bei jedem Abruf neu bestimmt.
Viel zu kompliziert.
Idee 2 (mit Javascript):
Die eingegebene Kontonummer (a) wird codiert, indem ihr ein Code (b) gegenübersteht. Ziffer für Ziffer wird nun a von b abgezogen. Natürlich auch hier: Bei jedem Aufruf ein neuer Code.
Taugt gegen Abhören gar nichts.
Das ist nicht absolut wasserdicht, aber doch wohl ganz tauglich ?
Das ist alles andere als wasserdicht. Was hindert Dich daran, https einzusetzen?
Das ist alles andere als wasserdicht. Was hindert Dich daran, https einzusetzen?
Es kostet Geld!
Hast Du Dich mal um die Gebühren für Zertifikate und entsprechende Server erkundigt.
Manche Provider bieten sogenannte SSL Proxys an.
Da muß man halt mal gucken.
Das wäre auch die einzige preiswerte Alternative, ich würde mal nach SSL Proxy googlen.
Im Übrigen, meine Kontonummern von der Firma stehen auf jedem Briefbogen. Was ist daran geheim?
Hi,
Es kostet Geld!
und bringt auch welches. Auf SSL zu verzichten ist bei brisanten Daten *keine* Lösung.
Im Übrigen, meine Kontonummern von der Firma stehen auf jedem Briefbogen. Was ist daran geheim?
Es geht nicht um geheim, sondern um sicher. Unverschlüsselte Daten können abgefangen und missbraucht werden; durch ihre Veränderung beim eigentlichen Vorgang wird dann (gewöhnlich) eine Fehlermeldung erzeugt, die zur erneuten Eingabe aufruft, welche dann nicht abgefangen wird und dem User ein "alles ist in Ordnung"-Gefühl vermittelt. Dies ist nur _eine_ Möglichkeit des Missbrauchs - der online durch die implizite Bestätigung des Besitzers der Bankverbindung wesentlich leichter ist.
Cheatah
hi,
Das ist alles andere als wasserdicht. Was hindert Dich daran, https einzusetzen?
Es kostet Geld!
wenn kalles verfahren darauf basiert, dass der _benutzer_ seine kontodaten selbständig "kodieren" muss, in dem er irgendwelche zeichen einfügt, kostet das effektiv sicher mehr.
nimm den fall an, der benutzer vertut sich beim "kodieren".
gruss,
wahsaga
Hi,
wenn kalles verfahren darauf basiert, dass der _benutzer_ seine kontodaten selbständig "kodieren" muss, in dem er irgendwelche zeichen einfügt, kostet das effektiv sicher mehr.
nimm den fall an, der benutzer vertut sich beim "kodieren".
Nicht nur das. Es darf nicht vergessen werden, daß allein durch dieses
"Ich soll da meine Kontonummer seltsam kodieren"
viele Kunden abgeschreckt werden.
"Bei anderen Online-Shops brauch ich so umständliche Sachen nicht machen, da kauf ich lieber woanders"
und weg ist der Kunde.
cu,
Andreas
Moin,
Das ist nicht absolut wasserdicht, aber doch wohl ganz tauglich ?
Hmm, wofür soll es taugen? Als Lacher zwischendurch? Sicherlich. Als schlechtes Beispiel? Ganz bestimmt. Zur Sicherung der Übertragung? Absolut nicht.
Definiere doch mal bitte ganz genau was für eine Art von Angriffen du abwenden möchtest, inwiefern diese Angriffsarten eventuell relevant sind und vor allem wie deine Maßnahmen geeignet wären diese Angriffe abzuwenden. Dir wird dann auffallen, dass es genau gar nichts bringt, wenn du den Schlüssel zur 'Verschlüsselung' über den selben Kanal (HTTP-Verbindung zwischen Browser und Server über das Internet) überträgst, dem du keine unverschlüsselten Daten anvertrauen wolltest. Dass du noch ganz andere Probleme bekommst, wenn du keine echten Zufallszahlen als Schlüssel einsetzt, ist dann eher noch zweitrangig.
Benutze doch einfach existierende, etablierte und von allen möglichen Menschen untersuchte Kryptosysteme. Sicherlich baut sich jeder der sich mit Programmierung beschäftigt einmal in seinen Anfangszeiten ein eigenes 'Verschlüsselungs'system (ich bin da keine Ausnahme), aber die werden regelmäßig von erfahreneren Kryptographen in der Luft zerrissen und sollten nicht ohne weitere Untersuchung auf die Öffentlichkeit losgelassen werden.
Für deinen Einsatzzweck kommen schon mal keine Algorithmen mit einem Schlüssel zum Ver- und Entschlüsseln in Frage, da du den Schlüssel zuvor über einen sicheren Kanal übertragen müsstest. Bleibt im Wesentlichen noch ein Diffie/Hellman key exchange (und dann doch wieder ein symmetrischer Algorithmus) oder einer der vielen public key-Algorithmen. Da mir keine Implementierung von einem davon in JavaScript bekannt ist und du wahrscheinlich keine schreiben willst: Nimm HTTPS.