OAuth anstatt Losepasswort?

[Snyke]

Hi,

ich wollte mal fragen ob es moeglich ist neben dem Losepasswort auch eine OAuth [1] autorisierung zu implementieren auf Klamm. Es ist mir als Seitenbetreiber immer unheimlich die Losepasswoerter der Benutzer zu kennen, und auch die Zeitlich limitierten Passwoerter sind nur eine leichte verbesserung da die Benutzer damit ziemlich in der Gegend rumgeschickt werden.

Mit OAuth ist es moeglich fuer jeden Consumer (die Klammseiten im Netz denen normalerweise das Losepasswort gegeben wird) ein geteiltes Passwort (Access Token) mit Klamm.de (dem Service Provider) zu erstellen, dass dann vom Benutzer abgesegnet wird (so nach dem Motto: ja die Seite kenne ich und sie darf auf meine Daten zugreifen), danach kann der Consumer das Passwort verwenden um Transaktionen im Namen des Benutzers auf Klamm.de auszufuehren.

Sollte der Benutzer dem Consumer (Seite) nicht mehr trauen oder einfach um uebersicht zu behalten, kann das Access Token als ungueltig erklaert werden und der Consumer hat keine Zugriffsrechte mehr auf die Daten des Benutzers auf Klamm.

Was das im Endeffekt bringt:

• Keine Passwoerter an andere Seiten anvertrauen
• Access Tokens koennen mit gewissen Rechten behaftet werden (also kontostand einsehen aber nichts daran veraendern, oder voller zugriff, oder jeder moegliche Mix)
• der Benutzer hat eine uebersicht von wo was ausgefuehrt wird, wer welche Rechte hat und kann diese auch entziehen

Keine Ahnung wie der Vorschlag unter meinen Programmierkollegen gesehen wird, aber ich denke wenn Facebook, Google, Twitter und viele mehr auf OAuth vertrauen, wieso sollte es dann nicht auch hier funktionieren?

Gruss,
Snyke

[1] http://oauth.net/

[sulospace]

Speicherst du die Losepasswörter?

[theHacker]

Zitat von Snyke

[...] wieso sollte es dann nicht auch hier funktionieren?

Weil die "Programmierer" der Loseseiten (also unsere Scriptkiddies) noch nicht mal im Stande sind, die primitive EF-API zu implementieren. Wie sollen die es dann schaffen, sowas kompliziertes richtig zu programmieren?

Ein realistischer Minus-Punkt wäre da sicher auch: Du kannst nicht von heut auf morgen die bisherige LosePW-Authentifizierung auf was anderes umstellen. Und wenn du es freiwillig machst, also beide Methoden erlaubst, so wird sich kein Scriptkiddie die Mühe machen, zusätzlichen Code zu schreiben. Wieso OAuth benutzen, wenn das LosePW doch funktioniert?

[baffi]

Dazu müssten die Anwender aber erstmal wissen was Access Tokens sind, wie die zu finden und zu ändern sind. Außerdem würde man die Rechte erst entziehen können wenn einem ein Grund auffiele, warum man der Seite nicht mehr vertraut, oder?

Dass der User für das EW-Passwort "rumgeschickt werde" verstehe ich nicht so ganz. Er kann es doch auf klamm an mehreren Stellen generieren?

[ice-breaker]

Zitat von baffi

Außerdem würde man die Rechte erst entziehen können wenn einem ein Grund auffiele, warum man der Seite nicht mehr vertraut, oder?

Man könnte auf diesem Wege aber auch einfach nur eine Losetransaktion authorisieren.

Vorteil für Klamm: mehr PIs

[DaxDony]

Zitat von theHacker

Weil die "Programmierer" der Loseseiten (also unsere Scriptkiddies) noch nicht mal im Stande sind, die primitive EF-API zu implementieren. Wie sollen die es dann schaffen, sowas kompliziertes richtig zu programmieren?

Warum gibst du - der heilige Code-Guru - nicht mal einen Ruck, und hilfst den geistig verarmten Scriptkiddies?

