Zeige Ergebnis 1 bis 4 von 4

Thema: Passwörter in DB - Klartext gespeichert

  1. #1
    STARFACE User

    Registriert seit
    23.05.2012
    Beiträge
    43

    Ausrufezeichen Passwörter in DB - Klartext gespeichert

    Hallo zusammen,


    Ich persönlich finde es relativ bedenklich das Passwörter in Klartext in die DB gespeichert werden. Bin ich da nicht allein? Kann man das beeinflussen (soweit ich weiss ja nicht).
    Es gibt ja doch Benutzer die für verschiedene Sachen mal das gleiche Passwort benutzen. Und das sollte man auch als Admin keine Möglichkeit haben das Passwort eines Benutzers anzeigen zu können!!
    Mit Speedial von O-Byte verschärft sich das ganze noch einmal. Aber deswegen bin ich schon mit O-byte in Kontakt.

    Aber ich denke wirklich das man hier auf irgendeinen "gesalzten" Hash oder so setzten sollte.

  2. #2
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.362

    Standard

    Eine Änderung an diesem Verhalten würde vieles zerbrechen...
    • Es wäre der Anlage nicht mehr möglich, schlechte Passwörter zu erkennen und davor zu warnen.
    • Es gibt viele Anwendungen von Drittanbietern, die die Zugangsdaten eines Users benötigen, um sich selbst per UCI an der Anlage anzumelden.
    • Der Anmeldevorgang würde extrem umständlich:
      Damit die Anmeldedaten eines Users nicht im Klartext übertragen werden, wird aus Login-ID und Kennwort ein MD5-Hash gebildet und zur STARFACE übertragen. Die STARFACE kann nun in der Datenbank suchen, welchem User MD5(Login-ID, Kennwort) gehört — und zwar direkt auf der Datenbank, weil PostgreSQL eine solche Query unterstützt.
      Wären die Kennwörter gesalzen und gehasht, müßte die STARFACE den Salt des anzumeldenden Users vorab zum Client übertragen, denn dieser müßte einen gesalzenen Hash generieren und übertragen. Die STARFACE kann vorher aber nicht wissen, welcher User sich anmelden wird. Man müßte also für jeden User den gleichen Salt verwenden, auf das Salzen verzichten oder einen Mehrwege-Handshake machen, bei dem der Benutzer erst seinen Benutzernamen eingibt, dieser übermittelt wird und in einem zweiten Schritt, nachdem der passende Salt übermittelt wurde, beim Client erneut Benutzername und Kennwort abgefragt wird, um dieses nun gesalten als Hash übermitteln zu können. Das würde den Usern vermutlich wenig Spaß machen.
      Bleibt also: Auf das Salzen zu verzichen oder einen Salt für alle User und STARFACE-Anlagen zu verwenden. Und schon sind die Hashes deutlich weniger sicher. Wäre der Salt pro Anlage eindeutig, müßte er immernoch zum Anmeldeclient übertragen werden.


    Die Zugangsdaten in der STARFACE sind außerdem lediglich dem Root-User zugänglich. Ist dessen Kennwort kompromittiert, kommt man ohnehin an die User-Kennwörter indem man auf Anmeldungen wartet. Hierzu muss man den Clients nur eine modifizierte Anmeldeseite unterschieben, die das Kennwort ungehasht im Klartext übermittelt.

    Falls es darum geht, dass der Administrator nicht die User-Kennwörter sieht, so läßt sich das technisch nicht vermeiden (siehe Modifikation der Anmeldeseite). Ohnehin ist es gute Praxis, pro Dienst ein eigenes Kennwort zu verwenden. Somit hätte der Administrator nur Zugang zur STARFACE — hat er aber ohnehin schon. Oder man generiert die Kennwörter der User über die STARFACE zufällig und verwendet AD für die Authentisierung.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  3. #3
    STARFACE Expert

    Registriert seit
    21.02.2008
    Beiträge
    468

    Standard

    @fwolf
    für was brauchen wir den Sicherheit im NSA Zeitalter. deine Argument sind indiskutabel.
    andere Authentifizierungsdienste wie z.B. das MS AD schaffen es ja auch.
    man kann alles tot reden ;-)

    Es kommt immer darauf an wie viel Sicherheit man seinen Kunden zugestehen will.
    1 x Starface VM | 231 User mit Snom | Telekom SIP-Trunk | Peoplefone SIP-Trunk | 25 DECT Sender | 59 DECT Mobilteile | 45 x PAP2T für Fax/Tor/Tür Sprechstellen|
    1 x Starface Pro | 20 User mit Snom | Peoplefone SIP-Trunk | 2 x PAP2T für Fax/Tor/Tür Sprechstellen
    1 x Starface Advanced | 11 User mit Snom | Telekom SIP-Trunk | Peoplefone SIP-Trunk | 2 x PAP2T für Fax/Tor/Tür Sprechstellen

  4. #4
    STARFACE User

    Registriert seit
    11.01.2011
    Beiträge
    37

    Standard

    Man will es nicht glauben, aber seit der neuesten Version von dieser Woche ist das endlich umgesetzt:

    O-Ton Support:
    Hallo Herr ....,
    ich wollte Ihnen nur kurz mitteilen, dass die Version mit verschlüsselten Passwörtern in der Datenbank inzwischen veröffentlicht wurde:

    http://www.starface.de/de/Service/versionhistory.php
    Version 6.4.2.19


    Reguläre Releases und Updates
    Version 6.4.2.19 Released am 06.07.2017

    Features:
    STARFACE PBX/Allgemeine Verbesserungen
    Bessere Handhabung von Passwörtern
    Neuer Authentifizierungsmechanismus
    Wichtiger Hinweis
    Bitte updaten Sie Ihre UCC Clients für Windows und Mac, sowie den Mobile Client für Android, da die älteren Versionen der Clients mit der neuen Version der STARFACE nicht kompatibel sind.
    Bitte beachten Sie vor der Installation
    Für ein automatisches Update der UCC Clients aktivieren Sie bitte vor dem Serverupdate in jedem Client die Einstellung "SSL verwenden".
    Bitte beachten Sie, dass das Update eine größere Datenmenge herunterlädt.
    Sollten Sie eine STARFACE PRO v2 aktualisieren, beachten Sie bitte, dass der freie Speicherplatz mindestens 2,5 GB betragen sollte.
    Wir empfehlen, vor dem Update die Rufliste mit dem Modul 'STARFACE Archivierung' zu verkleinern, sowie in allen Modulen mit vollqualifizierten Rufnummern zu arbeiten.
    UCC Clients
    Die Release Notes für den UCC Client für Windows finden Sie hier.
    Die Release Notes für den UCC Client für Mac finden Sie hier.
    Bugfixes:
    Bugfixes
    Behoben: Sehr seltene Störungen in der Leitungskonfiguration [Call#1067517]
    Behoben: Einspielen des Backups war in Ausnahmefällen nicht möglich [Call#1062495]
    Behoben: Eigene externe Rufnummern wurden falsch geroutet [Call#1067280]
    Behoben: Bei Providerprofilen, die vom Default-Land abweichen, war die Register-Zeile falsch [Call#1069071]
    Behoben: Internet Explorer reagiert nicht auf Optionswahl zum Versenden von Logfiles

Ähnliche Themen

  1. Abfrage ob Rufummer im Adressbuch gespeichert
    Von sd-tele.com im Forum STARFACE Module
    Antworten: 1
    Letzter Beitrag: 10.04.2012, 10:04
  2. Telefonkonferenz - Webserveradresse ohne / gespeichert
    Von thomas.hertli im Forum Bugreports
    Antworten: 3
    Letzter Beitrag: 15.12.2011, 17:45
  3. Antworten: 1
    Letzter Beitrag: 06.12.2011, 11:06

Stichworte

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •