Passwort Management System - zu "dünn"?

[Kölner]

Hallo werte Mitleser und Ratgeber!

Was ist eure Meinnung zu Folgendem:

1. Projektbezeichnung

Auswahl eines geeigneten Passwort Management Systems mit anschließender Implementierung/Integration in die bestehende Netzwerk Infrastruktur.

1.1 Kurze Projektbeschreibung

a) Erläuterung des Geschäftsprozesses

Einbindung und Schnittstellen des Projekts innerhalb eines Auftrages bzw. Teilauftrages

c) Angaben zum Ist-Zustand, u. a. technische Einrichtungen

d) Ziel des Auftrages und Darstellung des Nutzens für den Anwender/Kunden

Zurzeit verwendet die Firma „XYZ“ eine Open Source Software für die Verwaltung der Logindaten von Kundensystemen, welche in einer Datenbank hinterlegt sind.

Diese Datenbank wird regelmäßig gesichert, auf einem File Server hinterlegt und zwischen zwei Standorten der „XYZ“ synchronisiert. Der Zugriff auf diese Dantebank ist mit einem Masterpasswort gesichert. Mit diesem Passwort ist es möglich sowohl die Einträge aller Kunden im Klartext einzusehen, als auch zu ändern oder zu löschen. Mit der jetzigen Lösung ist nicht nachvollziehbar, welcher Mitarbeiter, wann und mit welchem Passwort, Zugriff auf ein Kundensystem hat. Des Weiteren könnte ein Diebstahl der Datenbank zur Kompromittierung aller Kunden Logindaten führen.

Zur Erhöhung der Unternehmenssicherheit soll das bestehende Passwort Management abgelöst werden. Das Ziel des Projekts ist es, die vollständige Protokollierung sowie Kontrolle über die Zugriffe auf die Kundensysteme zu gewährleisten.

Des Weiteren ist das User Access Management eine Voraussetzung, für die, von der "XYZ" angestrebten Zertifizierung nach ISO 27001.

Es soll eine plattformunabhängige Lösung gefunden werden, in welche sich die bestehenden Datenbankbestände integrieren lassen. Das Verwalten der Logindaten soll ohne direkten Zugriff auf die Datenbank geschehen. Durch Redundanz des Systems, an einem weiteren Standort, soll hohe Verfügbarkeit sowie Ausfallsicherheit erzeugt werden.

Die Integration des neuen Systems wird in einem heterogenen Unternehmensnetzwerk, bestehend aus div. physikalischen als auch virtuellen Maschinen, Linux, Windows, Mac-OS, realisiert. Dem Firmennetzwerk liegt eine Windows Active Directory Domäne zu Grunde.

2.0 Projektumfeld

Das Unternehmen „XYZ“ mit seiner Hauptniederlassung in Timbuktu und einer Zweigstelle in Bokinafaso, beschäftigt zurzeit 35 Mitarbeiter. Das Betätigungsfeld der Firma besteht hauptsächlich in dem Vertrieb und Support von IT Sicherheitslösungen. Des Weitern bietet die „XYZ“ auch Schulungen rund um die IT Sicherheit an.

Als Praktikant bin ich der Abteilung Technik zugewiesen, in welcher ich auch das Projekt durchführe, da es sich um ein internes Projekt handelt.

3.0 Projektplanung einschließlich Zeitplanung

a) Angaben der Projektphasen,

Nennung der erforderlichen, wesentlichen Arbeitsschritte mit Vernetzungen

c) Kennzeichnung der prüfungsrelevanten Phasen

d) Tabellarische Auflistung der Phasen und deren zeitliche Aufwände

Definitionsphase (2,5h)

- Besprechung Auftrag (1h)

- Ist-Analyse (0,5h)

- Soll-Konzept (1h)

Planungssphase (11h)

- Erstellung eines Projektstrukturplan (1h)

- Erstellung Zeitplan mittels Projektablaufplan, Netzplan (2h)

- Evaluieren möglicher Lösungen (4h)

- Erstellen einer Vergleichsmatrix (2h)

