Wie am einfachsten Passwörter speichern

[fkerber]

Hi!

Gib auf www.torry.net bei der schnellsuche encryption ein, das erste Suchergebnis isses.
Je nach Delphi-Version hast du ein paar Probleme bei der Install, dazu steht aber im Forum schon einiges.

Ciao fkerber

[titus]

Bei PHP benutz ich immer MD5, das kreirt einen 32 Zeichen langen Hash...

[negaH]

Zitat:

einfachsten Sicher Passwörter speichern

Einfach oder sicher, aber sicher ist immer komplizierter als einfach und dafür unsicher.

Da diese Frage immer wieder auftaucht möchte ich hier einige wichtige Punkte abklären:

1.) ein sicheres Passwortsystem das dem Anwender die Wahl des Passwortes überlässt ist immer nur so sicher zu bekommen wie der User in der Wahl seines Passwortes ein sicheren Schlüssel auswählt. Diese Logik bezieht sich primär auf reine softwarebasierende Systeme, schließt also extra Hardware oder einbruchsichere Server vorerst aus.

2.) es gibt eine grundsätzliche Frage die man vorab klären muß: Muß das Benutzerpasswort zu einem späteren Zeitpunkt wieder lesebar sein oder eben nicht. Benötigt man ein System bei dem es zu jeder Zeit möglich sein muß das benutzte Userpasswort lesbar zur Hand zu haben, da kann nur eine Verschlüsselung in Frage kommen. Benötigt man aber zB. ein Login System in dem der Server oder die Software nur die Korrektheit eines eingegebenen Passwortes überprüfen muß, dann sind Einweg Funktionen wie zB. die secure Hash Algorithmen die beste Wahl.

3.) WO sollen die Zugangsdaten, sprich Benutzername und Passwort gespeichert werden. Geht man von einem System aus das diese Daten in Datenbanken oder Dateien LOKAL im Rechner speichert, also so das JEDER Zugriff auf diese Daten samt Software hat, dann kann es NIEMALS einen sicheren softwarebasierten Schutz geben. Ein Angreifer hat zu jeder Zeit dann die Möglichkeit die wichtigen Daten durch eigene zu ersetzen oder aber die Software zu reverse-engineer'en. In diesem Falle kann nur ein hardwarebasierter Schutz oder aber die Benutzerspezifische Verschlüsselung ALLER Daten als sicher gelten. Den hardwarebasierten Schutz lassen wir mal aussen vor. Eine softwaretechnische Lösung würde mit hilfe des Benutzerpasswortes die kompletten sicherheitsrelevanten Daten verschlüsseln. Das Ziel eines Zugriffsschutzes ist es ja meistens die Daten zu schützen. Diese Art der Zugriffsberechtigung könnte auch als Administrator Login zum mounten verschlüsselter Datenträger verstanden werden.

Werden die Benutzerdaten dagegen auf einbruchsicheren Servern verwaltet so tritt dieser Server als Intranet-Trust auf. In diesem Falle können die Benutzerkonten im Grunde sogar unverschlüsselt gespeichert aber NICHT unverschlüsselt übertragen werden.

D.h. das primäre Ziel warum man ein Benutzerpasswort mit einem Hash absichert und dann als Zugangsberechtigung benutzt liegt NICHT im Schutz des Server, der Daten oder der Software, sondern erstmal nur im Schutz des Benutzers !! Ein Angreifer kann zwar immer noch über die Manipulation der Benutzerkonten auf dem Server Zugriff erlangen er kann aber mit nur enorm geringer Wahrscheinlichkeit das reale Benutzerpasswort ermitteln.
Eine einfache Hash Funktion als Zugriffsschutz ist also keine sichere Lösung aus Sicht der Software.
Sekundär kann man aber die Sicherheit des Gesamtsystemes durch die Anwendung von Hashfunktionen drastisch erhöhen. Aus diesem Blickwinkel heraus wird versucht technologisch die schlecht gewählten Passwörter der Benutzer zu "entschärfen" und "sicherer" zu machen. Dazu MUSS aber in der Berechnung des Passwortes-Hashes ein Zufallswert eingerechnet werden, der sogenannte SALT.


