Passwort aus Windows-Programm ändern ( CHGPWD )

[cimbala]

Hallo,

wir verwenden bei uns die i5 als Datenbanksystem, unsere Anwendung ist allerdings eine Windows-Applikation.
Damit ein Benutzer bisher sein Passwort ändern konnte, hatten wir eine Funktion geschrieben die ein GUI erzeugt und so im Hintergrund das Passwort ändert. Gibt es eine Möglichkeit CHGPWD im Greenscreen mit Parametern aufzurufen um das Passwort zu ändern? Dann genauso kann ich den Befehl aus meinem Windows-Programm verwenden.

Danke für eure Hilfe.

[Pikachu]

Mit dem API QSYCHGPW könnte das gehen. V4R5 | V5R2

[Sven Schneider]

Ist aber aus Sicherheitsgründen ein schlechtes Anwendungsdesign.
Da sich so jeder Anwender mit seinem Profil auch manuell (per ODBC, JDBC, FTP etc.) in der Datenbank bewegen kann, d.h. z.B. an der Anwendung vorbei updates ausführen.

Besser :
Ein I5 Anwendungsprofil, mit dem sich die Anwendung gegenüber der Datenbank authorisiert. Das Passowrt hierzu ist nur dem Admin bekannt.

Für die einzelnen Anwender legst du eine eigene Tabelle mit den registrierten Anwendungsbenutzern und deren Passwörtern an.
Hier hast du dann alles selbst in der Hand.
Kannst die Passwörter ändern, verschlüsseln ggf. eigene Anwendungsberechtigungen vergeben etc.

[holgerscherer]

Ist aber aus Sicherheitsgründen ein schlechtes Anwendungsdesign.

Sven... meine persönliche Meinung: Deine Variante ist auch nicht besser. Wie kriegt man da jemals raus, wer in der Applikation rumgefummelt hat? Man hebelt damit die gesamten (nachvollziehbaren) Vorteile des System-Audits aus.

-h

[Fuerchau]

Hier sei noch ergänzt, dass man zusätzlich nach der Verbindung noch das API QSYSETPH aufrufen kann um dann auf den anderen User umzuschalten.
Die Kennworte läßt man generieren, kann sie mit jedem Aufruf ändern (CHGPWD-API kann unter QSECOFR ja Jeder) und schon läufts wieder mit den Journalen.

Eine eigene Anmeldung bekommt man ja nicht hin, da sich das temporäre User-Password ja nicht mal die Anwendung merken muss.

[holgerscherer]

Hier sei noch ergänzt, dass man zusätzlich nach der Verbindung noch das API QSYSETPH aufrufen kann um dann auf den anderen User umzuschalten.

Was haben wir denn dann gewonnen, wenn wir 2 Userprofile verwenden, einmal zum Anmelden und zum Zutritt, und einmal zur Rechteumschaltung und korrekten Auditierung?

Dann habe ich ja noch eine Baustelle mehr, bei der ich mich um ernsthafte Sicherheit kümmern muss; ein PC kann ja ein sehr unsicheres Werkzeug sein.

-h

[Fuerchau]

Genau das ist doch das große Sicherheitsproblem:

Benötigt ein Benutzer mit seiner persönlichen Anmeldung die Datenrechte so stehen diese automatisch für ODBC zur Verfügung.
Bei klassischen 5250-Anwendungen konnte man sich noch mit einem APP-User und Owner-Berechtigung des Startprogrammes behelfen. Dies klappte auch für journalisierte Anwendungen.
ODBC-Zugriffe konnten somit verhindert werden.

Bei Client-Server-Anwendungen und Zugriffen über ODBC/JDBC/DRDA usw. ist es aus mit geerbter Berechtigung.
Die Anmeldung mit einem APP-User scheidet aus o.a. Gründen im Wesentlichen aus.
Was bleibt ?
Genau:
Eigene User-Verwaltung (ggf. mit verschlüsseltem Kennwort)
ODBC-Anmeldung mit APP-User, aufruf einer Prozedur mit User/Kennwort zur eigentlichen Anmeldung und Umschaltung auf das tatsächliche Profil (das nun eben kein bekanntes Kennwort hat).

Gut, dieses geht tatsächlich nur, wenn man keine 5250-Zugriffe mehr benötigt.

[holgerscherer]