- Entscheidungsfindung (1h)

- Kostenanalyse (1h)

Realisierungsphase (12h)

- Erwerb und Download der Software (1h)

- Installation der ermittelten Software auf EXSi / VMware (1h)

- Anpassen der Software an die Unternehmensanforderung (2h)

- Erstellung und Anpassung eines clones für Test von Failover auf EXSi (2h)

- Sicherung und Migration der bestehenden Datenbank (1h)

- Testen auf korrekte Ausführung (3h)

- Puffer (2h)

Abschlussphase (9,5h)

- Fazit (0,5h)

- Erstellung Projektdokumentation (8h)

- Projektübergabe/Abschlussbesprechung (1h)

Gesamt (35h)

4.0 geplante Dokumentation zur Projektarbeit

......

Vielen Dank für eure Zeit und Gruß aus Köln

[flashpixx]

Ich halte es für fahrlässig Klartextpasswörter zu verwenden, da nützt auch kein neues Managementsystem. Passwörter gehören gehasht & gesalzen und nicht im Klartext. Im Grunde sollte das Design des Systems überarbeitet werden, damit es mit gehashten Passwörtern arbeitet, das was Du hier machst halte ich für mehr als fahrlässig, weil Du im Grunde das Problem nicht erkennst

[Kölner]

Moin flashpixx,

danke für die schnelle Antwort.

Ich halte es für fahrlässig Klartextpasswörter zu verwenden, da nützt auch kein neues Managementsystem. Passwörter gehören gehasht & gesalzen und nicht im Klartext. Im Grunde sollte das Design des Systems überarbeitet werden, damit es mit gehashten Passwörtern arbeitet, das was Du hier machst halte ich für mehr als fahrlässig, weil Du im Grunde das Problem nicht erkennst

Kann sein das ich das Problem nicht erkannt habe, vielleicht magst du mir ja auf die Sprünge helfen.

Der Zugriff auf diese Dantebank ist mit einem Masterpasswort gesichert. Mit diesem Passwort ist es möglich sowohl die Einträge aller Kunden im Klartext einzusehen, als auch zu ändern oder zu löschen.

Also erst nach dem das Masterpasswort eingegeben wurde, liegen die Daten in Klartext vor. Masterpasswort zu knacken wäre zwar schwer aber nicht unmöglich. 1 Grund für Systemwechsel.

Bei Anwendung, soll heißen, bei Zugriff auf Kundensystem wird https/ssl Verbindung verwendet, also eigentlich auch nichts mit Klartext. Wo lieg ich falsch, mit meinem Ansatz?

Vielen Dank für die Mitarbeit.

Gruß aus Köln

[Aras]

Da bin ich aber beruhigt dass man nur ein(!) Passwort knacken muss um an alle Passwörter ranzukommen.

Auch in Hinsicht dass nur einer das Klartextpasswort sehen kann, lässt sich kein Bedarf für die Klartextspeicherung erkennen.

Dass ihr auch noch ein Sicherheitsunternehmen seid ist bedenklich.

[Akku]

Wie bereits erwähnt, solltest du dir wirklich Gedanken machen. Als Prüfer würde ich deine Entscheidung und Vorgehensweise bzgl. der Passwörter, mehr als bedenklich finden. Dies hätte mit Sicherheit einen nicht unerheblichen Einfluss auf deine Abschlussnote.

[Kölner]

Da bin ich aber beruhigt dass man nur ein(!) Passwort knacken muss um an alle Passwörter ranzukommen.

Auch in Hinsicht dass nur einer das Klartextpasswort sehen kann, lässt sich kein Bedarf für die Klartextspeicherung erkennen.

Dass ihr auch noch ein Sicherheitsunternehmen seid ist bedenklich.

Servus!

Ich stehe irgendwie total auf dem Schlauch.

