[Muratti] Passwort Reset erster Release

Mi Aug 24 20:58:32 CEST 2016

On 2016-08-24 11:41, Jogi Hofmüller - mur.at wrote:
> es wäre wirklich nett, wenn zumindest die eine/der andere das Teil
> nochmals ausprobieren würde, und hier kurz berichtet, wie sie/er das
> findet.

da ich in meiner mailbox keine link auf irgendwelche quellen gefunden 
habe, die zum code review zur verfügung stehen würden, muss ich mich 
hier eher allgemein fassen.

ich versteh wirklich gut, warum ein derartiges tool prinzipiell sinn 
macht. passworte zu ändern/zurückzusetzten und nervigen bürokratischen 
kram zu erledigen, ist ja wirklich das letzte, was man den kollegen im 
mur.at-arbeitsteam wünscht. es macht also schon sinn, genau solche 
ablaufe zu automatisieren bzw. computer hier einmal in jener weise zu 
nutzen, wie sie ursprünglich gedacht waren: uns last abzunehmen, statt 
und nur zusätzliche arbeit zu schaffen und das leben zu erschweren.

was dem allerdings entgegensteht, ist die tatsache, dass es sich das im 
konkreten fall -- so sehr man sich das auch wünschen würde -- m.e. kaum 
befriedigend sauber und vorbildlich "sicher" lösen lässt!

die hier gewählte variante der identitätsüberprüfung über zwei 
unabhängige kommunikationskanäle bzw. authentifizierungsfaktoren war vor 
einiger zeit noch als großer fortschritt anzusehen. mittlerweile wird 
sie aber, nachdem bspw. im e_banking-umfeld immer wieder erfolgreiche 
angriffe und umgehungsvarianten des mTAN austauschs zu beobachten waren, 
ein bisschen kritischer gesehen und von einschägigen stellen (bspw. dem 
BSI) ganz ausdrücklich nicht mehr empfohlen:

https://www.bsi-fuer-buerger.de/BSIFB/DE/DigitaleGesellschaft/OnlineBanking/SoFunktioniertDasOnlineBanking/Sicherheit/PIN-TAN-Schutzverfahren.html?cms_pos=3

ähnlich unnachgiebig positioniert sich das BSI in der frage der 
passwortsicherheit. auch dort verlangt es weiterhin, dass entsprechende 
eingriffe ausschließlich vom administrationspersonal durchgeführt 
werden, obwohl das nicht nur bei mur.at mit beträchtlichem aufwand 
verbunden ist:

"Die meisten Unternehmen sperren den
Zugang zu internen Systemen nach einer
begrenzten Zahl von Login-Fehlversuchen.
Oft liegt dieser Wert – in Übereinstimmung
mit den Empfehlungen der Maßnahmenkataloge
des BSI zum IT-Grundschutz (M 2.11
„Regelung des Passwortgebrauchs“ [BSI_08])
– bei drei; eine Aufhebung der Sperrung
ist nur mit AdministratorBerechtigung
möglich.
Die Konsequenz ist bekannt: Nach dem
Ende der Urlaubszeit und in den Tagen
nach je dem erzwungenen Passwortwechsel
steigt die Zahl der Passwortrücksetzungen
erheblich. Sie summieren sich nach
einschlägigen Untersuchungen auf 20-50%
aller Hotline-Anrufe[Smith_02].
Der Aufwand für eine Passwortrücksetzung
ist erheblich: Nach einer Studie von
Forrester Research aus dem Jahr 1999
(„A digital Certificate Roadmap“)
liegen die Gesamtkosten bei 80 US$ je Vorgang."