Es gibt nun verschiedene technische Verfahren des Zugriffsschutzes die basierend auf obige Aussagen arbeiten. Einige Szenarien:

Eine Einzelplatz-Software soll einen Login bekommen:
Die beste Wahl ist es mit Hilfe des Benutzerpasswortes alle Daten des Benutzers die in der Software eingepflegt werden zu verschlüsseln. Dieses System lässt sich dahingehend ausbauen das mehrere Benutzerpasswörter die gleichen Daten ver- und entschlüsseln können, es ist also bedingt Multiuserfähig zu bekommen.
Ein Masterkey gespeichert in der Software ist in diesem Falle immer die schlechteste Wahl, schlechter als auf jeglichen Schutz zu verzichten, da sie nur Sicherheit vorgaugelt.


Eine Server Lösung soll Benutzer verwalten und Login's abprüfen, der Server ist nicht einbruchsicher:
Dieses Szenario ist gleichzusetzen wie vorhergenanntes.

Eine Server Lösung soll Benutzer verwalten und Login's abprüfen, der Server ist einbruchsicher entweder im Intranet oder Internet:
In diesem Falle ist es nur WICHTIG das die Benutzerdaten sicher und authentifiziert zum Server gelangen. Der Server selber kann, muß aber nicht, die Benutzerdaten verschlüsselt speichern.
Das eigentliche Problem ist die Frage "Wie übertrage ich die Daten sicher und authentifiziert zum Server ?"
Nun, hier gibt es zwar Verfahren die auf rein symmetrischen Verschlüsselungen und Hashfunktionen aufbauen können, aber bisher sind bei all diesen Verfahren Schwachstellen entdeckt worden.
Die beste Wahl wären also Verfahren die auf asymmetrischen Algorithmen basieren, zB. dem Diffie Hellmann = DH Schlüsselaustausch und ebenso verschiedene Verfahren der digitalen Signaturen, zB. ElGamal, DSA usw.
Ein als enorm sicher anerkanntes Standardverfahren wäre SRP = Secure Remote Protocoll/Passwort. Dieses basiert auf einem verkürzten DH Schlüsselaustasuch mit mutualer Authentifikation.
Wie man sieht wird's schnell komplexer ein anerkannt sicheres Verfahren auszuwählen und aufzubauen.

Man kann nicht mal eben schnell eine einfache Passwortverwaltung ohne großartige Kenntnisse aufbauen. Alles was daran vorbeigeht ist genausogut wie gar kein Schutzsystem oder nur sogut wie eine "Tarnen und Täuschen" Lösung.

Denoch kann die Anwendung von Kryptographie an obigen Szenarien vorbei einiges an "Schutz" bieten. Man muß sich aber immer vor Augen halten das die tatsächlich erreichbare Sicherheit nur ein Bruch-Bruch-Bruchteil der möglichen Sicherheit beträgt. Ein Angreifer wird statt 0 Sekunden in einem ungeschützten System, ca. 3 Wochen in einem solch schlecht gesicherten System zu etwa 1 Million Jahren in einem gut gesicherten System, zum Eindringen benötigen.
Der Aufwand des Software Entwicklers für ungeschütze System beträgt 0 Sekunden, für untaugliche Systeme ca. 1 Woche und für sichere Systeme nur 3 Wochen länger. Der letzte Fall setzt die Andwendung von fertigen Komponenten vorraus und zeigt das der Mehrgewinn an Sicherheit enorm sein wird.

Ich empfehle immer den Schutz auf die eigentlichen Daten der Software auszudehen. Dies ist der einfachste und zugleich universell sicherste Weg. Ein Angreifer will primär die Daten der Benutzer und Software erlangen, und diese lassen sich durch ein gutes Passwort und kleiner aber leistungsfähiger Verschlüsselungen absichern.