Spaß beiseite:
Die Idee ist sicherlich ganz nett, jedoch denke ich nicht, dass eine Umstellung sinnvoll wäre, denn immerhin müsste man sämtliche Systeme die mit dem aktuellen Authentifizierungsystem arbeiten umstellen - und das wäre eine gewaltige Arbeit.
Außerdem bin ich der Meinung, dass das aktuelle System hinreichend Sicher ist, wenn man wenige "Sicherheit-Regeln" befolgt.

[Snyke]

Zitat von sulospace

Speicherst du die Losepasswörter?

Nein, absolut nicht!
Aber es giebt garantiert Leute (Webmaster) die meinen sie seien super schlau und machen das. Ich denke es sollte alles mit minimum Trust gehen.

Zitat von theHacker

Weil die "Programmierer" der Loseseiten (also unsere Scriptkiddies) noch nicht mal im Stande sind, die primitive EF-API zu implementieren. Wie sollen die es dann schaffen, sowas kompliziertes richtig zu programmieren?

Ein realistischer Minus-Punkt wäre da sicher auch: Du kannst nicht von heut auf morgen die bisherige LosePW-Authentifizierung auf was anderes umstellen. Und wenn du es freiwillig machst, also beide Methoden erlaubst, so wird sich kein Scriptkiddie die Mühe machen, zusätzlichen Code zu schreiben. Wieso OAuth benutzen, wenn das LosePW doch funktioniert?

Stimmt, aber was passiert wenn man langsam den Preis fuer EF Anfragen mit Losepasswort hochdreht (freiabfragen und gekaufte abfragen) um die Leute zu "ermutigen" auf den besseren Standard zu wechseln?

Zitat von baffi

Dazu müssten die Anwender aber erstmal wissen was Access Tokens sind, wie die zu finden und zu ändern sind. Außerdem würde man die Rechte erst entziehen können wenn einem ein Grund auffiele, warum man der Seite nicht mehr vertraut, oder?

Der vorteil eines ausgekluegelten Standards: andere machen sich dieselben gedanken
Nein im Ernst es is soweit extrem einfach als dass man auf die Consumer Seite geht, dann irgendwas machen will (Lose Einzahlen z.B.), der Consumer merkt dass er fuer dich gar kein Access Token hat, und du als Benutzer wirst zu Klamm.de geleitet. Da wirst du gefragt ob du die Aktion genehmigst (Ueberweisung auf das Betreiberkonto im Beispiel) und ob du diese Genehmigung fuer diese Seite in Zukunft speichern willst.

Danach wirst du wieder an die Seite zurueckgeleitet, und falls du zugestimmt hast bekommt der Consumer im Hintergrund sein Access Token mit dem er dann die Aktion ausfuehrt.

Wenn du die Berechtigung gespeichert hast wirst du nie wieder nach passwort oder anderem gefragt.

Wie bereits bemerkt kann man auch einfach eine einmalige Berechtigung erteilen und dann wuerde man jedes Mal zu klamm.de geschickt.

Alles einfacher als Passwortabfrage, zu klamm.de rennen, einmaliges Passwort erstellen, kopieren, wieder zurueck zur Seite, einfuegen, abschicken.

Das meiste ist fuer den Endbenutzer vollkommen transparent

HTH
Snyke

[ScarFace01]

Naja aber den Token stopen/ändern oder blockieren kann oder macht man ja eigentlich auch erst wenns zu spät ist oder? Genau wie bei dem System das es jetzt auch gibt.

Man kann es so sicher machen wie man will, am Ende ist diese Sicherheit ja doch nur so sicher, wie man selber damit umgeht!

Nachtrag:
Und das mit den EF Anfragen Gebühren erhöhen, das hatten wir doch vor garnicht all zu langer Zeit erst! Was ein Geschreie!

[Snyke]

Zitat von ScarFace01

Naja aber den Token stopen/ändern oder blockieren kann oder macht man ja eigentlich auch erst wenns zu spät ist oder? Genau wie bei dem System das es jetzt auch gibt.