(https://www.secorvo.de/publikationen/passwortsicherheit-fox-schaefer-2009.pdf)

aber gut -- mTAN ist nicht unmittlelbar mit dem hier gewählten procedere 
zu vergleichen. banken bzw. gedüberweisungen, bilden für angreifer ein 
ganz andere attraktivität als unsere mickrigen server. dort geht's im 
übrigen ja auch wirklich um die frage, wer die kosten im schadensfall zu 
tragen hat? -- deshalb eben auch diese ganz klaren und sehr vorsichtigen 
empfehlungen.

aber ganz so unbedeutend, wie bspw. bei irgendeinem lustigen web-forum, 
wo es mich natürlich auch nicht weiter bekümmert, wenn im ernstfall 
wieder eine menge e_mail-anschriften und login-daten in fremde hände 
gelangen, erscheinen mir die mur.at-authentifizierungsangaben bzw. der 
zugriff auf unsere rechner dann auch wieder nicht.

ich würde also gefühlsmäßig am ehesten vorschlagen, die ganze sache gar 
nicht so sehr ausschließlich nur unter dem gesichtspunkt des realen 
bedrohungpotentials zu sehen, sondern es vielmehr als ganz praktisches 
beispiel im umgang bzw. vorbildlicher gestaltung gegenwärtiger fragen 
der "netzkultur" verstehen.

macht man also einfach nur nach, was ja auch die großen banken 
praktizieren, oder aber zeigt man sich übervorsichtig und kritisch und 
verzichtet dafür auf eine mögliche erleichterung im alltag? man könnte 
es im ersteren fall ja auch als zustimmung zu diesen anderen 
alltäglichen anwendungsfällen deuten, in der wir uns unserer rolle als 
multiplikatoren bzw. kritischer instanz bewusst sein sollten.

ich würde in diesem zusammenhang auch noch gerne zwei-drei weitere 
wichtige punkte anreißen, die einen recht nachdenklich stimmen können:

seit vielen jahren gilt es als gängige praxis, zumindest zwei dinge in 
den passwort policies einzufordern:

1.) ein regelmäßiges ändern der passwörter
2.) eine mindestmaß an formaler komplexität (länge, zeichenumfang etc.)
und sicherheit gegenüber einfachen dictionary attacks.

beide dinge wirken durchaus plausibel und sinnvoll, auch wenn man über 
ihren praktischen nutzen gewöhnlich nur aus dem bauch heraus zu urteilen 
pflegt.

in den letzten jahren wourden aber vermehrt studien durchgeführt, die 
dieser frage auch mit objektiveren methoden der empirischen 
sozialforschung nachgegangen sind. die ergebnisse zeigen eine 
erschreckende abweichung von unserem bisherigen technokratischen 
verständnis dieser problematik!

in beiden fällen scheint es so zu sein, als würde sich die 
automatisierte kontrolle in wahrheit spürbar kontroproduktiv auswirken:

http://arstechnica.com/security/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/

https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes

http://www.eurecom.fr/en/publication/2910/download/rs-publi-2910_1.pdf

http://link.springer.com/chapter/10.1007/978-3-319-41932-9_26

eine wirklich gute antwort darauf kenne ich auch nicht. es relativiert 
nur einige jener falsche gewissheiten, die ich dazu bisher auch geteilt 
habe.

(im übrigen finde ich es ohnehin immer wieder sehr spannend, wenn 
technik tatsächlichen an menschlichem maß gemessen und neu bewertet wird ;))

nicht zuletzt deshalb ist es mir [weiterhin] ein ziemliches anliegen, 
dass die tatsächliche server-sicherheit bei mur.at nicht so sehr nur mit 
diesen ganz oberflächlichen und höchst löchrigen mechanismen in 
verbindung gebracht wird, sondern vor allen dingen auch dahinter -- der 
art und weise, wie einzelne anwendungen auf den servern voneinander 
isoliert werden, um möglichen schaden wenigstens einzugrenzen!!!

deshalb hätte es mich auch sehr interessiert, wie diese tool tatsächlich 
umgesetzt ist -- es ist schließlich ein wunderbares beispiel für genau 
diese problematik! ich persönlich hätte nämlich ziemliches bauchweh, 
wenn ich derart priviligierte abläufe im web-umfeld abwickeln sollte. am 
ehesten würde ich es heute wohl mit einer art micro-service zu lösen 
versuchen, wo nur die oberfläche übers web realistiert wird, der 
eigentlich sicherheitsrelevante teil aber ausschließlich via RPC 
angesprochen wird, und in einem viel überschaubarerem unabhängigen 
prozess/kontext läuft.

wie gesagt: die beweggründe hinter diesem werkzeug kann ich nur zu gut 
nachvollziehen. es spricht also gewiss einiges dafür, hier einfach ein 
auge zuzudrücken und etwaige bedenken in den hintergrund zu rücken.
ganz wohl ist mir aber bei der sache trotzdem nicht, weil sie einfach 
dem besseren wissen bzw. unseren hoch gesteckten gemeinsamen ansprüchen 
doch ein wenig widerspricht...

aber eigentlich gäbe es ja vermutlich auch andere dinge zu diskutieren, 
die für mur.at von größerer wichtigkeit sein könnten.

liebe grüße
martin