Thema: API Schnittstelle Alternativvorschlag
freesimpsons
+18
29.10.2014 08:59
Hallo,
ich hätte einen Alternativvorschlag bzgl. der Abschaltung der API - Schnittstelle von ebesucher.
Mein Gegenvorschlag würde so aussehen:
Die Schnittstelle in der jetzigen Form wird zum 31.12.2014 global für alle abgeschaltet. Der Benutzer kann nun entscheiden, ob er die Schnittstelle weiterhin benutzen möchte oder nicht. Er kann dieses unter Einstellungen aktivieren bzw. deaktivieren. Wenn er diese aktiviert, so hat der User die Möglichkeit ein TAN per Brief oder SMS zu bekommen.
Ich stelle mir das so wie beim Online Banking vor. Warum also das Rad neu erfinden wenn es sowas schon gibt? Der User bekommt bei Brief einen Brief von ebesucher mit 100 TAN´s. Möchte der User Punkte transferieren, so bekommt er eine Meldung: "Geben Sie TAN 76 ein". Der User schaut auf seine Liste und gibt TAN 76 ein.
Hat der User hingegen allerdings SMS ausgewählt, so bekommt der User eine SMS auf sein Handy geschickt. Unsere Handynummern mussten wir bereits eh schon angeben.
Das ganze in der jetzigen Zeit würde ich bis zum 31.12. laufen lassen, da das System ja auch erst mal programmiert werden müsste.
Zudem muss der User bei der Aktivierung der Schnittstelle zustimmen, dass ebesucher bei Punkteverlust nicht haftet. Somit ist ebesucher draussen und hat keine zusätzliche Arbeit mehr und kann sich auf das Kerngeschäft konzentrieren.
Natürlich kann ebesucher für den Brief bzw. SMS Geld bzw. ebesucher verlangen. Für die Premium Plus User könnte man das ganze kostenlos anbieten bzw. 10 SMS pro Monat frei. Das ist ein weiterer positiver Effekt für Premium Plus User.
Vorteile:
- viele User werden wahrscheinlich wegen dem API Verlust sich von ebesucher abmelden bzw. nicht mehr nutzen
- die Schnittstelle gibt es weiter und muss nur etwas geändert werden
- durch die TAN´s kann die API Schnittstelle weiterleben und es ist für beide Seiten sicherer
Bitte schreibt dazu, ob euch meine Idee gefällt oder nicht.
Hallo,
ich hätte einen Alternativvorschlag bzgl. der Abschaltung der API - Schnittstelle von ebesucher.
Mein Gegenvorschlag würde so aussehen:
Die Schnittstelle in der jetzigen Form wird zum 31.12.2014 global für alle abgeschaltet. Der Benutzer kann nun entscheiden, ob er die Schnittstelle weiterhin benutzen möchte oder nicht. Er kann dieses unter Einstellungen aktivieren bzw. deaktivieren. Wenn er diese aktiviert, so hat der User die Möglichkeit ein TAN per Brief oder SMS zu bekommen.
Ich stelle mir das so wie beim Online Banking vor. Warum also das Rad neu erfinden wenn es sowas schon gibt? Der User bekommt bei Brief einen Brief von ebesucher mit 100 TAN´s. Möchte der User Punkte transferieren, so bekommt er eine Meldung: "Geben Sie TAN 76 ein". Der User schaut auf seine Liste und gibt TAN 76 ein.
Hat der User hingegen allerdings SMS ausgewählt, so bekommt der User eine SMS auf sein Handy geschickt. Unsere Handynummern mussten wir bereits eh schon angeben.
Das ganze in der jetzigen Zeit würde ich bis zum 31.12. laufen lassen, da das System ja auch erst mal programmiert werden müsste.
Zudem muss der User bei der Aktivierung der Schnittstelle zustimmen, dass ebesucher bei Punkteverlust nicht haftet. Somit ist ebesucher draussen und hat keine zusätzliche Arbeit mehr und kann sich auf das Kerngeschäft konzentrieren.
Natürlich kann ebesucher für den Brief bzw. SMS Geld bzw. ebesucher verlangen. Für die Premium Plus User könnte man das ganze kostenlos anbieten bzw. 10 SMS pro Monat frei. Das ist ein weiterer positiver Effekt für Premium Plus User.
Vorteile:
- viele User werden wahrscheinlich wegen dem API Verlust sich von ebesucher abmelden bzw. nicht mehr nutzen
- die Schnittstelle gibt es weiter und muss nur etwas geändert werden
- durch die TAN´s kann die API Schnittstelle weiterleben und es ist für beide Seiten sicherer
Bitte schreibt dazu, ob euch meine Idee gefällt oder nicht.
Devtronic
0
31.10.2014 18:22
Das große Projekt was ich in dem riesen Thema bzgl. der Abschaltung erwähnt habe war soetwas ähnliches, ein Payment-System basierend auf BTP und MTP.
Kurz zusammengefasst:
Benutzer verwendet dann die API des Paymentsystems, Punkte werden an dieses Transferiert und solange eingefroren bis beide Seiten bestätigt haben das der Deal in Ordnung ist.
Für diejenigen die es interessiert, hier hatte ich eine Temporäre Projekt Page, die ich leider jetzt umsonst habe...
http://ebpayment.de/index.php?page=3
Schade eigentlich...
Das große Projekt was ich in dem riesen Thema bzgl. der Abschaltung erwähnt habe war soetwas ähnliches, ein Payment-System basierend auf BTP und MTP.
Kurz zusammengefasst:
Benutzer verwendet dann die API des Paymentsystems, Punkte werden an dieses Transferiert und solange eingefroren bis beide Seiten bestätigt haben das der Deal in Ordnung ist.
Für diejenigen die es interessiert, hier hatte ich eine Temporäre Projekt Page, die ich leider jetzt umsonst habe...
http://ebpayment.de/index.php?page=3
Schade eigentlich...
Jeff
+5
08.11.2014 12:44
Vielen Dank für Deine Vorschläge! Du hast in deinem Beitrag zwei grundsätzlich unterschiedliche Verfahren beschrieben. Deswegen werde ich einzeln darauf eingehen.
1) "Der User bekommt bei Brief einen Brief von ebesucher mit 100 TAN´s."
Das von Dir beschriebene Verfahren gleicht dem sogenannten iTAN-Verfahren. Der Grundgedanke ist aus unserer Sicht gut und wir haben die Umsetzung dieses Verfahrens zuvor einmal in Erwägung gezogen. Vor 2012 fand das Vorgehen noch breite Anwendung. Inzwischen gibt es jedoch neue Erkenntnisse, die dagegen sprechen. Siehe dazu z.B. die Meldung des BKA bei Heise Security.
Es ist aus wirtschaftlicher Sicht sehr bedenklich Geld, Zeit und Mühe für die Entwicklung eines Sicherheitssystems aufzuwenden, welches bereits jetzt als veraltet und unsicher gilt.
2) "Hat der User hingegen allerdings SMS ausgewählt, so bekommt der User eine SMS auf sein Handy geschickt."
Das von Dir beschriebene Verfahren gleicht dem sogenannten mTAN-Verfahren. Über die Umsetzung dieses Verfahrens haben wir ebenfalls bereits nachgedacht. Grundsätzlich ist es sicherer, als das iTAN-Verfahren, löst aber nicht alle Probleme. So häufen sich inzwischen Meldungen über die Unsicherheit dieses Verfahrens: z.B. bei der Zeit und bei Chip.
Deshalb halte ich den Einsatz dieses Verfahrens aus heutiger Sicht ebenfalls für nicht empfehlenswert.
Eventuell hast Du noch andere Ideen hinsichtlich möglicher Neuerungen. Der Übersicht halber schlage ich vor, dass wir in folgendem Thread weiter diskutieren: http://forum.ebesucher.de/threads/28922-Deaktivierung-der-Transfer-Funktion?p=229572
Vielen Dank für Deine Vorschläge! Du hast in deinem Beitrag zwei grundsätzlich unterschiedliche Verfahren beschrieben. Deswegen werde ich einzeln darauf eingehen.
1) "Der User bekommt bei Brief einen Brief von ebesucher mit 100 TAN´s."
Das von Dir beschriebene Verfahren gleicht dem sogenannten iTAN-Verfahren. Der Grundgedanke ist aus unserer Sicht gut und wir haben die Umsetzung dieses Verfahrens zuvor einmal in Erwägung gezogen. Vor 2012 fand das Vorgehen noch breite Anwendung. Inzwischen gibt es jedoch neue Erkenntnisse, die dagegen sprechen. Siehe dazu z.B. die Meldung des BKA bei Heise Security.
Es ist aus wirtschaftlicher Sicht sehr bedenklich Geld, Zeit und Mühe für die Entwicklung eines Sicherheitssystems aufzuwenden, welches bereits jetzt als veraltet und unsicher gilt.
2) "Hat der User hingegen allerdings SMS ausgewählt, so bekommt der User eine SMS auf sein Handy geschickt."
Das von Dir beschriebene Verfahren gleicht dem sogenannten mTAN-Verfahren. Über die Umsetzung dieses Verfahrens haben wir ebenfalls bereits nachgedacht. Grundsätzlich ist es sicherer, als das iTAN-Verfahren, löst aber nicht alle Probleme. So häufen sich inzwischen Meldungen über die Unsicherheit dieses Verfahrens: z.B. bei der Zeit und bei Chip.
Deshalb halte ich den Einsatz dieses Verfahrens aus heutiger Sicht ebenfalls für nicht empfehlenswert.
Eventuell hast Du noch andere Ideen hinsichtlich möglicher Neuerungen. Der Übersicht halber schlage ich vor, dass wir in folgendem Thread weiter diskutieren: http://forum.ebesucher.de/threads/28922-Deaktivierung-der-Transfer-Funktion?p=229572
Devtronic
0
08.11.2014 13:10
Es wundert mich dass mein Beitrag einfach so weg ist...
Was haltet Ihr von meinem Vorschlag ein "Treuhand"-System zu verwenden?
Die Punkte werden auf einem Dritt-Konto "eingefroren" bis beide Parteien ein OK gegeben haben.
Wie ich bereits geschrieben habe, hatte ich sowas, bis zur Ankündigung, in Entwicklung, und es steckt bereits 1 Jahr Arbeit drin.
Es wundert mich dass mein Beitrag einfach so weg ist...
Was haltet Ihr von meinem Vorschlag ein "Treuhand"-System zu verwenden?
Die Punkte werden auf einem Dritt-Konto "eingefroren" bis beide Parteien ein OK gegeben haben.
Wie ich bereits geschrieben habe, hatte ich sowas, bis zur Ankündigung, in Entwicklung, und es steckt bereits 1 Jahr Arbeit drin.
soulreafer
0
29.11.2014 18:05
Geht es hier um einen sicherheitsaspekt bei gehackten Accounts?
Warum dann nich ganz einfach jedem User die Möglichkeit bieten seine Email unwiederruflich zu speichern sodass ein möglicher hacker diese nicht ändern kann. Und bei einer anstehenden Transkation wird einfach ein Bestätigungslink verschickt welchen man nutzen muss falls die Transaktion von der richtigen Person erstellt wurde. Andernfalls kann man die Mail Ignorieren und melden.
Treuhand (middleman) finde ich schwachsinnig. Weil wenn ein Account gehackt wurde kann der Hacker auch einfach seine Transaktion und die vom fremden Account bestätigen.
Geht es hier um einen sicherheitsaspekt bei gehackten Accounts?
Warum dann nich ganz einfach jedem User die Möglichkeit bieten seine Email unwiederruflich zu speichern sodass ein möglicher hacker diese nicht ändern kann. Und bei einer anstehenden Transkation wird einfach ein Bestätigungslink verschickt welchen man nutzen muss falls die Transaktion von der richtigen Person erstellt wurde. Andernfalls kann man die Mail Ignorieren und melden.
Treuhand (middleman) finde ich schwachsinnig. Weil wenn ein Account gehackt wurde kann der Hacker auch einfach seine Transaktion und die vom fremden Account bestätigen.
djoni
+11
17.12.2014 21:05
An dieser Stelle der Hinweis, dass die neue API nun veröffentlicht wurde. Kommentare, Feedback und Kritik sind gerne gesehen.
Link zum API-Thread:
http://forum.ebesucher.de/threads/29368-eBesucher-API
An dieser Stelle der Hinweis, dass die neue API nun veröffentlicht wurde. Kommentare, Feedback und Kritik sind gerne gesehen.
Link zum API-Thread:
http://forum.ebesucher.de/threads/29368-eBesucher-API