Anscheinend ist mein Text nicht besonders gut gelungen. Wo steht, das in Klartext gespeichert wird? Erst nach dem Masterpasswort wird in Klartext angezeigt, lokal... den JA! die Kollegen hier haben schon so ne grobe Idee, wie das funktioniert, so mit die IT-Gedöne und dem ganzen Sicherheitsdingens Heisst ja nicht das ich der Crack bin, ich bin Praktikant, aber die Kollegen hier sind es definitiv. (darum wärs nett, wenn man nicht ne FIRMA, oder deren MITARBEITER grundlos runterzieht, nur weil ich vieleicht nicht gut genug bin einen Sachverhalt verständlich wieder zu geben). Aber macht euch ruhig lustig, den Humar hat wer trotzdem lacht

Aber vielen Dank für die kostruktive Kritik.

[Kölner]

Hi Akku,

vieln Dank für deine Antwort.

Wie bereits erwähnt, solltest du dir wirklich Gedanken machen. Als Prüfer würde ich deine Entscheidung und Vorgehensweise bzgl. der Passwörter, mehr als bedenklich finden. Dies hätte mit Sicherheit einen nicht unerheblichen Einfluss auf deine Abschlussnote.

Was genau meinst du: welche Entscheidung soll ich denn bis hier her getroffen haben? Nicht zu verwechseln wäre IST-Zustand und wo es hin gehen soll/kann..

Vieleicht hast du noch ne Minute und schenkst mir ein paar Worte damit ich klar seh.

Vielen Dank

[Akku]

Deine Entscheidung bzgl. der Passwortproblematik.

1. Du hast ein Masterpasswort. Sobald das richtig eingegeben wurde, hast du Zugriff auf alle Kundendaten. Richtig?

2. Jedem Kunden ist aber wieder (hoffentlich) ein Passwort zugewiesen, dass aber nun im Klartext angezeigt wird. Richtig?

3. Wenn dem so ist, kann ich nach "knacken" des Masterpassworts ein schweres Chaos anrichten. Das must du verhindern.

Soweit klar?

[Kölner]

Hello Akku,

Deine Entscheidung bzgl. der Passwortproblematik.

1. Du hast ein Masterpasswort. Sobald das richtig eingegeben wurde, hast du Zugriff auf alle Kundendaten. Richtig?

2. Jedem Kunden ist aber wieder (hoffentlich) ein Passwort zugewiesen, dass aber nun im Klartext angezeigt wird. Richtig?

3. Wenn dem so ist, kann ich nach "knacken" des Masterpassworts ein schweres Chaos anrichten. Das must du verhindern.

Soweit klar?

Klar soweit, ziemlich genaue Wiedergabe der IST - Situation und bis hier her gibt’s meiner Seits keinen Einfluss auf den Prozess. (…zudem: auch wenn es jemand gelänge das Masterpasswort zu knacken, müsste er/sie erschwerend erst einmal an die Datenbank kommen. Auch nicht ganz trivial)

Aber wie dem auch sei, genau diese Dinge sollen ja abgestellt werden...

Also vom Ansatz her doch nicht das Schlechteste, oder?

[SilentDemise]

wie werden die passwörter im hintergrund verschlüsselt? Wie wird das Master Kennwort überwacht, stichwort auditing, wie wird die Datenbank in der die Passwörter liegen verschlüsselt, wo liegen die Connectionstrings zu der Datenbank?

[Kölner]

Hey SilentDemise,

vielen Dank für dein Interesse.

wie werden die passwörter im hintergrund verschlüsselt? Wie wird das Master Kennwort überwacht, stichwort auditing, wie wird die Datenbank in der die Passwörter liegen verschlüsselt, wo liegen die Connectionstrings zu der Datenbank?

Derzeitige Verschlüsselung der Datenbank mit AES 256bit. (Passwörter werden zuzeit nicht noch mal extra verschlüsselt) Masterpasswort wird zurzeit nicht überwacht, ist aber nur den Mitarbeitern bekannt welche es benötigen.

Zur Frage: wo der connectionstring liegt - kann ich momentan nicht beantworten, da ich mit der Fragestellung "wo" gerade nicht so viel anfangen kann, sorry my fault.