Genau das ist doch das große Sicherheitsproblem:
...
Was bleibt ?
Eigene User-Verwaltung (ggf. mit verschlüsseltem Kennwort)
ODBC-Anmeldung mit APP-User, aufruf einer Prozedur mit User/Kennwort zur eigentlichen Anmeldung und Umschaltung auf das tatsächliche Profil (das nun eben kein bekanntes Kennwort hat).
Gut, dieses geht tatsächlich nur, wenn man keine 5250-Zugriffe mehr benötigt.

Na, dann brauche ich auch keinen sicheren Server mehr - der Client ists ja auch nicht. Ich kenne diverse Existenzen dieser Art von Implementierung - bisher war da nicht nur ein Sicherheitsloch (der Server), sondern hunderte (die Clients). Da bin ich doch manchmal froh um den großen Anteil meiner Kunden, die mich schlagen würden, wenn ich denen den 5250 wegnehme.

-h

[DVE]

@Furchau
bei uns gibt es seit Monaten genau diese Anforderung und die scheidet an "meinem" Widerstand. Gestern sollte bewiesen werden, dass ich unrecht habe. Aufbau: Anwender meldet sich mit seinem Benutzer an und ruft ein Programm auf, dass den Benutzer "umschießt". Anschließend sollte den Anwender sich die Daten ohne Benutzung einer Anwendung herunterladen (also SQL). Und siehe da .. er konnte (wie zu erwarten war .. oder ??).
Was will ich damit sagen, auch wenn für die eigentliche Verarbeitung ein anderer Benutzer verwendet wird, dass der Anwender nicht kennt. Sobald das zum "umschießen" benötigte Programm (Prozedur) bekannt ist, "brechen alle Dämme".
Irgendwie ist mir das zu hoch, auf der eine Seite soll die iSeries zur uneinnehmbaren Festung umgewandelt werden und gleichzeit sollen alle Anwender auf alle Daten lesend/schreibend (wg. der schönen graphischen Browseroberfläche) zugreifen können.
Gruß
DVE

[Fuerchau]

Selbst wenn die Prozedur bekannt ist sollten die dazu benötigten Parameter eben nicht bekannt sein.
Die Prozedur muss die Sicherheit leisten dass Sie eben nicht einfach so aufgerufen werden kann.
Andererseits darf es auch kein Benutzerprofil geben, dass eine 5250-lose Anmeldung erlaubt (also ODBC).

So auf die Schnelle fällt mir hierzu nichts ein, es muss aber gehen. Schließlich haben auch andere Datenbanken (SQL-Server, Oracle o.ä.) die selben Probleme wenn es um freie ODBC-Zugriffe geht.
Andere DB's noch um so mehr als dass dort ein Umschiessen des Users nicht möglich ist.

Die Anwendung meldet sich mit eine APP-User an. Dieses Kennwort hierzu muss verschlüsselt abgelegt oder programmiert werden so dass eine normale Anmeldung ausserhalb der Anwendung mit diesem Userprofil unmöglich gemacht wird.
Dann klappt auch das Umschiessen des Users mit einem temporären internen Kennwort dass ausschließlich der Anwendung bekannt ist.
Die dazu nötigen Profile sind selbst wiederum nicht anmeldefähig.
Man kann sogar mal probieren ob QSYGETPH/QSYSETPH mit disabled Profilen möglich ist.

Vielleicht hat ja mal jemand Zeit dies zu probieren.

[DVE]

@Fuerchau
*DISABLED gerade ausprobiert. Geht nicht, der Benutzer muss *ENABLED sein.

Aber die Idee "es muss gehen" ist ein guter Ansatz. Wenn jemand weiß wie, bescheid sagen. Das ist weder lakonisch noch ironisch gemeint, sonder ernst. Mir gehen die Diskussionen hier ziemlich auf die Nerven. Sogar die Forderung alle Anwender sind ja MA der Firma und damit berechtigt die Daten zu sehen/ändern wird gestellt, um den "kleinen" Störenfried ruhigzustellen.

Gruß
DVE

[BenderD]

Hallo,

