Server Notice:

hide

Public Pad Latest text of pad akv-passwortsicherheitsabfragen Saved April 6, 2019

 
    Erarbeitung eines Fragenkatalogs zur Passwortsicherhei
-------------------------------------------------------------------------------
 
  • Hinweis: weiter unten
 
 
 
 
-------------------------------------------------------------------------------
Input Patrick Breyer:
 
die Regelung zur Bestandsdatenauskunft könnte genutzt werden, um
Passwörter zu den folgenden
a) soziale Netzwerke wie von Facebook oder wer-kennt-wen.de angeboten
b) Microbloggingdienste wie von Twitter oder bka.li angeboten
c) Bloggingdienste wie von blogspot.de oder blogg.de angeboten
d) Hostingdienste wie von all-inkl oder 1&1 angeboten
e) Speicherdienste wie von Flickr oder Rapidshare angeboten
f) DE-Mail-Dienste sowie der ePostbrief-Dienst
i) Anonymisierungsdienste wie Proxies, TOR oder von Jondonym angeboten,
j) anonyme Hinweisgebersysteme wie vom Bundeskartellamt oder vom LKA
Niedersachsen angeboten
 
Mich würde interessieren, welche Anbieter Passwörter
- Klartext
- MD5?
- MD5 mit Salt?
- Mehrer Iterationen (wie viele?)?
Je nach Verfahren kann es einfach sein, das Ausgangspasswort oder ein
anderes gültiges Passwort zu ermitteln, ohne das Passwort zurücksetzen
zu müssen (was der Nutzer bemerkt).
 
 
 
-------------------------------------------------------------------------------
Input von Katta:
 
im Endeffekt stellt sich natürlich die Frage ob es in der Praxis auch auf eine "aktive Zusammenarbeiter" der Telkos hinausläuft. Ich habe einen Telko-Admin gefragt und der meinte, dass das eh egal sei wie das verschlüsselt ist, da sie das Passwort unbemerkt zurücksetzen können und dann ohne das Passwort zu kennen wieder den Ursprungszustand herstellen können.
 
-------------------------------------------------------------------------------
Input von Volker Birk:
 
Erstens ist das Speichern von Kennwort-Hashes eine Kunst, die
nicht-trivial ist. Das Speichern “MD5 mit Salt in mehreren Iterationen”
kann z.B. völlig unsicher sein, wenn der Salt nicht aus einer guten
Zufallsquelle stammt. Ob eine gute Zufallsquelle verwendet wurde bei
jedem Salt, das sieht man den generierten Salts ggf. nicht auf den
ersten Blick an.
 
Was man also testet ist, ob sich die Leute Gedanken über's Problem
gemacht haben, die die Software geschrieben haben – und vielleicht
trotzdem völlig versagt. Wenn man testen möchte, ob das taugt, was sie
geschrieben haben, kommt man weder um eine Quellcodeanalyse noch um ein
Bewerten der in der Implementierung verwendeten Zufallsquellen drum
herum (und um das Nachvollziehen, wo die bisherigen Salts herstammen).
 
Dann ist es so, dass wenn man sich gegen Regenbogentabellen schützt,
dass man dann immer noch nicht geschützt gegen weiche Kennwörter ist.
Da muss dann z.B. Pepper verwendet werden, und da wiederum muss man die
Implementierung genau beleuchten, wie man an denselben im Zweifel
rankommt.
 
Sinnvoll aus Sicht des Speicherns wäre also insbesondere die Kombination
eines harten Kennworts mit dem Hashen über einen Salt aus einer guten
Zufallsquelle, oder das Speichern von sicheren MACs (z.B. HMAC über MD5
oder ein MAC über eine bisher sichere Hashfunktion wie RIPEMD160) aus
Kennwort, Salt und Pepper.
 
Übrigens wäre eine Nachprüfung bei jeder Änderung beteiligter Software
nötig, um die Prüfaussage über's nächste Update zu retten – und das ab
da für jedes Update.
Vernünftiger geschützt gegen das Auslesen eines Datenträgers sind ggf.
sogar die Anbieter, die Kennwörter im Klartext speichern – aber in einem
Kryptocontainer, der nur manuell mit Passphrase aufgeht. Die wiederum
sind nicht geschützt gegen das Auslesen des gemounteten Containers aus
dem laufenden System heraus…
 
Das wäre dann alles zu prüfen und abzuwägen. Wie soll das geleistet
werden? Prüft man das nicht, besteht die grosse Gefahr, dass man
ausgerechnet demjenigen mit dem nächsten grossen Datenskandal die
Bestnote gegeben hat.