Zu eventuellen Zukünftigen Lösungen kann ich noch nichts sagen, da ich sie mir im Einzelnen noch nicht angeschaut habe. Ich habe ja auch noch keinen Antrag bei der IHK gestellt.

Aber im Übrigen finde ich deine Fragen schon schick und könnte mir vorstellen das ein Prüfer die auch stellt, also schon mal Dankeschön.

[flashpixx]

Passwörter werden zuzeit nicht noch mal extra verschlüsselt

Noch einmal: Passwörter gehören nicht verschlüsselt, sondern sie sollten gehasht werden und zusätzlich mit einem Salt versehen werden. Eine Verschlüsselung ist umkehrbar, ein Hash nicht (Grundlage der Algebra)

Egal was Du Dir hier als Projekt überlegst, in der Prüfung bietest Du mit dieser Thematik eine Steilvorlage, Dich sprichwörtlich fachlich zu zerlegen. Egal was Du hier machst, die Passwörter liegen unverschlüsselt in der Datenbank und jeder der das Masterpasswort kennt, kann sie lesen, aber selbst ein Administrator soll Passwörter nicht lesen können, allenfalls darf der Admin ein neues Passwort setzen. Bitte benutze einmal Google und suche danach wie oft in den letzten Jahren Firmen durch solche massiven Sicherheitslücken eine negative Presse erhalten haben, weil Passwörter ungehasht gespeichert wurden bzw. im Klartext abgelegt wurden. Es ist schon seit Jahren Standard Passwörter zu hashen.

Das Argument "das Passwort ist nur einigen Mitarbeitern bekannt" ist nichts wert, denn wer sagt, dass das Passwort nicht nach außen gelangen kann. Und wenn die Anwendung nun auf die Datenbank connected, dann kann der User den Connectionstring abgreifen und macht einfach ein "select * from usertable" und schon sieht er von allen Benutzern die Passwörter im Klartext.

Ich rate Dir, entsorge das Projekt, denn es hat massive fachliche Fehler.

[Kölner]

Hey flashpixx,

vielen Dank für deine dezidierte Meinung!

. ...Egal was Du hier machst, die Passwörter liegen unverschlüsselt in der Datenbank und jeder der das Masterpasswort kennt, kann sie lesen, .

Ja genau und Teil des Projekts soll eben sein dies zu ändern.

Bitte benutze einmal Google und suche danach wie oft in den letzten Jahren Firmen durch solche massiven Sicherheitslücken eine negative Presse erhalten haben.

Ja kann sehr interessant sein, wer schon alles negativ aufgefallen ist. Das Projekt soll ja das Auftreten eben der massiven Sicherheitslücken, wie du sie benennst, ja abstellen.

Es ist schon seit Jahren Standard Passwörter zu hashen. .

Danke für den Hinweis, werde es nachlesen.

Das Argument "das Passwort ist nur einigen Mitarbeitern bekannt" ist nichts wert, denn wer sagt, dass das Passwort nicht nach außen gelangen kann.

Genau, gut erkannt das es nicht viel wert sein mag und es soll Teil des Projekts sein dies zu ändern. Eventuell durch ein regelbasierte Zugriffssteuerung zum Beispiel, mal sehen was es da gibt.

Und wenn die Anwendung nun auf die Datenbank connected, dann kann der User den Connectionstring abgreifen und macht einfach ein "select * from usertable" und schon sieht er von allen Benutzern die Passwörter im Klartext. .

Sehr interessanter Aspekt, das blick ich noch nicht ganz, wie das "abgreifen funktioniert" bzw wie man es verhindert..

Ich rate Dir, entsorge das Projekt, denn es hat massive fachliche Fehler

davon bin ich noch nicht ganz überzeugt, ist eigentlich auch viel zu Spannend. Wie kann ein noch nicht durch geführtes Projekt zu viele fachliche Fehler haben? Man kann sicherlich einiges/vieles verbessern, obs mein Spatzenhirn hinkriegt steht auf nem anderen Blatt.

Aber wie schon gesagt und ganz erhlich gemeint, Danke für den Rat.