man muss sich erst mal entscheiden ob der Client (sprich der Rechner) vertrauenswürdig ist, oder nicht; wenn selbiger bei der Anmeldung abprüft und dann Berechtigungen steuern kann, dann vertraut man ihm im allgemeinen, tut man das nicht, dann muss der Anwender vor Aufruf einer gesicherten Anwendung einen Bewis erbringen wer er ist (Benutzer Kennwort oder etwas adäquates).
Jetzt kommt die Anmeldung am Server (AppServer oder Datenbank Server, oder what ever). Selbige erfolgt tunlichst nicht mit einer persönlichen Berechtigung des Anwenders, sonst darf er das alles ja auch unkontrolliert mit einem beliebigen Frontend über ODBC, JDBC, oder das entsprechende Protokoll der Anwendung. Also braucht man jetzt einen AnwendungsBenutzer, der sich connected, dessen Kennwort muss geschützt abgelegt sein, also lokal verschlüsselt (sonst kanns der Anwender lesen), oder hart im Programm, oder remote auf einem entsprechenden Authentikations Server.
Die Berechtigungs Differenzierung innerhalb der entsprechenden Server Domain (in unserem Fall Datenbank), kann jetzt in der Applikation, oder der Datenbank erfolgen, wenn die Anwendung jetzt auf einem Server läuft (WebServer oder AppServer), dann entscheidet man sich meist für Applikations Level (aus Pooling und Cashing Gründen), handelt es sich um einen Fat Client, dann kann man das auch der Datenbank überlassen, wenn die das kann. Persönliche Benutzer scheiden hier meist wegen des zu treibenden Aufwands aus, meist hat man ein paar Rollen, für die jeweils ein Benutzer zur Verfügung steht. Für den Wechsel zur passenden Rolle muss der Anwender einen Beweis haben, dass er diese Rolle spielen darf und im diskutierten Beispiel braucht er noch einen Beweis, dass es die Applikation ist, die den Wechsel zu der Rolle vornimmt, für die Anmeldung kann man durchaus die API Lösung mit dem Profile Switch nehmen. Bei ODBC dürfte das etwas schwieriger als bei JDBC sein (soweit der Benutzer an die DSN auch mit Excel drankommt), dann muss man halt die Kennwörter in der entsprechenden Datei nochmal mit einem Schlüssel verschschlüsseln, den nur die Applikation und nicht der Benutzer kennt (der kann wieder verschlüsselt lokal abgelegt sein, oder hard codiert in der Anwendung, oder remote auf einem Authentikations Server).

Noch ein paar Anmerkungen zur "schönen alten Welt": ich habe bisher so gut wie keine Umgebung gesehen, in der adopted Authority korrekt und sicher implementiert war. Spätestens, wenn man eine Command Line mit der Berechtigung eines solchen Einstiegsprogrammes kombiniert, dann frisst einem der Rechner aus der Hand.

Dieter Bender,

der seine Tätigkeiten im Bereich Security eingestellt hat, weil er keine Lust mehr hatte seinen Kunden Dinge zu erzählen, die sie nicht hören wollten und Sachen zu zeigen, die sie nicht sehen wollten.

Selbst wenn die Prozedur bekannt ist sollten die dazu benötigten Parameter eben nicht bekannt sein.
Die Prozedur muss die Sicherheit leisten dass Sie eben nicht einfach so aufgerufen werden kann.
Andererseits darf es auch kein Benutzerprofil geben, dass eine 5250-lose Anmeldung erlaubt (also ODBC).

So auf die Schnelle fällt mir hierzu nichts ein, es muss aber gehen. Schließlich haben auch andere Datenbanken (SQL-Server, Oracle o.ä.) die selben Probleme wenn es um freie ODBC-Zugriffe geht.
Andere DB's noch um so mehr als dass dort ein Umschiessen des Users nicht möglich ist.

Die Anwendung meldet sich mit eine APP-User an. Dieses Kennwort hierzu muss verschlüsselt abgelegt oder programmiert werden so dass eine normale Anmeldung ausserhalb der Anwendung mit diesem Userprofil unmöglich gemacht wird.
Dann klappt auch das Umschiessen des Users mit einem temporären internen Kennwort dass ausschließlich der Anwendung bekannt ist.
Die dazu nötigen Profile sind selbst wiederum nicht anmeldefähig.
Man kann sogar mal probieren ob QSYGETPH/QSYSETPH mit disabled Profilen möglich ist.

Vielleicht hat ja mal jemand Zeit dies zu probieren.