When Twitter was recently hacked, I was among those who got an email saying I was affected. So I changed my password.
But here’s what I’ve noticed: changing my password does not cause any of the Twitter clients on my iPhone to ask me again for authentication. They just keep working normally. […]
I understand that OAuth is a security win in some ways. But implementors should, I think, be mindful of what normal people expect — which is that changing your password locks out every app until you re-authenticate.
Das ist ein schon länger bekanntes Problem, das Twitter lösen sollte. Die Tatsache, dass Twitter das nicht nach dem letzten Hack geändert hat, deutet darauf hin, dass sich daran auf absehbare Zeit nichts ändern wird. (Man könnte fast sagen, das sei wenig überraschend, da Twitter nur noch ein partielles Interesse am eigenen Ökosystem hat und deswegen dortige Sicherheitsprobleme keine hohe Priorität bekommen.)
Vielleicht bin ich etwas befangen, als jemand der schon mal eine eigene OAuth Server-Implementierung geschrieben hat, aber: Das ist genau was man will. Es hat ja in der Vergangenheit immer genervt, wenn man sein Passwort geändert hat und dann alle Clients neu zu autorisieren waren. Insbesondere sind ja bei einer Kompromittierung des Passwortes die ausgegebenen Auth-Tokens nicht kompromittiert. Der Angreifer, kann nun bestehende Tokens löschen (was komplett in Ordnung geht) oder sich selber welche ausstellen (was kritisch ist).
Meiner Meinung sollte bei dem forciertem Passwortwechsel darauf hingewiesen werden, dass sich ein Angreifer neue Tokens hat ausstellen können. In diesem Fall sollte die Möglichkeit zum Löschen aller Tokens aber auch die Möglichkeit der Einsichtnahme geordnet nach Ausstellungsdatum angeboten werden. Twitter zeigte beim letzten Zwangspasswortwechsel die Liste der autorisierten Dritt-Apps. Ich empfinde das als hinreichend. Jemand mit 200 autorisierten Dritt-Apps hat vielleicht Gründe für sein Handeln.
Bei korrekten Implementierung verfallen Auth-Tokens sowieso nach einer bestimmten Zeit (jeder der eine Zeit lang nicht die Facebook-App geöffnet hat, hat schon einmal unerwartet den Login-Bildschirm zu Gesicht bekommen → sein in der App hinterlegtes Auth-Token lief ab), so dass auch vom Angreifer kurzfristig ausgestellte Auth-Tokens mit der Zeit ungültig werden und er nach dem Zwangspasswortwechsel nicht die Möglichkeit hat, sich selbst neue auszustellen. Ein Passwortwechsel via Auth-Token oder aus Ausstellen neuer Auth-Tokens mit einem bestehenden Auth-Token geht üblicherweise nicht (für letzteres sieht OAuth2 so genannte Refresh-Tokens vor, die sind meistens aber auch zeitlich begrenzt, je nach Implementierung).
Ja. Wobei es bei einem Massenhack nicht schaden kann, die Tokens der betroffenen Accounts zu löschen. Nicht zuletzt weil die meisten User nicht verstehen dürften, wo die Gefahren liegen.
Es schadet leider doch. Denn wenn man wieder zurückkehrt zu dem alten Status Quo: Das ein Hack immer gleich unkomfortabel für die User wird, werden sich Entwickler nicht mehr für den Mehraufwand entscheiden, die ein Verfahren bedeutet, welches besser als User/Password-Credentials ist – und es ist ein deutlicher Mehraufwand. Man entscheidet sich für Tokens, genau aus dem Grund, dass User/Password-Credentials bei Drittanbieter oder Geräten in Kundenhand nicht sicher aufzubewahren sind.
Das Argument: Der User versteht das nicht, darf nicht dafür herhalten das man bei der UX/UI spart. Wie bereits gesagt: In dem Fall hier würde ja sowohl der Hinweis, als auch auch vielleicht schon eine Vorauswahl (alle Clients) für einen „Auswahl löschen“ Button genügen. Ich wehre mich nur dagegen, dass man davon ausgeht, dass alle User „dumm“ sind und man ihnen deshalb nicht mehr die Wahl lässt.
Das sehe ich anders. Der API-Provider kann Verifizierungen via Passwort unterbinden und OAuth vorschreiben. Zusätzlich, wenn er das nicht macht, kann er auch alle Sessions die über das alte Passwort gestartet worden, beenden. Also alle Verifizierungen ernaut abfragen, unabhängig ob OAuth-Token oder anders.
Oder übersehe ich da etwas?
Das ist dann aber allenfalls eine Zweitdiskussion und hat mit dem Ursprungszitat nur bedingt etwas zu tun. Wenn ich mein Passwort ändere – was man ja eigentlich regelmäßig tun sollte – möchte ich eigentlich nicht bei allen OAuth-autentifizierten Drittservices plötzlich ausgesperrt und zur Neuanmeldung gezwungen sein. Da halte ich wie vorgeschlagen eine andere Lösung via begleitenden Vorschlagssystemen („Ihre aktuellen Autorisierungen“, „diese Dienste sind länger als … aktiv“) für die bessere. Letztlich kann Sicherheit doch nur ein Angebot sein und sollte dem User nicht als Ärgernis übergeholfen werden. Ich bin auch der Meinung, dass es fördernswert ist, sich aktiv mit dem Thema auseinandersetzen zu müssen, statt vom System gegängelt zu werden. Denn da schalten viele Nutzer ohnehin auf Durchzug.
Hm. Ich bin nicht sicher, ob das sinnvoll ist, wenn man das Passwort aus Sicherheitsgründen ändert (warum sonst sollte man?) und das Angebot aber zu 90% über mit OAuth verifizierten Drittanbieterapps nutzt.