[MartinSt]

Ich treibe die Fragen mal weiter:

Wie machst du ein automatisches regelmäßiges Backup der DB ohne dass das Sicherungsscript das Masterpasswort kennt?

Wie sicherst du das Backup gegen unberechtigten Zugriff?

Wie sicherst du die Konfig-Daten des DMS, denn diese Konfiguration bestimmt z.B. bei Postgres welche Anmeldung ein Passwort erzwingen.

[flashpixx]

Ja genau und Teil des Projekts soll eben sein dies zu ändern.

Die Änderung heißt: Nutze gehashte Passwörter und keine Vershclüsselung

Das Projekt soll ja das Auftreten eben der massiven Sicherheitslücken, wie du sie benennst, ja abstellen.

Nein Du klebst ein Heftpflaster drauf, denn das Problem sind die Klartextpasswörter in der Datenbank, das ist ein Designfehler der Datenbank bzw. der Anwendung und diesen muss man beseitigen. Wenn jemand mit dem Messer abgestochen wird, stellst Du ja auch keine Wand davor und sagt "ich seh es nicht, also ist es nicht da".

Genau, gut erkannt das es nicht viel wert sein mag und es soll Teil des Projekts sein dies zu ändern. Eventuell durch ein regelbasierte Zugriffssteuerung zum Beispiel, mal sehen was es da gibt.

s.o.

Sehr interessanter Aspekt, das blick ich noch nicht ganz, wie das "abgreifen funktioniert" bzw wie man es verhindert..

Deine Anwendung wird "irgendwie" auf die Datenbank connecten, d.h. ich hole mir den Connectstring, nehme ein Tool wie Database Management Software Tools - DbVisualizer connecte mich mit dem Connectionstring direkt nativ auf die Datenbank mache ein "show tables" und gucke die tabellen mit "select * from table" durch und zack ich sehe wunderbar alle Klartextpasswörter. Und dann logge ich mich mit einem anderen User / Passwort ein, denn das kann ich ja einfach lesen, und mache irgendwas lustiges in den Daten und da ich ja ein anderer User bin, kann ich ggf die Daten dieses Users irgendwo abziehen und veröffentlichen. Sind das z.B. Geschäftsdaten, dann könnte das juristisch richtig Probleme bei Euch machen

Wie kann ein noch nicht durch geführtes Projekt zu viele fachliche Fehler haben? Man kann sicherlich einiges/vieles verbessern, obs mein Spatzenhirn hinkriegt steht auf nem anderen Blatt.

Du erkennst nicht das Problem, das Problem ist ein fehlerhaftes Design der Datenbank / Software und Du versuchst es mit einem Heftpflaster zu flicken. Passwörter - ich wiederhole mich - werden (!!) niemals (!!) verschlüsselt / im Klartext gespeichert, sondern immer als Hash mit einem Salt. Die Lösung, die Du machen musst, ändere die Software / Datenbank so, dass dort gehashte Passwörter stehen und eben nicht die Klartextpasswörter.

Es ist völlig irrelevant, ob Du nun den Dump verschlüsselst, denn spätestens, wenn ich auf die Datenbank drauf komme, dann komme ich auch an die Passwörter und d.h. da sie dort im Klartext stehen, kann ich sie auch lesen. Wenn ich irgendwie an das Masterpasswort dran komme, dann hole ich mir einfach den Dump, entschlüssle ihn und habe auch die Passwörter aller Kunden im Klartext. Eine Verschlüsselung ist das falsche Werkzeug !! Der richtige Weg ist jedes Passwort mit einer Kryptologische Hashfunktion / Hashfunktion in der Datenbank zu speichern. Z.B. wird ja das Windows Login Passwort auch nicht im Klartext gespeichert, sondern eben als Hash. Da Dein Projekt eben genau diesen fatalen Fehler hat, machst Du es mit dem, was Du tust nicht besser und es bietet aus Sicht der Prüfer extrem viele Angriffspunkte Dir unangenehme Fragen zu stellen. Ich würde Dir z.B. so eine Frage stellen "Definieren Sie bitte einmal Hashing" oder "Erläutern Sie bitte den Unterschied zwischen Hashing, Salt & Verschlüsselung" und dann abschließend käme die Frage "Warum nutzen Sie kein Hashing, sondern eine Verschlüsselung, mit der es möglich ist, die Passwörter im Klartext abzufragen. Wie würden Sie die Qualität Ihrer Arbeit unter diesen Bedingungen bewerten".