Eine Eigenentwicklung von Verschlüsselungsalgorithmen ist im Grunde Idiotie, mal den Fall des Lernes aussen vor gelassen. Erstens gibt es viele fertige Bibliotheken und Sourcen im WEB die die gängigsten Standardverfahren enthalten, und zweitens sind es Standard-Verfahren die durch anerkannte Experten entwickelt und durch andere Experten überprüft wurden. Dabei sind das ganze Gruppen von Mathematikern, Ingeneuren und Technikern die ihr ganzes Leben lang an diesen Problemen arbeiten. Wer glaubt mit simpler XOR Technologie und mit ein paar Aufrufen von Random() selber ein sicheres Verfahren aufbauen zu können der irrt gewaltig. Und nochwas: Sich hier im Forum hinzustellen und zu sagen "Probier doch mal ob du mein Verfahren knacken kannst" ist ziemlich sinnlos. Der Entwickler eines Verfahrens muß schon selber mathematisch fundiert beweisen können das sein Verfahren sicher ist. Wenn sein prohibitäres Verfahren nicht geknackt wurde dann liegt es meistens nur daran das es keiner echt versucht hat, weil es keinen interessiert.

So nachdem ich nun so ausgescheift bin soll denoch die Eingangsfrage gelösst werden, auch wenn man keine sichere Lösung ganz einfach hinbekommen kann. Ich möchte hier also eine kleine Lösung vorstellen die besser als garnichts ist:

Delphi-Quellcode:

uses DECUtil, Cipher, Hash, Classes, INIFiles;

const
  sMasterKey: String = 'Secret Key';

procedure SaveUserPassword(const UserName, UserKey: String);
var
  Salt, Digest, UserID: String;
  I: Integer;
begin
// 1.)
  Randomize;
  SetLength(Salt, 16);
  for I := 1 to 16 do Salt[I] := Char(Random(256));
// 2.)
  UserID := THash_SHA1.CalcString(sMasterKey + UserName, nil, fmtHEX);
  Digest := Salt + THash_SHA1.CalcString(Salt + UserName + UserKey, nil, fmtCOPY);
  Digest := StrToFormat(PChar(Digest), Length(Digest), fmtHEX);
// 3.) 
  with TiniFile.Create(ChangeFileExt(ParamStr(0), '.ini')) do
  try
    WriteString('Password', UserID, Digest);
  finally
    Free;
  end;
end;

function CheckPassword(const UserName, UserKey: String): Boolean;
var
  UserID,Digest,Salt: String;
begin
// 4.)
  UserID := THash_SHA1.CalcString(sMasterKey + UserName, nil, fmtHEX);  
// 5.)
  with TIniFile.Create(ChangeFileExt(ParamStr(0), '.ini')) do
  try
    Digest := ReadString('Password', UserID, '');
  finally
    Free;
  end;
// 6.)
  Digest := FormatToStr(PChar(Digest), -1, fmtHEX);
// 7.)
  Salt := Copy(Digest, 1, 16);
  Delete(Digest, 1, 16);
// 8.)  
  Result := THast_SHA1.CalcString(Salt + UserName + UserKey, nil, fmtCOPY) = Digest;
end;

Im obigen Code wird eine secure Hash Funktion = SHA1 als Einweg Konvertierung benutzt. Mit dieser Methode kann man also ein Login-basiertes System aufbauen. Hie nun die einzelenen Schritte:

Funktion SaveUserPassword() speichert ein eigegebenes Benutzerpasswort in einer INI Datei ab.

