Das SCC (3)

Dezember 16th, 2008 § 9 comments

In den Kommentaren zu diesem Post hat Klaus Mebus -- Sicherheitschef des SCC -- den folgenden Text über die Probleme des SCC und die Umstellung von NIS auf LDAP hinterlassen, der hier nach Rücksprache mit ihm veröffentlicht wird:

Die Umstellung war für definitiv für März geplant. Die Voraussetzungen sollten u.a. mit der seit Juni 2008 laufenden und immer noch nicht abgeschlossenen Passwortsynchronisierung geschaffen werden. Wenn man ein Authentifizierungssystem umstellt, dann geht das in einer gewachsenen völlig heterogenen Umgebung mit verteilten Verantwortlichkeiten und einer möglichst geringen Beeinträchtigung aller Nutzer (wir haben über 7500 Accounts!) nicht auf die Schnelle, ohne das ggf. wichtige Prozesse beeinträchtigt werden. Das Problem war im übrigen nicht in erster Linie die Verwendung eines unsicheren Verschlüsselungsalgorithmus, sondern die Zugänglichkeit der NIS-Datenbank und der damit verbundenen Möglichkeit des Crackens der Passwort-Hashes. Hier machen es einem viele Nutzer sehr leicht, indem sie Passwörter verwenden, die die Bezeichnung kaum verdient haben. Hier hilft nicht mal die stärkste Verschlüsselung, wenn das bloße Raten ausreicht. Mir wäre es auch lieber, dass alle bekannten Misstände auf einen Schlag Geschichte wären, aber im SCC laufen eben noch viele andere Prozesse, die vielleicht nicht jeder auf den ersten Blick so sieht, und damit meine ich nicht nur die Standardaufgaben, sondern Projekte wie die gerade durchgeführte Storageumstellung. Umstellungen mit weitreichenden Folgen sollten gut geplant und ausreichend getestet werden, sonst kann es bei einer schnellen Implementierung auch wieder zu Fehlern kommen, die einem später auf die Füße fallen. Im Lehrbuch ist das immer einleuchtend und wenn meine seine(n) Home-PC oder Mac bearbeitet, geht das auch immer fix, aber hier geht es um wie gesagt um die komplette Infrastruktur eine Universität.
Schon mal versucht ein Passwortsystem für über 7500 accounts von Crypt auf MD5 (das wäre ja wohl die einzige Alternative im NIS) umzustellen? Funktioniert das überhaupt auf allen Systemen? Wie soll das Passwortsystem in der Übergangszeit crypt und MD5-Hashes gleichzeitig verarbeiten? Ist das überhaupt möglich? Sollten wir allen Nutzer das Passwort wegnehmen, alle accounts auf MD5 umstellen und dann jeder sich ein neues beim Benutzerservice abholen? Was machen die, die gerade nicht in Weimar sind?.... So easy ist das eben nicht.

Jedenfalls wurde die Umstellung nun angegangen und das bei vielen nicht ohne Schmerzen, die hätten vielleicht vermieden werden können, aber wir waren nun mal im Zugzwang und wollten und konnten nicht mehr warten. Ich hoffe jeder hat nun auch das Verständnis dafür, wenn eben mal temporär was nicht läuft, aber so ist das eben bei unplanmäßigen Änderungen und selbst bei einer guten Planung und Test kann es immer Fälle geben, bei denen Abhängigkeiten auftauchen, die man nicht voraussehen konnte.

In einer E-Mail fügte er an:

Bei neuen auf LDAP basierenden System werden wir natürlich bemüht sein einen Hash-Algorithmus zu verwenden, der die größt mögliche Sicherheit verspricht (SHA oder RIPEMD160). SHA-1 ist da zwar Standard bei LDAP, Bruce Schneier hat aber bereits 2005 auf Schwächen hingewiesen. Wenn es möglich ist werden wir also SHA-2 einsetzen und zusätzlich in jedem Fall dafür sorgen, dass man an die nicht mehr so einfach rankommt.

Tagged , , , ,