Sorry, ich verstehe aber echt nicht, was daran so schwierig zu verstehen ist !? Google doch einmal danach wie man Passwörter richtig speichert.

[Kölner]

Nabends flahpixx,

du gibst dir aber echt Mühe, muss ich zugeben.

Dankeschön.

Sorry, ich verstehe aber echt nicht, was daran so schwierig zu verstehen ist !? Google doch einmal danach wie man Passwörter richtig speichert.

Kommunikation ist so ziemlich das Schwierigste, was so man betreiben kann.

Ich versteh dich nicht, weil ich nirgends geschrieben habe, dass die Passwörter auch in Zukunft in Klartext gespeichert bleiben müssen oder verschlüsselt werden sollen. Kann natürlich mit meiner Darstellung im Antrag zu tuen haben, dass es so rüber kommt(Trotzdem 1001 Dank für das Augenmerk in die Richtung salted hash vs. Verschlüsselung wird helfen genauso wie der Link zum connection string).

Steht doch nirgends etwas von Unveränderlichkeit der angesprochenen Dinge?

Fehlende Fachkompetenz kann man mir ja gerne vorwerfen, ist kein Ding, dafür lerne ich es ja auch gerade. Aber man kann doch nicht davon ausgehen, das wenn ein Problem x auftritt, das man evtl nicht sofort, oder gleich perfekt lösen kann, das Ganze gleich in die Tonne zu werfen. Da ist noch ein bissel Luft bis zu der Durchführung des Projekts (wenn es denn überhaupt angenommen wird bei der IHK), also auch um noch was dazu zu lernen. Deshalb meine Unverständnis und ich werf erst mal gar nix inne Tonne

Aber wie schon geschrieben nix für Ungut, ich bin da eher Dankbar für deine konstruktive Kritik!

Schöne Grüsse und erst mal gute Nacht

[flashpixx]

Ich versteh dich nicht, weil ich nirgends geschrieben habe, dass die Passwörter auch in Zukunft in Klartext gespeichert bleiben müssen oder verschlüsselt werden sollen.

Noch einmal: Verschlüsselung != Hashing

Kann natürlich mit meiner Darstellung im Antrag zu tuen haben, dass es so rüber kommt

Steht doch nirgends etwas von Unveränderlichkeit der angesprochenen Dinge?

Ich zitiere aus Deinem Antrag:

Der Zugriff auf diese Dantebank ist mit einem Masterpasswort gesichert. Mit diesem Passwort ist es möglich sowohl die Einträge aller Kunden im Klartext einzusehen, als auch zu ändern oder zu löschen.

Fehlende Fachkompetenz kann man mir ja gerne vorwerfen, ist kein Ding, dafür lerne ich es ja auch gerade. Aber man kann doch nicht davon ausgehen, das wenn ein Problem x auftritt, das man evtl nicht sofort, oder gleich perfekt lösen kann, das Ganze gleich in die Tonne zu werfen. Da ist noch ein bissel Luft bis zu der Durchführung des Projekts (wenn es denn überhaupt angenommen wird bei der IHK), also auch um noch was dazu zu lernen. Deshalb meine Unverständnis und ich werf erst mal gar nix inne Tonne

Wenn Du auf den aktuellen Stand (Klartextpasswörter) eine Verschlüsselung drauf ziehst, dann macht es das nicht besser und ich würde Dir in der Prüfung sagen, dass Deine Lösung das Problem nicht löst, sondern Du im Grunde am Problem vorbeigeplant hast, denn Du erkennst nicht die Schwachstelle Deines Projekts, die hier noch ein riesiges Sicherheistloch in die Software reißt.