1.) Es wird ein 16 Bytes langer Zufallswert erzeugt = Salt. Dieser Wert verhindert das man Wörterbuch-Angriffe auf den UserKey durchführen kann.
2.) Es wird UserID berechnet um den UserName abzusichern. Der Benutzer muß also exakt seinen Namen + Passwort im Login Dialog eingeben. Einem Angreifer wird es so erschwert zu einem bekannten Benutzer Namen die INI Datei zu fälschen. Desweiteren wird nun aus dem Salt + UserName + UserKey die "Prüfsumme" zum Benutzer berechnet. Hierist es WICHTIG zu beachten das man den UserName mit in die Berechnung einfließen lässt. So wird sichergestellt das der Benutzer Name wie das Benutzer Passwort ein Sicherheitsfaktor wird, und somit ebenfalls beide bekannt sein muß.
Anschließend wird er benutze Zufallswert und der Digest als ein einzigster String in eine Hexadezimale Darstellung konvertiert, damit die INI diese Daten auch speichern kann.
3.) die so erzeugten Daten werden in die Ini gespeichert.

Funktion CheckUserPassword() überprüft einen UserName + UserKey aus der Ini Datei.

4.) wieder berechnen wir unseren UserID unter dem die "Prüfsumme" gespeichert wurde.
5.) wir laden die Prüfsumme aus der Ini
6.) die Prüfsumme wird aus der Hexadezimalen Darstellung in deren binäre Repräsentation konvertiert
6.) wir extrahieren den Zufallswert damit wir exakt die gleiche Berechnung wir bei 2.) nachvollziehen können.
7.) wir berechnen nun wiederum aus dem Salt + UserName + UserKey unsere Prüfsumme un vergleichen sie mit der gespeicherten.

Obiges Verfahren ist auf einbruchsicheren Servern sicher. Auf lokalen Systemen würde der Angreifer als erstes die Sofwtare analysieren und den Wert in sMasterKey ermitteln. Dies dürfte relativ einfach sein für einen erfahrenen Angreifer. Nachdem er diesen Wert hat kann er schonmal zu einem Benutzernamen den Eintrag in der INI Datei ermitteln. Das MasterKey ist also in Wirklichkeit nur eine "Tarnen & Täsuchen" Methode und nicht wesentlich sicherer als gar kein Schutz. Nachdem er diesen Wert hat wird's nun schon wesentlich schwieriger für den Angreifer. Falls er KEINEN Benutzernamen hat so müsste er eine Brute Force Suche starten die den UserName UND UserKey ermittelt. Da aber in unserem Verfahren der Salt mit 16 Bytes = 128 Bits enthalten ist stellt die eine Suche im Heuhafen dar. Der Salt stellt also ein gewaltiger Sicherheitsfaktor dar der eine Brute Force Suche fast unmöglich macht.
Hat der Angreifer dagegen einen bekannten Usernamen, kann er nun den INI Eintrag finden in dem die Prüfsumme steht. Desweiteren kann er nun selber einen Salt erzeugen, den Benutzernamen benutzen und sein eigenes Passwort um seine EIGENE Prüfsumme statt der des Benutzers in der INI zu speichern. Schwups, der Angreifer hat sich einen regulären Account gehackt. Dieser Angriff ist mit KEINER auf reiner Software basierten Methode in unserem Szenario zu umgehen !!

Ok, in den obigen Betrachtungen wurde ein simpler Patch der Software bei 8.) nicht betrachtet. D.h. modifiziert der Angreifer die Software an Punkt 8.) so das immer TRUE zurückgeliefert wird so hat jeder Benutzer und jedem Passwort Sofortzugriff.

Aus diesem Grunde schlug ich gleich am Anfang des Posting vor das mit dem UserKey eben auch die zugehörigen Benutzerdaten, sprich Datenbanken, Dokumente etc. verschlüsselt werden. Würde man so vorgehen so nutzt nun ein Patch rein garnichts mehr. Auch der Austausch der Schlüssel, wie oben gezeigt, bringt nichts. Damit der Angreifer auch sinnvolle Daten erhält MUSS er nun tatsächlich das Passwort herausfinden !!


Gruß Hagen

[HaJo]

Hallo Hagen,

ist eigentlich eine perfekte Abhandlung des gesamten Themas. Mein Kompliment dafür!
Hut ab!

Gruß
Jochen