Man kann es so sicher machen wie man will, am Ende ist diese Sicherheit ja doch nur so sicher, wie man selber damit umgeht!

Nachtrag:
Und das mit den EF Anfragen Gebühren erhöhen, das hatten wir doch vor garnicht all zu langer Zeit erst! Was ein Geschreie!

Naja man koennte auch den OAuth usern einfach nur die haelfte berechnen oder so ^^

Es geht ja weniger darum das momentan laufende System zu aendern (Programmer Rule #1: never change a running system) sondern eine alternative zu schaffen.

Selbst wenn man die Berechtigung nicht speichert (also nur one-time passwords mit authorization) und jedesmal zu klamm.de geschickt wird und da einmal klicken muss um zu bestaetigen, ist es immer noch angenehmer als der jetzige One-Time password kram.

[ice-breaker]

Zitat von DaxDony

Spaß beiseite:
Die Idee ist sicherlich ganz nett, jedoch denke ich nicht, dass eine Umstellung sinnvoll wäre, denn immerhin müsste man sämtliche Systeme die mit dem aktuellen Authentifizierungsystem arbeiten umstellen - und das wäre eine gewaltige Arbeit.

Man muss das aktuelle ja noch nicht ersetzen, man könnte es zusätzlich anbieten.
Der EF kostet ja nur, damit Lukas seine Kosten dafür decken kann, mit OAuth würde man direkt zu Klamm weitergeleitet und müsste die Aktion genehmigen, was Klamm wieder PIs beschert und somit Geld, also könnte man den neuen Service kostenlos anbieten, womit ganz schnell alle auf OAuth umsteigen würden, und der EF würde langsam aussterben.

Zitat von DaxDony

Außerdem bin ich der Meinung, dass das aktuelle System hinreichend Sicher ist, wenn man wenige "Sicherheit-Regeln" befolgt.

Das aktuelle System ist kein Stück sicher.
Ich sage auf der Seite, dass ich 1mio Lose einzahlen möchte und gebe mein Einmalpasswort an, das System bucht aber das doppelte ab, wunderbar, bisher war der Anbieter seriös, ab heute nicht mehr. Und du kannst NICHTS dagegen tun.
Mit OAuth müsstest du auf Klamm erst bestätigen, dass der EF XYZ 1mio einziehen darf.

Zitat von Snyke

Wenn du die Berechtigung gespeichert hast wirst du nie wieder nach passwort oder anderem gefragt.

Ich würde wirklich so weit gehen und sagen, dass es keine dauerhafte Genehmigung geben sollte.

Zitat von Snyke

Alles einfacher als Passwortabfrage, zu klamm.de rennen, einmaliges Passwort erstellen, kopieren, wieder zurueck zur Seite, einfuegen, abschicken.

wenn irgendwer hier das liest und mit einem Grafikprogramm umgehen kann, könnte er ja mal ein paar Bilder als Demo erstellen, wie das funktioniert.
Twitter ist da denke ich eine gute Vorlage.

Zitat von ScarFace01

Man kann es so sicher machen wie man will, am Ende ist diese Sicherheit ja doch nur so sicher, wie man selber damit umgeht!

das man eine Transaktion erst genehmigen muss, ist absolut sicher. Wenn man zustimmt 10Mrd abzubuchen, statt den gewollten 100mio ist man selbst Schuld. Tut mir Leid, aber das ist dann wirklich zu dumm zum zum.



Würde es ein kostenloses FWX und VMS Plugin geben, wäre die Verbreitung sicherlich auch gleich hoch.
Damit wird das vermieden, was theHacker anspricht, denn ich teile seine Meinung.
Wobei es für Twitter irgendwie auch jeder Trottel hinbekommt.

[theHacker]

Zitat von ice-breaker

das man eine Transaktion erst genehmigen muss, ist absolut sicher. Wenn man zustimmt 10Mrd abzubuchen, statt den gewollten 100mio ist man selbst Schuld. Tut mir Leid, aber das ist dann wirklich zu dumm zum zum.

Ich krieg sehr häufig PNs von Leuten, die mich fragen, ob ich falsch überwiesene Lose zurückbuchen kann.
Man beachte jetzt:

• Ich bin nur ein Moderator von vielen, d.h. anderen Mods gehts vermutlich genauso.
• Ich bin "nur" Moderator und nicht mal Admin, d.h. möchte nicht wissen, wie viele Anfragen bei den Admins eingehen.
• Zusätzlich gibts noch KzA und die service-Mailadresse, wo sowas landen könnte
• ...und: jede Losetransaktion muss jetzt schon bestätigt werden.

Klar, was ich sagen will?

[DaxDony]

Zitat von ice-breaker

Das aktuelle System ist kein Stück sicher.
Ich sage auf der Seite, dass ich 1mio Lose einzahlen möchte und gebe mein Einmalpasswort an, das System bucht aber das doppelte ab, wunderbar, bisher war der Anbieter seriös, ab heute nicht mehr. Und du kannst NICHTS dagegen tun.
Mit OAuth müsstest du auf Klamm erst bestätigen, dass der EF XYZ 1mio einziehen darf.

Sind den vergleichbare Fälle bekannt?
Ich Zweifelsfall kann man immer etwas tun: Maximal x Millionen Klammlose auf dem Konto, den Rest in den Tresor, dann kann auch maximal die Summe x abgebucht werden.

Ich behaupte ja nicht, dass das System perfekt ist. Aber wenn jemand betrügen will, dann wird er dies auch irgendwie schaffen, unabhängig vom Transfer-System.
Hingegen wird ein User, der sich vor Betrügern ernsthaft schützen möchte, dies auch auf Umwegen schaffen, wenn man es schafft Threads wie "2% pro Tag" weg zu klicken und versucht auf ein paar wenigen Seiten zu zocken.

Zitat von ice-breaker

Man muss das aktuelle ja noch nicht ersetzen, man könnte es zusätzlich anbieten.

Das wäre natürlich etwas anderes. Jedoch müsste man die Vor- und Nachteile genau abwiegen, was sicherlich auch nicht so leicht ist.
Ein Nachteil wäre der hohe Arbeitsaufwand.

[Robbi5]

Zitat von DaxDony

Ein Nachteil wäre der hohe Arbeitsaufwand.

Das würde sich wahrscheinlich sehr schnell lösen lassen. Auf GitHub findet man ja für Twitter einige fertige OAuth-Libs, die man ja etwas auf die Klamm-OAuth-Lösung umbiegen kann. Und wenns erst ein paar fertige Plugins für die diversen Loseseitenscripte gibt, werden sicherlich einige umsteigen - allein schon wegen dem zusätzlichem Sicherheitsgefühl für die User.

Das Problem ist hier wie bei meinem damaligen OpenID-Vorschlag, Lukas müsste sich dazu einfach mal äußern. (Am besten zu beiden, OAuth+OpenID lässt sich ja wunderbar kombinieren)

Klamm als OAuth&OpenID-Provider wäre einfach super

OT: Wir setzen unsere Loseseite Losecatcher.de schon als OAuth-Provider ein, um diesen ganzen Login&Datenkram für externe Tools einfacher zu machen - es funktioniert wunderbar. Somit sehe ich zumindest keinen technischen Grund, warum Klamm es nicht umsetzen sollte.

Edit: Gleichzeitig könnte Klamm dann mit OAuth auf eine sauberere API umsteigen, damit man nicht mehr dieses Trennzeichen-Gefrickel hat.

[D_Blade]

Naja, ich denke es wäre nicht falsch auf sowas umzustellen.

Viele neue Seiten, vorrangig Browsergames, benutzen bereits OAuth.

[Kesselchen]

Zitat von ScarFace01

Nachtrag:
Und das mit den EF Anfragen Gebühren erhöhen, das hatten wir doch vor garnicht all zu langer Zeit erst! Was ein Geschreie!

Wo wie was wurde da erhöht?

LG