Die Lösung für das Problem heißt: Konzipier die Datenbank neu, so dass dort gehashte Passwörter stehen. Das ist aber als FISI nicht Dein Job, sondern es wäre der Job des FIAE.

Sprichwörtlich kannst Du als FISI das Problem nicht lösen, also folgt daraus, dass Du Dir besser ein anderes Projekt suchst, um Deine Prüfung zu bestehen. Du kannst gerne Dein Projekt mit einem "Passwort-Manager" versuchen, aber ich würde an Deiner Stelle mich sehr sehr sehr sehr gute auf die mündl Prüfung vorbereiten, denn es könnte extrem schwer für Dich werden dein Projekt so dem PA darzustellen, dass Du hier ein fachliches gutes Konzept umgesetzt hast. Du riskierst in der aktuellen Form, dass Du ggf noch einmal wiederholen musst.

Das was Du in Deinem Antrag steht, ist fachlich extrem bedenklich, warum willst Du so ein Projekt mit aller Gewalt machen? Mach es Dir doch einfacher und suche Dir ein Projekt, was fachlich und wirtschaftlicher auf soliden Beinen steht.

[Aras]

Werden überhaupt die Klartextpasswörter für externe Systeme gebraucht?

Also werden da drin z.B. Passwörter für externe Dienste gespeichert? Nicht dass wir FTP-Passwörter hashen möchten und am Ende keinen Zugriff mehr darauf haben.

[SilentDemise]

Wenn die fachliche Anforderung lautet, die Passwörter müssen im Klartext anzeigbar sein, und nur dann, sollte man sich über das Thema Verschlüsselung Gedanken machen. Ansonsten wie flashpixx sagt auf jedenfall mit ausreichendem hashing arbeiten.

Klartext Passwörter wären nicht nur in der implementierung weit aufwendiger, das zieht einen nötigen Rattenschwanz nach sich, der innerhalb eines Abschlussprojekts nicht zu bewältigen ist. Eure Firma kommt dann um die Implementierung massiver Sicherheitsmechanismen nicht drum herum, vor allem wenn auch Kundenpasswörter abgelegt werden. Wir reden dann von Zutrittskontrolle, auditing, 4 Augen Prinzip, PKI, HSMs, Database encryption und dem ganzen Prozessgeraffel was da hinten dran hängt, denn nur dann kann mit mit einigermaßen guten Gewissen über eine Verschlüsselung nachdenken. Alles andere halte ich für absolut fahrlässig.

[Kölner]

Schönen guten Morgen flashpixx. Guten Morgen liebe Mitlesenden.

Vielen Dank für deine/eure Geduld!

Kann sein dass der Groschen bei mir nur centweise fällt, aber damit er dann fällt noch folgendes:

Mitarbeiter X kommt morgens ins Büro möchte sich anmelden. Login Fenster meldet sich, er gibt seine credentials ein. Im Hintergrund gibt z.B. die AD dem Login den Hash Algo.(evtl. MD5), + das Salt. Aus dem Passwort das gerade von Mitarbeiter X eingeben wurde, wird wieder der Hash-Wert errechnet, mit dem Wert in der AD abgeglichen und wenn es passt, wird der User mit seinen credentials zugelassen. (Ich hoffe soweit erst mal keine groben Schnitzer in der Logik)

Mitarbeiter X ist zudem noch in der Gruppe Helpdesk vertreten und hat ca.100 Remote Devices zu bespassen. Diese devices liegen nicht gezwungener Maßen in derselben AD Domäne. Um jetzt nicht 100 credentials im Kopf haben zu müssen, bedient er sich irgendeines softwaretools als Passwortsafe. Wie bekommt mit Mitarbeiter X die Logindaten zu seinen Remote Devices, wenn diese nur als Hashwert in der Datenbank des Passwortsafes abgelegt sind?

Gar nicht oder, denn die Passwörter selbst liegen ja nicht vor sondern nur die gesalzenen Hashes, welche nicht umkehrbar sind?