§ 9 Responses to Das SCC (3)"

  • MMMMmmmh sagt:

    Ich habe zwar keine Ahnung vom Coderkrams aber als jemand der bereits an eine Uni Mitarbeiter war weis ich das die Mühlen da gerne mal bedeutend langsamer mahlen als in jedem anderen Job den ich hatte. (Ich zitiere in dem Zusammenhang mal einen meiner damaligen Mitarbeiter "Wenn du hier nen Jahr gearbeitet hast bist du versaut fürs leben") Es gibt immer noch jemanden der etwas Diskutieren oder nicht haben will und vorankommen tut man alle par Wochen mal, bei aufgaben die man normalerweise in einigen Tagen (mit gutem Ergebnis) erledigt haben könnte. Besonders bei externen Terminsachen wars immer lustig, wenn die Herren dann teilweise drei tage vor Torschluss gemerkt haben das man vielleicht wirklich mal was anfangen sollte anstatt nur drüber zu reden....

    Hier scheint es ja ganz ähnlich zu sein, jeder macht sich über die Homepage lustig weil sie (abseits der Pinnwände) ein unglaubliches kahos ist - aber eine neue gibt's trotzdem nicht weil (soweit ich es gehört habe) sich einige nicht auf das Script der neuen Homepage einigen können... und seit Jahren unbesetzte Professuren, die Studenten? Egal, die Kandidaten passen nicht in mein Ego! Und wie die anderen Profs in meiner Fakultät (oder gar der anderen) arbeiten passt mir auch nicht! Ich, Ich, Ich, Ich, ich... BIN WICHTIG!

    Ein kleiner tritt in den Arsch mag unangenehm sein (wie das mit einem tritt in den Arsch nunmal ist) aber da es hier doch um unser aller Daten Sicherheit ging sehe ich dem nur positives inne... die Sparkasse kann auch nicht ewig an nem unsicherem System festhalten weil sie viele Kunden hat und es aufwändig wäre das asp umzustellen...

    Nun, wie gesagt, ich habe keine Ahnung vom Coderkrams, aber ich habe lieber sichere Daten mit Kinderkrankheiten als Daten die jedem der aktives Interesse hat zugänglich sind. Das ist von mir zwar nur Prinzipiendenken, aber ich bin sicher es gibt auch einige die wirklich sensibles zeug auf den Servern liegen haben.

  • mh sagt:

    hi MMMMmmmh,

    wie bereits mehrfach erwähnt sind die Nutzer selbst ihres Schicksals Schmied und waren hier auch Teil des Problems. Die Beschränkung auf die ersten 8 Zeichen bei crypt ist evtl. nicht ausreichend kommentiert worden (daher das schwache siemens-Passwort), aber wer sich wirklich an die Regeln für gute Passwörter hält, hat auch mit crypt nichts zu befürchten, denn ein gutes Passwort mit 8 Zeichen hat etwa 722 Billionen gleichgesinnte, wo selbst die Geschwindigkeit von crypt mit 80.000 Passwörtern pro Sekunde rein rechnerisch dazu führt, dass man 280 Jahre benötigt, um den kompletten Raum zu durchsuchen. Da ist selbst um Faktor 100 beschleunigte Berechnung keine ernste Bedrohung wenn man mehrmals im Jahr sein Passwort ändert.
    Also wer hier immer nur rumjammert, dass seine Daten gefälligst sicher sein sollen, der hat zwar erstmal prinzipiell Recht - sollte aber erstmal vor der eigenen Tür kehren.
    Also die direkte Frage an dich:
    Wie oft rufst du z.B. eMails über unverschlüsselte Protokolle ab? Wie gut ist dein Passwort? Wo verwendest du es denn noch überall? Wie oft änderst du es? Was speicherst du so alles auf einem USB Stick den du mit dir rumträgst?

    Man muss sagen: ja - NIS und crypt sind sch****e, aber wenn ich mir das Nutzerprofil der BUW so anschaue, dann befindet sich das Problem ganz besonders oft zwischen Tastatur und Stuhl! Das wird in dieser Diskussion leider ständig unterschlagen. Also wenn ihr sichere Daten wollt, dann seid auch selbst konsequent...

  • MMMMmmmmmmh! sagt:

    Ich habe keine Ahnung wie viele e-Malis ich auf welche Art und weise verschicke und ich mache mir auch keine Gedanken darüber... genau wie über die Vielzahl und die änderungsrate von Passwörtern.
    Genau da liegt allerdings ein wichtiger Denkfehler... der normale Mensch weis nicht bescheid über diese Dinge, darum gibts ja Jobs für die Nerds die sich um diese Dinge kümmern.

    Ich fasse mich gerade sehr kurz (glaube ich) da ich zutun habe.

    Die Sparkasse zum Beispiel vergibt deswegen eine *nachzähl* 10-15 stellige Alphanumerische Benutzerkennung und verlangt ein ähnliches Passwort (mindestens 5 Stellen und Numerisch)... keine einfachen Eigenkreationen möglich, man nimmt dem Nutzer der sich hierüber keine Gedanken macht, weil er keine wirkliche Ahnung hat, die Entscheidung ab und drückt ihm ein Komplizierteres System auf... und selbst das noch mit dem vermerkt, "Vorsicht unsicher" - Nehmt doch lieber eine Chipkarte mit Kartenleser fürs Onlinebanking.

    Das macht am ende den unterschied zwischen dem bezahlten Sicherheitsexperten und dem zahlenden (bzw. einkommen verursachendem) User aus. Wenn ein Designer schlecht Designed oder ein Fliesenleger schief die Fliesenverlegt ist das auch dessen schuld, und nicht die des Kunden der sich zuvor nicht expertenwissend über den Berufsstamm und seine möglichen Tücken angeeignet hat.

    Wir können nicht alle alles überblicken, der normale (in diesem fall Studentische) Nutzer kommt einfach nicht auf die Idee sich bei 1000 Seiten die er besucht 500 Passwörter zu merken und diese dann noch möglichst kompliziert zu gestalten und alle 3 Monate zu ändern. Der ist einfach nur foh etwas leichtes im Kopf zu haben das überall funktioniert... und schubs liegen auch die wichtigen Daten offen...

    Das ist das Weltbild mit dem der Sicherheitsexperte Arbeiten muss... da hilft keine Propgerganda gegen... nur ein anpassen des Systems, wenn es sein muss mit nem tritt in den Arsch von zwei kleinen Hackern die vielleicht etwas über die Stränge geschlagen haben.

  • max sagt:

    Kann vielleicht mal wer mein Kommentar von grade eben im Pommes post hierherüber bewegen? Gar nicht gesehen, dass das hier nochmal explizit hervorgehoben wurde :)

  • max sagt:

    achso, @mh:
    Ein 10000 Euro Teil steht in der Uni Kiel oder Bochum, das probiert dir wirklich alle DES schlüssel durch...in 6.4 Tagen.

  • mt sagt:

    @max: ungesalzene DES hashes ja, gesalzene nein. du musst mindestens (DES(salt,DES(password)) rechnen. Also bräuchtest du mindestens 12.8 Tage. Wenn du alle Passwörter haben möchtest, dann musst du obige Operation für jeden Salt ausführen, hättest also 4096*12.8 Tage das sind dann immer noch theorethisch 150Jahre. Wobei wenn man davon ausgeht, das die hälfte der Versuche genügt sind es nur 75Jahre für alle Nutzer der BUW.

  • max sagt:

    @mt: Ich versteh deine Argumentation grade nicht, ich bilde mir ein, crypt-Salze funktionieren anders. Aber egal, was sind 12.8 Tage schon. Und was interessieren mich alle Passwoerter, wenn ich die Superuser Passwoerter kriegen kann?
    Uebrigends: das Teil kann man auch mieten.

  • mt sagt:

    @max: Das stimmt schon, ein gezielter Angriff auf ein Passwort ist schon möglich, allerdings hoffe ich dass die Admins ssh-keys mit Passphrase nutzen und sparsam mit sudo und su umgehen :)

  • mh sagt:

    @max: es geht nich um schlüssel sondern um hashes.
    aber ja, ich habe hashkollisionen nicht berücksichtigt.
    die kiste kostet 10k dollar, nicht euro.
    die 6 tage sind schon die durchschnittszeit, nicht für den gesamten raum.
    du musst die 6 tage außerdem mit 25 multiplizieren, da crypt bei der Hash-Berechnung 25mal DES-verschlüsselt, und dabei würzt. --> 150 tage durchschnitt.
    nein, die superuser sind nicht im NIS, warens auch nie und nutzen natürlich keine crypt-hashes.
    sudo wird überhaupt nicht eingesetzt.
    demnächst werden die hashes SSHA und nicht zugänglich sein.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

What's this?

You are currently reading Das SCC (3) at maschinenraum.

meta