DE602005000029T2

DE602005000029T2 - Mehrere Authentifizierungskanäle, mit jeweils mehreren Authentifizierungmodi

Info

Publication number: DE602005000029T2
Application number: DE602005000029T
Authority: DE
Inventors: Scott A. UT 84653 Isaacson; Alexander Y. UT 84065 Danoyan
Original assignee: Novell Inc
Current assignee: Micro Focus Software Inc
Priority date: 2004-03-23
Filing date: 2005-02-14
Publication date: 2006-12-28
Anticipated expiration: 2025-02-15
Also published as: US20050108579A1; EP1585285A1; EP1585285B1; US7321972B2; DE602005000029D1

Description

VERWANDTE ANMELDUNGSDATEN
Diese Patentanmeldung ist mit unseren US-Patentanmeldung Serien-Nr. 10/061,911 mit dem Titel „Authentication Cache in a Distributed Network Environment" eingereicht am 1. Februar 2002 und mit US-Patentanmeldung Serien-Nr. 10/061,895 mit dem Titel „Authentication on Demand in a Distributed Network Environment" eingereicht am 1. Februar 2002 verwandt.
BEREICH DER ERFINDUNG
Diese Erfindung betrifft Netzwerkzugänge und im Speziellen das Bereitstellen eines Weges zur Unterstützung neuer Hashalgorithmen beim Authentifizieren eines Benutzers an ein Netzwerk.
ALLGEMEINER STAND DER TECHNIK
Die Möglichkeit, auf Informationen über ein Netzwerk zuzugreifen, war für die meisten Benutzer ein Segen. Die Tatsache, dass ein Benutzer auf gewünschte Informationen von einem entfernten Standort (möglicherweise sogar an einem Standort, den der Benutzer physisch nicht lokalisieren oder erreichen kann) zugreifen kann, brachte für viele Vorteile.
Es ist jedoch noch immer wichtig, dass der Benutzer, der auf die Ressource zugreift, ein berechtigter Nutzer ist. Aus diesem Grund müssen sich Benutzer in das Netzwerk einloggen und sich authentifizieren. Wenn sie sich gegenüber dem Netzwerk nicht richtig identifizieren können, wird ihnen der Zugriff auf die Netzwerkressourcen verweigert. Diese Situation tritt ein, wenn die Authentifizierung über das Common Internet File System (CIFS) verwendet wird und wird in der Novell Network Attached Software Appliance und den Novell Branch Office Produkten verdeutlicht.
Ursprünglich war der Server, der die Authentifizierung durchführte, auch der Server, der die für den Benutzer interessanten Ressourcen speicherte. Diese Situation wird durch 1 verdeutlicht. Der Benutzer bedient den Client oder die Benutzer-Workstation 105. Der Client 105 kann jede Art von Computersystem sein: Desktop, Laptop, Thin Client, nicht intelligentes Endgerät, Personal Digital Assistant (PDA) und so weiter. Der Client 105 beinhaltet die für seinen Aufbau passenden Komponenten. Wenn der Client 105 zum Beispiel ein Desktop-Computer ist, dann beinhaltet der Client 105 wie gezeigt den Computer 110, den Bildschirm 115, die Tastatur 120 und die Maus 125. Der Computer beinhaltet eine zentrale Verarbeitungseinheit (CPU), einen Speicher und andere passende Elemente. Andere Komponenten des Client 105 wie beispielsweise ein Drucker können vorhanden sein. Der Fachmann wird andere Variationen des Client 105 erkennen.
Der Client 105 berechnet ein Hash des Benutzerpassworts durch Anwenden eines Hashalgorithmus auf das Passwort. Durch Hashen des Benutzerpassworts gibt es keine Bedenken, dass das Benutzerpasswort „ins Blaue" gesendet wird, wo es abgefangen werden kann. Der Client 105 kontaktiert dann den Server 130 über das Netzwerk 135. Das Netzwerk 135 kann jede Art der Netzwerkverbindung zwischen dem Client 105 und dem Server 130 sein. Das Netzwerk 135 kann beispielsweise eine direkte Verbindung zwischen dem Client 105 und dem Server 130, eine verkabelte Netzwerkverbindung (wie Ethernet oder Token-Ring), eine drahtlose Verbindung (wie IEEE 802.11b, IEEE 802.11a, oder Bluetooth) oder jede andere Art der Verbindung sein. Das Clientcomputersystem 105 stellt den Benutzernamen und das gehashte Passwort an den Server 130 bereit. Der Server 130 schlägt den Benutzernamen in der Benutzerliste 140 nach, um das Benutzerklartextpasswort zu bestimmen. Der Server 130 verwendet dann einen Hashalgorithmus (wie die Hashalgorithmen 145, 150 oder 155), um das Klartextpasswort zu hashen. (Welcher Hashalgorithmus verwendet wird, ist abhängig von dem Clientcomputersystem 105, da verschiedene Computer verschiedene Algorithmen verwenden können.) Der Server 130 vergleicht dann die gehashten Passwörter. Wenn sie übereinstimmen, ist der Benutzer authentifiziert und Zugriff auf die Ressourcen wie Ressource 160 wird erteilt.
Eine Variation dieses Ansatzes trennt die Verantwortlichkeit für die Authentifizierung von der Verantwortlichkeit für das Speichern der Ressourcen. Diese Situation wird in 2 verdeutlicht. In 2 kontaktiert der Benutzer den Anwendungsserver 130 von Client 105 aus. Doch anstatt dass der Anwendungsserver 130 für die Authentifikation des Benutzers verantwortlich ist, gibt der Anwendungsserver 130 stattdessen die Verantwortlichkeit für die Authentifikation des Benutzers an den Authentifikationsserver wie einen der Authentifikationsserver 205, 210 oder 215 weiter. (Der Anwendungsserver wählt normalerweise den entsprechenden Authentifikationsserver, der kontaktiert werden soll, basierend auf der Ressource, auf die der Benutzer zuzugreifen versucht, aus.) Unter Verwendung des Authentifikationsservers 205 als Beispiel beinhaltet der Authentifikationsserver eine Benutzerliste 220 und Umsetzungen der Hashalgorithmen 225, 230 und 235 (die den Umsetzungen der Hashalgorithmen 145, 150 und 155 der 1 entsprechen). Die Authentifikationsserver 210 und 215 sind ähnlich angelegt. Der Authentifikationsserver 205 schlägt das Benutzerklartextpasswort basierend auf dem Benutzernamen nach, hasht es und vergleicht die gehashten Passwörter, um den Benutzer zu authentifizieren. Der Authentifikationsserver 205 gibt das Ergebnis dann an den Anwendungsserver 130 zurück, der dann dem Benutzer Zugriff auf die Ressource 160 freigibt oder verweigert abhängig davon, ob die Authentifikation erfolgreich war oder nicht.
Obwohl das Trennen der Authentifikation von dem Anwendungsserver Vorteile bietet, indem die Verantwortlichkeit aufgeteilt wird, hat es auch Nachteile. Ein Nachteil besteht darin, dass, wenn der Authentifikationsserver 205 nicht verfügbar ist, der Anwendungsserver 130 dem Benutzer keinen Zugriff auf die Ressourcen gewähren kann, selbst wenn der Anwendungsserver 130 verfügbar ist. Techniken, die dieses Problem ansprechen, sind in dem verwandten US-Patentanmeldung Serien-Nr. 10/061,911 mit dem Titel „Authentication Cache in a Distributed Network Environment" eingereicht am 1. Februar 2002 und in US-Patentanmeldung Serien-Nr. 10/061,895 mit dem Titel „Authentication on Demand in a Distributed Network Environment" eingereicht am 1. Februar 2002 beschrieben.
Ein weiteres Problem besteht darin, dass jeder Authentifikationsserver alle möglichen Hashalgorithmen kennen muss, die von dem Client verwendet werden könnten. Wenn ein Client verfügbar wird, der einen neuen Hashalgorithmus verwendet, muss dieser Hashalgorithmus umgesetzt und in jedem der Authentifikationsserver 205, 210 und 215 installiert werden. Das muss manuell erfolgen: es gibt keinen Mechanismus zum Automatisieren der Entwicklung des Hashalgorithmus. Und es ist für gewöhnlich nicht möglich, den Hashalgorithmus nur einmal umzusetzen und ihn auf jedem Authentifikationsserver zu installieren: Jeder Authentifikationsserver hat eine verschiedene Hardware- /Softwareumgebung, die spezialisierte Bemühungen zum Umsetzen des Hashalgorithmus in den Umgebungen erfordert. Da die Anzahl der verschiedenen Hashalgorithmen zunimmt, wird es zunehmend komplexer sicherzustellen, dass jeder Authentifikationsserver eine richtige Umsetzung jedes Hashalgorithmus hat: die Anzahl der Umsetzungen steigt exponential an.
Demzufolge gibt es einen Bedarf an einem Weg zum Durchführen der Authentifikation mittels eines Authentifikationsservers unter Vermeidung der exponentialen Komplexität bei der Umsetzung der Hashalgorithmen für jeden Authentifikationsserver, um diese und andere Probleme im Zusammenhang mit dem Stand der Technik anzugehen.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung zum Durchführen von Authentifikation gemäß den folgenden Ansprüchen. Ein Anwendungsserver beinhaltet eine Benutzerliste, die einen Benutzernamen und ein zugewiesenes Klartextpasswort aufweist. Der Anwendungsserver kann das Klartextpasswort zu einem Klartextpasswort authentifizieren, das auf einen Authentifikationsserver gespeichert ist. Der Anwendungsserver kann das Klartextpasswort hashen, es mit einem von einer Benutzerworkstation empfangenen gehashten Passwort vergleichen und ein Ergebnis zu der Workstation zurücksenden.
Die vorangegangenen und andere Eigenschaften, Aufgaben und Vorteile der Erfindung werden durch die folgende detaillierte Beschreibung deutlicher, die Bezug auf die dazugehörigen Zeichnungen nimmt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein System des Stands der Technik zum Authentifizieren eines Benutzers mittels eines Anwendungsserver.
2 zeigt ein System des Stands der Technik zum Authentifizieren eines Benutzers mittels eines Anwendungsserver und eines Authentifikationsservers.
3 zeigt ein System mit einem Authentifikationsserver, der angelegt ist, ein Klartextpasswort zu authentifizieren, und einem Anwendungsserver, der angelegt ist, ein gehashtes Benutzerpasswort gemäß einer Ausführungsform der Erfindung zu authentifizieren.
4 zeigt die Informationen, die zwischen der Workstation, dem Anwendungsserver und dem Authentifikationsserver der 3 gemäß einer Ausführungsform der Erfindung übertragen werden.
5 zeigt Details des Anwendungsservers der 3 gemäß einer Ausführungsform der Erfindung.
6 zeigt den Anwendungsserver der 3, der ein Klartextpasswort in der Benutzerliste gemäß einer Ausführungsform der Erfindung aktualisiert.
7A–7C zeigt ein Ablaufdiagramm des Verfahrens zum Authentifizieren eines Benutzers, der das System der 3 gemäß einer Ausführungsform der Erfindung verwendet.
8 zeigt ein Ablaufdiagramm des Verfahrens zum Unterstützen der Authentifikation von einer Workstation in dem System der 3 gemäß einer Ausführungsform der Erfindung.
9A–9B zeigt ein Ablaufdiagramm zum Aktualisieren des Klartextpassworts, das zur Authentifikation in dem System der 3 verwendet wird, gemäß einer Ausführungsform der Erfindung.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Um zu vermeiden, dass eine große Anzahl von Hashalgorithmus-Umsetzungen in den Authentifikationsservern installiert werden muss, verwenden die Ausführungsformen der Erfindung die Authentifikationsserver zum Prüfen, dass das Klartextpasswort auf dem Anwendungsserver korrekt ist, lassen den Anwendungsserver jedoch den Hash des Klartextpassworts berechnen. In diesen Ausführungsformen ist nur eine Umsetzung des Hashalgorithmus erforderlich: für den Anwendungsserver. Doch die Authentifikation wird trotzdem zu dem Authentifikationsserver verschoben, da der Anwendungsserver nicht wissen kann, ob er das korrekte Klartextpasswort zur Verwendung im Hash hat. Zur Verdeutlichung wird das Verfahren, das durch den Authentifikationsserver durchgeführt wird (Prüfen, dass das auf dem Anwendungsserver gespeicherte Klartextpasswort korrekt ist), als Passwortauthentifikation bezeichnet; das Verfahren, das durch den Anwendungsserver ausgeführt wird (Prüfen, dass das von dem Client empfangene gehashte Passwort mit einem Hash des Klartextpassworts übereinstimmt), wird als Benutzerauthentifikation bezeichnet. Wo diese Begriffe nicht verwendet werden, sollte aus dem Zusammenhang hervorgehen, ob das Passwort oder der Benutzer authentifiziert werden.
In 3 kommuniziert der Client 105 (auch als Workstation bezeichnet) mit dem Anwendungsserver 130 über das Netzwerk 135. Beispiele für mögliche Konfigurationen des Client 105 beinhalten unter anderem Computer, die unter Windows^® XP laufen, Computer, die unter Windows^® 98 mit einem NetWare^® Client laufen und einen Mac^® Computer. (Windows ist entweder ein eingetragenes Markenzeichen oder ein Markenzeichen der Microsoft Corporation in den Vereinigten Staaten und/oder anderen Ländern; NetWare ist ein eingetragenes Markenzeichen der Novell, Inc. in den Vereinigten Staaten und anderen Ländern; Mac ist ein eingetragenes Markenzeichen der Apple Computer, Inc. in den Vereinigten Staaten und anderen Ländern.) Ein Beispiel einer möglichen Konfiguration des Anwendungsservers 130 ist, ohne auf diese Konfiguration beschränkt zu sein, ein NetWare 6,5 Server mit Native File Access wie NetWare Core Protocol (NCP), CIFS und AppleTalk^® Filing Protocol (AFP) unter anderen. (AppleTalk ist ein registriertes Markenzeichen der Apple Computer, Inc. in den Vereinigten Staaten und anderen Ländern.) Wie zuvor stellt der Client 105 dem Anwendungsserver 130 den Benutzernamen (auch als Benutzeridentifizierer, Benutzeridentifikation oder Einlogidentifikation unter anderen Begriffen bezeichnet) und eine gehashte Form des Benutzerpassworts bereit. Der Client 105 kann jeden gewünschten Hashalgorithmus verwenden. Oft ist auf dem Client 105 nur ein Hashalgorithmus installiert, aber der Fachmann wird auch erkennen, dass der Client 105 mehr als einen installierten Hashalgorithmus aufweisen kann. Wenn auf dem Client 105 mehr als ein Hashalgorithmus installiert ist, kann der Client 105 einen verfügbaren Hashalgorithmus verwenden.
Der Anwendungsserver 130 schlägt dann das Klartextpasswort, das mit dem Benutzernamen in der Benutzerliste 140 verbunden ist, nach. Der Anwendungsserver 130 stellt dem Authentifikationsserver 205 den Benutzernamen und das Klartextpasswort über einen sicheren Kanal bei dem Versuch, die Passwortauthentifikation durchzuführen, bereit. Der Vorgang der Passwortauthentifikation kann mittels jedes gewünschten Protokolls durchgeführt werden. Zum Beispiel kann die Lightweight Directory Access Protocol (LDAP) Bind-Operation zum Authentifizieren des Klartextpassworts verwendet werden.
Der Authentifikationsserver 205 verwendet den Benutzernamen, um auf die Benutzerliste 220 zuzugreifen, um das mit dem Benutzernamen verbundene Passwort zu bestimmen. Der Authentifikationsserver 205 vergleicht dann das verbundene Klartextpasswort mit dem von dem Anwendungsserver 130 bereitgestellten Klartextpasswort.
Wenn die Klartextpasswörter übereinstimmen, ist der Authentifikationsversuch erfolgreich; wenn nicht schlägt der Authentifikationsversuch fehl.
Wenn der Passwortauthentifikationsversuch fehlschlägt, sendet der Anwendungsserver 130 an die Workstation 105 das Fehlschlagen der Authentifikation zurück. Normalerweise zeigt der Anwendungsserver 130 den Grund für das Fehlschlagen nicht an; der Anwendungsserver 130 zeigt einfach ein Fehlschlagen an. Doch der Fachmann wird erkennen, dass der Anwendungsserver 130 anzeigen kann, dass das Problem ein nicht übereinstimmendes Passwort war, und somit dem Benutzer die Möglichkeit anzeigen kann, dass sein Passwort, so wie es in der Benutzerliste 140 auf dem Anwendungsserver 130 gespeichert ist, nicht mehr aktuell ist.
Wenn der Vorgang des Passwortauthentifikationsversuchs erfolgreich ist, versucht der Anwendungsserver 130 danach, das Benutzerpasswort zu validieren und somit den Benutzerauthentifikationsvorgang zu beenden. Der Anwendungsserver 130 bestimmt, welcher Hashalgorithmus/welche Hashalgorithmen der Client 105 verwendet haben könnte, und verwendet jeden der Reihe nach, um das aus der Benutzerliste 140 bezogene Klartextpasswort zu hashen. Einige mögliche Hashalgorithmen beinhalten, ohne eine vollständige Liste darzustellen: Common Internet File System/Server Message Block (CIFS/SMB), Message Digest 4 (MD4), Diffie Hellman und Secure Hash Algorithm 1 (SHA1). Nach dem Hashen des Klartextpassworts unter Verwendung jedes Hashalgorithmus der Reihe nach vergleicht der Anwendungsserver 130 die gehashten Passwörter. Wenn die gehashten Passwörter übereinstimmen (unter Verwendung der Hashalgorithmen, die mit dem Client 105 verbunden sind), dann ist die Benutzerauthentifikation vollständig und dem Benutzer kann Zugriff auf die Ressource 160 gewährt werden. Andernfalls schlägt die Benutzeridentifikation fehl und dem Benutzer wird der Zugriff verweigert.
3 beschreibt den Anwendungsserver 130 und den Authentifikationsserver 205, die Klartextversionen des Benutzerpassworts kommunizieren. Wie oben erwähnt erfordert dieser Austausch eine sichere Verbindung zwischen dem Anwendungsserver 130 und dem Authentifikationsserver 205. Wenn sich beide Server an physikalisch sicheren Standorten befinden und die Verbindung zwischen ihnen geschützt werden kann, dann können sie ohne das Verschlüsseln geteilter Daten kommunizieren. Der Fachmann wird jedoch erkennen, dass der Anwendungsserver 130 und der Authentifikationsserver 205 unter Verwendung sicherer Mittel kommunizieren können. Zum Beispiel könne der Anwendungsserver 130 und der Authentifikationsserver 205 mittels Secure Sockets Layer (SSL) kommunizieren. Oder der Anwendungsserver 130 kann die Klartextversion des Benutzerpassworts hashen und nur die gehashte Version an den Authentifikationsserver 205 kommunizieren. Angenommen der Authentifikationsserver 205 verwendet den gleichen Hashalgorithmus wie der von dem Anwendungsserver 130 verwendete, dann kann der Authentifikationsserver 205 das Benutzerpasswort auf dem Anwendungsserver 130 authentifizieren, ohne dass das Klartextpasswort möglichem Abfangen ausgesetzt wird. Oder der Anwendungsserver 130 und der Authentifikationsserver 205 können eine Art der Verschlüsselung verwenden, so dass der Anwendungsserver 130 das Benutzerpasswort verschlüsseln kann und der Authentifikationsserver 205 kann es entschlüsseln, bevor der Authentifikationsvorgang beendet ist.
Ein Punkt, der noch nicht beschrieben wurde, ist, wie die verschiedenen Benutzerlisten aufgebaut werden. Anfänglich werden die Benutzerlisten 220, die in dem Authentifikationsserver 205 gespeichert sind, normalerweise von einem Administrator erzeugt: wenn jeder Konten für sich selbst erzeugen könnte, dann wäre die Sicherheit sehr schwach. Doch der Fachmann wird erkennen, dass die Benutzerliste 220 auf andere Arten gefüllt werden kann. Der Administrator kann zum Beispiel eine Masterliste der Benutzer und anfänglichen Passwörter anderswo erstellen und die Einträge werden in der Benutzerliste 220 nach Bedarf generiert.
Der Administrator füllt normalerweise nicht die Benutzerliste 140, die in dem Anwendungsserver 130 gespeichert ist. Stattdessen wird die Benutzerliste 140 aus anderen Quellen gefüllt. Wie in der verwandten US-Patentanmeldung Serien-Nr. 10/061,911 mit dem Titel „Authentication Cache in a Distributed Network Environment" eingereicht am 1. Februar 2002 und in dem verwandten US-Patentanmeldung Serien-Nr. 10/061,895 mit dem Titel „Authentication on Demand in a Distributed Network Environment" eingereicht am 1. Februar 2002 beschrieben, kann der Anwendungsserver 130 Informationen für die Benutzerliste aus dem Authentifikationsserver 205 anfordern. In dieser Ausführungsform kann das Klartextpasswort von dem Authentifikationsserver 205 über einen sicheren Kanal oder durch eine Art der Verschlüsselung so empfangen werden, dass das Klartextpasswort vor Abfangen geschützt ist. Eine andere Möglichkeit besteht darin, dass, wenn sich der Benutzer zum ersten Mal in den Anwendungsserver 130 einloggt, der Anwendungsserver 130 den Benutzer nach einer Klartextversion seines Passworts fragt. (Wieder wird das Klartextpasswort anfänglich vorzugsweise von dem Client 105 an den Anwendungsserver 130 unter Verwendung einer sicheren Verbindung oder verschlüsselt gesendet, um mögliches Abfangen durch Dritte zu verhindern.) Der Anwendungsserver 130 kann dann versuchen, die von dem Benutzer bereitgestellt Version des Passworts zu authentifizieren.
4 zeigt die Informationen, die zwischen der Workstation, dem Anwendungsserver und dem Authentifikationsserver der 3 gemäß einer Ausführungsform der Erfindung übertragen werden. Nachricht 405 ist die erste Nachricht, die von dem Client 105 an den Anwendungsserver 130 gesendet wird. Die Nachricht 405 beinhaltet den Benutzernamen (User1) und das Passwort als durch den Client 105 gehashtes (HPwd1). Nach Empfangen der Nachricht 405 bestimmt der Anwendungsserver 130 das Klartextpasswort, das mit dem Benutzernamen innerhalb der auf dem Anwendungsserver 130 gespeicherten Benutzerliste verbunden ist. Der Anwendungsserver 130 sendet dann den Benutzernamen (User1) und das verbundene Klartextpasswort (Pwd1) an den Authentifikationsserver 205 wie durch Nachricht 410 gezeigt. Wie oben beschrieben sollte, da das Klartextpasswort kommuniziert wird, ein sicherer Kommunikationskanal, eine Verschlüsselung oder eine andere Art zum Schutz des Klartextpassworts vor Abfangen verwendet werden. Der Authentifikationsserver 205 sendet die Nachricht 415 zurück, die anzeigt (Ja/Nein), ob das mit dem Benutzernamen in der Benutzerliste, die auf dem Authentifikationsserver 205 gespeichert ist, verbundene Klartextpasswort mit dem von dem Anwendungsserver 130 bereitgestellten Klartextpasswort übereinstimmt. Angenommen der Passwortauthentifikationsvorgang ist erfolgreich, dann vergleicht der Anwendungsserver 130 die gehashte Version des Klartextpassworts mit dem von dem Client 105 bereitgestellten gehashten Passwort (angezeigt als „Nachricht" 420). Am Ende antwortet der Anwendungsserver 130 mit der Nachricht 425, die anzeigt (Ja/Nein), ob der Benutzer authentifiziert ist.
5 zeigt Details des Anwendungsservers der 3, der (in Software, Firmware, Hardware oder einer Kombination daraus) angelegt ist, gemäß einer Ausführungsform der Erfindung zu arbeiten. Der Anwendungsserver 130 beinhaltet den Clientdienstprovider 505, den Komparator 510, den Authentifikator 515 und die Tabelle 520. Der Clientdienstprovider 505 arbeitet als Schnittstelle für den Client. Der Clientdienstprovider 505 empfängt den Benutzernamen/das gehashte Passwort von der Workstation und leitet den Benutzernamen an den Authentifikator 515 weiter. er Authentifikator 515 verwendet den Benutzernamen, um das Klartextpasswort aus der Benutzerliste zu ermitteln. Der Authentifikator 515 leitet dann den Benutzernamen/das Klartextpasswort an den Authentifikationsserver weiter. Wie oben beschrieben wird das Klartextpasswort vorzugsweise mittels eines sicheren Kommunikationskanals, in verschlüsselter Form oder auf andere Art vor Abfangen geschützt weitergeleitet. Der Authentifikator 515 empfängt das Ergebnis der Passwortauthentifikation von dem Authentifikationsserver (wie oben beschrieben).
Wenn das Klartextpasswort authentifiziert ist, hasht der Clientdienstprovider 505 das Klartextpasswort mittels Hashalgorithmen, die mit dem Client verbunden sind. Der Clientdienstprovider 505 verwendet die Tabelle 520, die eine Liste darüber speichert, welche Hashalgorithmen von welcher Workstation verwendet werden können. Wie oben mit Bezug auf 3 beschrieben kann ein Clientcomputersystem mehr als einen installierten Hashalgorithmus aufweisen. Die Tabelle 520 listet jeden Hashalgorithmus zusammen mit allen Workstations auf, die diesen Algorithmus verwenden. Zum Beispiel wird gemäß Eintrag 525 der Hashalgorithmus HA1 von den Workstations 1 und 2 verwendet, wohingegen der Hashalgorithmus HA3 von den Workstations 2 und 3 verwendet wird. Obwohl Tabelle 520 zeigt, welche Workstations mit welchen Hashalgorithmen verbunden sind, wird der Fachmann erkennen, dass es andere Möglichkeiten gibt, diese Informationen zu organisieren. Tabelle 520 kann die Daten zum Beispiel nach Workstations sortieren, indem sie auflistet, welche Hashalgorithmen von bestimmten Workstations verwendet werden. Oder jede Workstation könnte ein Objekt in einer Container-Hierarchie sein und die verbundenen Hashalgorithmen sind Eigenschaften des Objekts.
Wenn der Clientdienstprovider 505 das Klartextpasswort gehasht hat, leitet der Clientdienstprovider 505 das gehashte Klartextpasswort und das von der Workstation empfangene gehashte Passwort an den Komparator 510 weiter. Der Komparator 510 sendet das Ergebnis des Vergleichs zurück. Wenn der Komparator 510 anzeigt, dass die zwei gehashten Passwörter übereinstimmen, sendet der Clientdienstprovider 505 an den Client zurück, dass der Benutzer authentifiziert ist. Andernfalls prüft der Clientdienstprovider 505, ob ein anderer Hashalgorithmus mit den Client in Tabelle 520 verbunden ist, um diesen zu versuchen. Wenn es einen anderen Hashalgorithmus zum Versuchen gibt, hasht der Clientdienstprovider 505 das Klartextpasswort mit dem nächsten Hashalgorithmus und leitet das neue gehashte Klartextpasswort und das empfangene gehashte Passwort an den Komparator 510 für einen erneuten Versuch weiter. Der Vorgang wiederholt sich, bis der Komparator 510 einen erfolgreichen Vergleich anzeigt (in dem Fall ist der Benutzer authentifiziert) oder bis es keine weiteren Hashalgorithmen zum Versuchen mehr gibt (in dem Fall ist der Benutzer nicht authentifiziert).
Da der Clientdienstprovider 505 und der Authentifikator 515 beide mit anderen Maschinen kommunizieren, verwenden beide Empfänger/Sender 530. Der Empfänger/Sender 530 ist für das Senden und Empfangen von Kommunikation im Auftrag des Anwendungsservers 130 (und aller Komponenten innerhalb des Anwendungsservers 130) verantwortlich.
6 zeigt den Anwendungsserver 130 der 3, der ein Klartextpasswort in der Benutzerliste gemäß einer Ausführungsform der Erfindung aktualisiert. Gute Sicherheitsverfahren sprechen gegen das Beibehalten desselben Passworts für längere Zeiträume, was bedeutet, dass der Benutzer sein Passwort periodisch ändern sollte. In 6 versucht der Benutzer, sich durch den Anwendungsserver 130 auf dem Authentifikationsserver 205 einzuloggen. Der Benutzer stellt seinen Benutzernamen bereit, das aktuelle Passwort und das neue Passwort wie durch Nachricht 605 gezeigt. Da das aktuelle und das neue Passwort als Klartext gesendet werden, wird die Nachricht 605 auf sichere Art gesendet: beispielsweise über einen sicheren Kommunikationskanal oder als verschlüsselte Nachricht. Der Anwendungsserver 130 leitet diese Nachricht an den Authentifikationsserver 205 wie durch Nachricht 610 gezeigt weiter. Wiederum wird auch die Nachricht 610 gesichert, da Klartextpasswörter gesendet werden. Der Authentifikationsserver 205 authentifiziert das aktuelle Passwort des Benutzers durch Vergleichen des mit dem Benutzernamen in der Benutzerliste 220 verbundenen Passworts mit dem bereitgestellten aktuellen Passwort. Angenommen das aktuelle Passwort ist authentifiziert, dann ersetzt der Authentifizierungsserver 205 das aktuelle Passwort wie gezeigt durch das neue Passwort. Und sobald der Authentifizierungsserver 205 an den Anwendungsserver 130 eine Anzeige zurückgesendet hat, dass der Benutzer authentifiziert wurde, ersetzt der Replacer 615 in der Benutzerliste 140 auf dem Anwendungsserver 130 das aktuelle Passwort durch das neue Passwort.
Obwohl 6 zeigt, dass das Passwort sowohl auf dem Authentifizierungsserver 205 als auch auf dem Anwendungsserver in etwa gleichzeitig ersetzt wird, wird der Fachmann erkennen, dass das nicht erforderlich ist. Der Benutzer kann zum Beispiel ein Administrationswerkzeug verwenden, um das Passwort direkt auf dem Authentifikationsserver 205 zu ändern, ohne über den Anwendungsserver 130 zu gehen. Wenn dann der Benutzer versucht, auf die Ressourcen auf dem Anwendungsserver 130 zuzugreifen, kann der Benutzer das aktuelle Passwort auf dem Anwendungsserver 130 ändern. Doch durch den in 6 gezeigten Ansatz muss der Benutzer das neue Passwort nur einmal bereitstellen, wodurch das Verfahren vereinfacht wird.
7A–7C zeigt ein Ablaufdiagramm des Verfahrens zum Authentifizieren eines Benutzers, der das System der 3 gemäß einer Ausführungsform der Erfindung verwendet. In 7A bei Schritt 705 empfängt der Anwendungsserver 130 von der Workstation 105 einen Benutzernamen und ein gehashtes Passwort. Bei Schritt 710 greift der Anwendungsserver auf die Benutzerliste 140 zu. Bei Schritt 715 prüft der Anwendungsserver um zu sehen, ob der Benutzername in der Benutzerliste ist. Wenn nicht fordert der Anwendungsserver bei Schritt 720 von dem Benutzer eine Klartextversion des Passworts an, die bei Schritt 725 in der Benutzerliste gespeichert wird. Normalerweise wird wie oben mit Bezug auf 3 beschrieben die Klartextversion des Passworts von dem Benutzer über einen sicheren Kanal empfangen.
Sobald der Benutzername in der Benutzerliste gefunden wurde, greift der Anwendungsserver bei Schritt 730 (7B) auf das verbundene Klartextpasswort zu. Bei Schritt 735 wählt der Anwendungsserver einen Authentifikationsserver aus. Bei Schritt 740 versucht der Anwendungsserver das Passwort unter Verwendung des ausgewählten Authentifikationsservers zu authentifizieren. Bei Schritt 745 bestimmt der Anwendungsserver, ob der Passwortauthentifikationsvorgang erfolgreich war.
Wenn der Passwortauthentifikationsvorgang erfolgreich war, dann bestimmt der Anwendungsserver in Schritt 750 (7C) den Hashalgorithmes/die Hashalgorithmen, die mit der Workstation verbunden sind. Bei Schritt 755 prüft der Anwendungsserver um zu sehen, ob noch nicht versuchte Hashalgorithmen mit der Workstation verbunden sind. Wenn ja, dann wählt der Anwendungsserver in Schritt 760 einen der noch nicht versuchten Hashalgorithmen aus und hasht die Klartextversion mit dem ausgewählten Klartextalgorithmus. Bei Schritt 765 vergleicht der Anwendungsserver die gehashten Passwörter um zu sehen, ob sie übereinstimmen. Wenn ja berichtet der Anwendungsserver bei Schritt 770 der Workstation 105, dass die Benutzerauthentifikation erfolgreich war. Andernfalls kehrt der Vorgang zu Schritt 755 zurück, um zu sehen, ob es andere Hashalgorithmen zum Versuchen gibt. Letztendlich wenn kein Hashalgorithmus einen übereinstimmenden Hash des Passworts bereitstellt oder wenn der Authentifikationsserver das Passwort nicht authentifizieren konnte (bei Schritt 745 der 7B), dann bereichtet der Anwendungsserver bei Schritt 775 der Workstation über das Fehlschlagen der Authentifikation des Benutzers.
8 zeigt ein Ablaufdiagramm des Verfahrens zum Unterstützen der Authentifikation von einer Workstation in dem System der 3 gemäß einer Ausführungsform der Erfindung. Bei Schritt 805 empfängt der Anwendungsserver 130 einen Identifikator für eine neue Workstation. Bei Schritt 810 bestimmt der Anwendungsserver einen Hashalgorithmus, der von der neuen Workstation verwendet wird. Bei Schritt 815 prüft der Anwendungsserver, um zu sehen, er eine Umsetzung des Hashalgorithmus hat. Wenn nicht wird in Schritt 820 eine Umsetzung des Hashalgorithmus zu dem Anwendungsserver hinzugefügt. Letztendlich wird bei Schritt 825 die neue Workstation mit dem Hashalgorithmus verbunden.
Wie oben mit Bezug auf 3 beschrieben wurde, kann es mehr als einen umgesetzten Hashalgorithmus für eine bestimmte Workstation geben. Diese Möglichkeit wird durch Pfeil 830 unterstützt, der das Wiederholen der Schritte 810–825 für multiple Hashalgorithmen unterstützt.
9A–9B zeigt ein Ablaufdiagramm zum Aktualisieren des Klartextpassworts, das zur Authentifikation in dem System der 3 verwendet wird, gemäß einer Ausführungsform der Erfindung. In 9A empfängt der Anwendungsserver 130 bei Schritt 905 einen Benutzernamen, ein aktuelles Passwort und ein neues Klartextpasswort von der Workstation. Bei Schritt 910 sendet der Anwendungsserver diese Information an den Authentifizierungsserver. Bei Schritt 915 versucht der Authentifizierungsserver, das aktuelle Passwort zu authentifizieren (durch Vergleichen des empfangenen aktuellen Passworts mit dem Passwort, das mit dem Benutzernamen in der Benutzerliste verbunden ist). Bei Schritt 920 prüft das System, um zu sehen, ob der Passwortauthentifikationsvorgang erfolgreich war.
Wenn der Passwortauthentifikationsvorgang erfolgreich war, dann ersetzt der Authentifizierungsserver bei Schritt 925 (9B) das aktuelle Passwort durch das neue Passwort. Bei Schritt 930 berichtet der Authentifikationsserver dem Anwendungsserver, dass das aktuelle Passwort authentifiziert wurde. Bei Schritt 935 ersetzt der Anwendungsserver das aktuelle Passwort in der Benutzerliste des Anwendungsservers durch das neue Passwort. Letztendlich berichtet der Anwendungsserver bei Schritt 940 dem Benutzer, dass der Vorgang der Passwortänderung erfolgreich war.
Wenn andererseits der Vorgang der Passwortauthentifikation fehlgeschlagen ist, dann sendet der Authentifizierungsserver bei Schritt 945 an den Anwendungsserver ein Fehlschlagen der Authentifikation des Passworts zurück. In diesem Fall berichtet der Anwendungsserver dem Benutzer bei Schritt 950 das Fehlschlagen der Änderung des Passworts.
Die folgende Erörterung soll eine kurze, allgemeine Erklärung einer geeigneten Maschine bereitstellen, in der bestimmte Aspekte der Erfindung umgesetzt werden können. Normalerweise beinhaltet die Maschine einen Systembus, an den Prozessoren, Speicher wie beispielsweise Lese-Schreibspeicher (RAM), Nur-Lesespeicher (ROM) oder andere zustandsbewahrende Medien, Speichervorrichtungen, eine Videoschnittstelle und Eingabe-/Ausgabeschnittstellenports angeschlossen sind. Die Maschine kann, zumindest teilweise, durch Eingaben von herkömmlichen Eingabevorrichtungen wie Tastatur, Maus und so weiter ebenso wie durch Anweisungen von einer anderen Maschine, Interaktion mit einer Virtual-Reality-Umgebung (VR), biometrische Rückkopplung oder andere Eingabesignale gesteuert werden. So wie er hierin verwendet wird, soll der Begriff „Maschine" im Allgemeinen eine einzelne Maschine oder ein System kommunikativ gekoppelter Maschinen oder Vorrichtungen, die zusammen arbeiten, umfassen. Exemplarische Maschinen beinhalten Rechnervorrichtungen wie PCs, Workstations, Server, tragbare Computer, Handheld-Vorrichtungen, Telefone, Tablets und so weiter ebenso wie Transportvorrichtungen wie private oder öffentliche Verkehrsmittel wie beispielsweise Autos, Züge, Taxis und so weiter.
Die Maschine kann eingebettete Controller wie programmierbare oder nicht programmierbare logische Vorrichtungen oder Anordnungen, Anwendungsspezifische Integrierte Schaltungen, eingebettete Computer, Smart-Cards und ähnliches beinhalten. Die Maschine kann eine oder mehr Verbindungen zu einer oder mehreren entfernten Maschinen wie über eine Netzwerkschnittstelle, ein Modem oder andere kommunikative Kopplung verwenden. Die Maschinen können über ein physisches und/oder logisches Netzwerk wie ein Intranet, das Internet, Local Area Networks (LANs), Wide Area Networks (WANs) und so weiter miteinander verbunden sein. Der Fachmann wird erkennen, dass Netzwerkkommunikation verschiedene verkabelte und/oder drahtlose Kurzstrecken- oder Langstreckenträger und - protokolle einsetzen kann einschließlich Funkfrequenz (RF), Satellit, Mikrowelle, Institute of Electrical and Electronics Engineers (IEEE) 802.11, Bluetooth, optisch, infrarot, Kabel, Laser und so weiter.
Die Erfindung kann durch Bezug auf oder in Verbindung mit Daten beschrieben werden, die Funktionen, Abläufe, Datenstrukturen, Anwendungsprogramme und so weiter enthalten, was, wenn von einer Maschine aus darauf zugegriffen wird, dazu führt, dass die Maschine Aufgaben ausführt oder abstrakte Datentypen oder Low-Level-Hardware-Zusammenhänge definiert. Verbundene Daten können zum Beispiel im flüchtigen und/oder nichtflüchtigen Speicher gespeichert werden wie beispielsweise RAM, ROM und so weiter oder in anderen Speichervorrichtungen und ihren verbundenen Speichermedien einschließlich Festplatten, Disketten, optische Speicher, Bandlaufwerke, Flash-Speicher, Speicher-Sticks, digitalen Videodisks, biologischen Speichern und so weiter. Verbundene Daten können über Übertragungsumgebungen einschließlich das physische und/oder logische Netzwerk in Form von Paketen, seriellen Daten, parallelen Daten, propagierten Signalen und so weiter und können in komprimiertem oder verschlüsseltem Format verwendet werden. Verbundene Daten können in einer distributiven Umgebung verwendet werden und können lokal und/oder entfernt für Maschinenzugriff gespeichert werden.
Nachdem die Prinzipien der Erfindung mit Bezug auf die dargestellten Ausführungsformen beschrieben und dargestellt wurden, wird erkannt werden, dass die dargestellten Ausführungsformen in Anordnung und Detail verändert werden können, ohne von diesen Prinzipien abzuweichen. Und obwohl sich die vorangegangene Erörterung auf bestimmte Ausführungsformen konzentriert hat, sind andere Ausführungen vorgesehen. Im Speziellen bedeutet das, obwohl hierin Ausdrücke wie „gemäß einer Ausführungsform der Erfindung" oder ähnliche verwendet wurden, sollen sich diese Phrasen allgemein auf Ausführungsmöglichkeiten beziehen und beabsichtigen nicht, die Erfindung auf spezielle Ausführungsanordnungen festzulegen. Mit der Verwendung hierin können sich diese Begriffe auf die gleichen oder unterschiedliche Ausführungsformen beziehen, die in andere Ausführungsformen kombiniert werden können.
Angesichts der breiten Vielfalt der Umsetzungen der hierin beschriebenen Ausführungsformen sind die detaillierte Beschreibung und das dazugehörige Material lediglich für darstellende Zwecke gedacht und sollten nicht als Einschränkung des Geltungsbereichs der Erfindung verstanden werden.

Claims

Anwendungsserver (130), umgesetzt in einem Computer, umfassend: eine Benutzerliste (140), die einen Benutzernamen und ein erstes Klartextpasswort verbunden mit dem Benutzernamen umfasst, einen Authentifikator (515) zum Authentifizieren des ersten Klartextpassworts zu einem zweiten Klartextpasswort in einem Authentifikationsserver, unter Gebrauch des Authentifikationsservers (205), einen Hasher (145, 150, 155), zum Hashen des ersten Klartextpassworts, um ein gehashtes Passwort zu erzeugen, einen Komparator (510), um das gehashte Passwort mit einem empfangenen gehashten Passwort zu vergleichen, und einen Clientdiensteprovider (505), um das empfangene gehashte Passwort von einer Workstation (105) zu empfangen und ein Ergebnis von dem Komparator zu der Workstation zu übertragen.
Anwendungsserver nach Anspruch 1, wobei der Hasher (145) einen Hashalgorithmus (HA₁) verbunden mit der Workstation (105) umfasst.
Anwendungsserver nach Anspruch 2, bei dem der Hasher (150) einen zweiten Hashalgorithmus (HA₂) umfasst, der mit einer zweiten Workstation verbunden ist.
Anwendungsserver nach Anspruch 2, bei dem der Hasher (155) einen zweiten Hashalgorithmus (HA₃) verbunden mit der Workstation (105) umfasst.
Anwendungsserver nach Anspruch 1, bei dem der Clientdiensteprovider (505) betrieben werden kann, um das Klartextpasswort von der Workstation zu empfangen.
Anwendungsserver nach Anspruch 1, bei dem: der Clientdiensteprovider (525) betrieben werden kann, um ein neues Klartextpasswort von der Workstation (105) zu empfangen, und der Anwendungsserver (130) ferner einen Replacer (615) umfasst, um das Klartextpasswort mit dem neuen Klartextpasswort zu ersetzen.
System umfassend: ein Netzwerk (135), eine Workstation (105), die mit dem Netzwerk gekoppelt ist, wobei die Workstation Folgendes umfasst: einen ersten Benutzernamen (User1) und ein erstes Klartextpasswort (Pwd1), und einen ersten Hasher, um das erste Klartextpasswort (Pwd1) zu hashen, um ein erstes gehashtes Passwort (HPwd1) zu erzeugen, einen Authentifikationsserver (205), der mit dem Netzwerk gekoppelt ist, wobei der Authentifikationsserver einen zweiten Benutzernamen (User2) umfasst und ein zweites Klartextpasswort (Pwd2), das mit dem zweiten Benutzernamen verbunden ist, und einen Anwendungsserver (130), der mit dem Netzwerk gekoppelt ist, wobei der Anwendungsserver Folgendes umfasst eine Benutzerliste (140), die einen dritten Benutzernamen (User3) umfasst und ein drittes Klartextpasswort (Pwd3), das mit den dritten Benutzernamen verbunden ist, umfasst, einen Authentifikator (515), um das dritte Klartextpasswort (Pwd3) zu dem zweiten Klartextpasswort (Pwd2) unter Gebrauch des Authentifikationsservers (205) zu authentifizieren, einen zweiten Hasher, um das dritte Klartextpasswort (Pwd3) zu hashen, um ein zweites gehashtes Passwort (HPwd2) zu erzeugen, einen Komparator (510), um das erste gehashte Passwort (HPwd1) mit dem zweiten gehashten Passwort (HPwd2) zu vergleichen, und einen Clientdiensteprovider (515), um das von einer Workstation (105) empfangene gehashte Passwort zu empfangen und ein Ergebnis von dem Komparator zu der Workstation zu übertragen.
System nach Anspruch 7, bei dem: der erste Hasher einen Hashalgorithmus (HA₁) umfasst, und der zweite Hasher den ersten Hashalgorithmus umfasst, wobei der erste Hashalgorithmus mit der Workstation (105) verbunden ist.
System nach Anspruch 8, bei dem der zweite Hasher einen zweiten Hashalgorithmus (HA₂) umfasst, der mit einer zweiten Workstation verbunden ist (105).
System nach Anspruch 7, bei dem: ein Empfänger/Sender (530) betrieben werden kann, um ein neues Klartextpasswort von der Workstation (105) zu empfangen, und der Anwendungsserver ferner einen Replacer (615) umfasst, um das Klartextpasswort mit dem neuen Klartextpasswort zu ersetzen.
System nach Anspruch 10, bei dem der Empfänger/Sender (530) betrieben werden kann, um das neue Klartextpasswort zu dem Authentifikationsserver (205) weiterzugeben.
Verfahren zum Authentifizieren eines Benutzers auf einem Anwendungsserver, umfassend: Empfangen (705) eines Benutzernamens und eines gehashten Passworts von einer ersten Workstation, Bestimmen (720) eines Klartextpassworts, das mit dem Benutzernamen verbunden ist, Authentifizieren (740) des Klartextpassworts zu einem zweiten Passwort unter Verwenden eines Authentifikationsservers, Bestimmen (750) eines Hashalgorithmus, der von der ersten Workstation verwendet wird, Hashen (760) des Klartextpassworts unter Gebrauch des Hashalgorithmus, um ein errechnetes gehashtes Passwort zu erzeugen, Vergleichen (765) des empfangenen gehashten Passworts mit dem errechneten gehashten Passwort, und wenn das empfangene gehashte Passwort mit dem errechneten gehashten Passwort übereinstimmt, Authentifizieren des Benutzers.
Verfahren nach Anspruch 12, das ferner, wenn das empfangene gehashte Passwort nicht mit dem errechneten gehashten Passwort übereinstimmt, das Versagen des Authentifizierens des Benutzers umfasst (775).
Verfahren nach Anspruch 12, das ferner das Auswählen (735) des Authentifikationsservers aus einer Vielzahl von Authentifikationsservern umfasst.
Verfahren nach Anspruch 12, bei dem das Authentifizieren (740) des Klartextpassworts zu einem zweiten Passwort das Verbinden des Klartextpassworts zu dem zweiten Passworts auf dem Authentifikationsserver unter Gebrauch eines Lightweight Directory Access Protocol (LDAP) umfasst.
Verfahren nach Anspruch 12, bei dem das Bestimmen (750) eines Hashalgorithmus das Auswählen (755) des Hashalgorithmus aus einer Vielzahl von Hashalgorithmen umfasst.
Verfahren nach Anspruch 16, das ferner das Hinzufügen (820) eines neuen Hashalgorithmus zu der Vielzahl von Hashalgorithmen umfasst.
Verfahren nach Anspruch 17, wobei das Hinzufügen eines neuen Hashalgorithmus das Verbinden des Hashalgorithmus mit mindestens einer eines Satzes von Workstations umfasst, wobei der Satz von Workstations die erste Workstation umfasst.
Verfahren nach Anspruch 12, bei dem das Bestimmen eines Klartextpassworts Folgendes umfasst: Bestimmen (715), dass das Klartextpasswort auf dem Anwendungsserver nicht existiert, Anfordern (720) des Klartextpassworts von dem Benutzer, und Empfangen (725) des Klartextpassworts vom Benutzer.
Verfahren nach Anspruch 12, das ferner Folgendes umfast: Empfangen (905) einer Anfrage von der Workstation zum Ändern des Klartextpassworts in ein neues Klartextpasswort, und Ersetzen des Klartextpassworts mit dem neuen Klartextpasswort.
Verfahren nach Anspruch 20, das ferner das Weiterleiten (910) des neuen Klartextpassworts zu dem Authentifikationsserver (205) umfasst.
Computerprogramm, das beim Ausführen auf einem Computer oder Computernetzwerk das in einem der Ansprüche 12 bis 20 beanspruchte Verfahren ausführt.
Computerprogramm nach Anspruch 22, wenn auf einem maschinenzugänglichen Medium gespeichert.