Wenn ich dich jetzt soweit richtig verstehe, wäre auf jeden Fall der Mitarbeiter X genötigt, die 100 Logindaten im Kopf zu bewaren. Im Hinblick auf die Sicherheit dürfte der Mitarbeiter kein tool verwenden.

Was ist bei 200 remote devices oder 500.

Ich glaub schon, dass ich dich so halbwegs verstanden habe. Aber es mag mir noch nicht einleuchten, dass dem „armen“ Helpdeskmitarbeiter nicht geholfen werden kann. Irgendwo hakt es da in meinem Schädel.

[Kölner]

Guten Morgen SilentDemise.

Ich habe das Gefühl das du da Recht haben könntest, das es zu Komplex werden kann, für ein Abschlussprojekt.

Meine Ursprungsfrage lautete mal : passwort mangement system - zu "dünn" als Projekt.

Diese Fragestellung resultiert daraus, das einer meiner Dozenten eher der Meinung ist, das so wie sich der Antrag liest, es nicht für ein Projekt reichen könnte.

Danke Gruss aus Köln

[flashpixx]

Um jetzt nicht 100 credentials im Kopf haben zu müssen, bedient er sich irgendeines softwaretools als Passwortsafe. Wie bekommt mit Mitarbeiter X die Logindaten zu seinen Remote Devices, wenn diese nur als Hashwert in der Datenbank des Passwortsafes abgelegt sind?

Gar nicht oder, denn die Passwörter selbst liegen ja nicht vor sondern nur die gesalzenen Hashes, welche nicht umkehrbar sind?

Das ist Schwachsinn, denn in diesem Fall nutzt man Single Sign-on damit existiert das Problem nicht.

Ansonsten nutzt man Secure Shell - Wikipedia, the free encyclopedia mit Public-Key-Authentifizierung da ist noch nicht mal mehr ein Passwort notwendig

Ich glaub schon, dass ich dich so halbwegs verstanden habe. Aber es mag mir noch nicht einleuchten, dass dem „armen“

Helpdeskmitarbeiter nicht geholfen werden kann. Irgendwo hakt es da in meinem Schädel.

Der User bekommt genau ein Passwort und das kann er selbst wählen, wenn es noch sicherer sein soll, dann gibt es Einmalpasswörter mit entsprechenden Geräten. Ein Passwort sollte sich der User merken können, alle anderen Authentifizierungen werden über Schlüssel oder eben Sigle-Sign-On gemacht, damit ist keine Passworteingabe mehr erforderlich. Das Passwort liegt weiter als Hash vor und ich kann relativ einfach bei kompromitierten Schlüssel diesen dann sperren.

Wie schon gesagt, Dein Projekt hat fachliche Mängel.

@SilentDemise: FTP sollte man sowieso nicht verwenden, sondern wohl eher SFTP und da kann ich dann mittels Key authentifzieren.

[SilentDemise]

unter windows möchte ich allerdings kein ssh nutzen, aber das wäre dann ftps - mit PKI und smart Card logon aber kein Problem.

Agree was SSO angeht, gerade unter Windows mit Domain Trust überhaupt kein Problem.

Nebenbei: zu ftp hab ich nix geschrieben

[Kölner]

Nabends Allerseits!

Sehr anregende "Unterhaltung" bisweilen.

Frage ob ichs richtig verstehe:

Ihr würdet ein Single Sign On empfehlen, für vieleicht 50 unterschiedliche Domänen, um dort die Backendgeräte wie Switche,Router,Firewalls und Proxies zu konfigurieren? :confused:

[flashpixx]

Ihr würdet ein Single Sign On empfehlen, für vieleicht 50 unterschiedliche Domänen, um dort die Backendgeräte wie Switche,Router,Firewalls und Proxies zu konfigurieren? :confused:

Nein, in diesem Fall würde ich SSH mit Key nutzen, ist jedenfalls bei uns im Rechenzrentrum das Standardverfahren + zentraler Authentifizierungsserver via LDAP. Administrative Tätigkeiten werden hier nur per SSH gemacht.