MSSQL Server - Datentyp 'password' gesucht

[Lude]

Hi,

wuerde gerne in einem Datenfeld des Typs 'password' Passwoerter speichern. Leider gibt es den Datentyp nicht. - Kann mir jemand einen Tipp geben, wie ich die Anforderung Passwoerter "systemverschluesselt" zu speichern bearbeiten kann?

Gruss,
Lude

[Markus]

Du verwendest den Datentyp varchar oder sonstige zeichenketten, und speicherst sie halt verschlüsselt. keine ahnung, mit was Du auf die DB zugreifst !? falls mit php, würd ich mir mal die fkt. md5 zu gemüte führen ...

mfG,
   Markus.

[Lude]

Hi,

Du verwendest den Datentyp varchar oder sonstige zeichenketten, und speicherst sie halt verschlüsselt. keine ahnung, mit was Du auf die DB zugreifst !? falls mit php, würd ich mir mal die fkt. md5 zu gemüte führen ...

ich dachte eher an einen Datentyp, der den Wert der Zeichenkettenfolge allen Nutzern fuer Lesezwecke vorenthaelt. - Genauso wie beim Objekt 'Benutzername' des Systems 'MS SQL Server 2000'.

Gruss,
Lude

[Frank aus Ulm]

Hi, hallo

Wie jetzt bitte?

Das System "MS SQL Server 2000" hat ein Objekt "Benutzername" welches von
allen Nutzern nicht lesbar ist.

• es gibt kein Datentyp "Benutzername" oder "username" für Tabellen afaik
• wo ist dieses "Objekt" angesiedelt? wie und wo ist es nicht lesbar
• Benutzername wofür?  DB Zugriff/Datenbank oder eigenes Benutzersystem?
• was meinst du mit 'System' .. die Instanz des MS SQL Servers, die du
    über den Enterprise Manager verwalten kanns

Über dem EM kann ich doch die Benutzernamen der Datenbank(en) sehen ?? Normale User nicht, die haben ja eine andere Rolle.

Verschlüsselungen, egal symm./asymm./digest erzeugen im angewendeten Fall
programmatorisch eine Zeichenkette (z.B. Hash), die die Verschlüsselung
repräsentiert. Möglicherweise gibt es Ausnahmefälle, aber das steht hier
nicht zur Diskussion.

Pseudosicherheit mag eine MD5 (Digest) Hash-isierung der Ausgangszeichenketten (Passwort) geben, wo der Hash dann in der DB Tabelle als Varchar2 abgelegt wird.
Das Thema Pseudo-Sicherheit durch Verschlüsselung von Daten ist weiter unten neulich unter dem Titel SSL diskutiert worden. Egal wo du bei einer unverschlüsselten _Verbindung_ den Hash erzeugst  (HTTP Digest Authentication mal unbeachtet ... ist Neuland für mich) man-in-the-middle Aktionen sind immer der Schwachpunkt.

und was ist "systemverschlüsselt" ... wer auch immer dir diese Anforderung angetragen hat, sollte sie auch definieren können.

MS SQL Srv. unterstützt verschiedene Auth-Modi .... MS SQL Srv. basiert und "windows-integrated" ...

letzteres funktioniert auf Basis der am NT-basierten (auch w2ksrv und folgende) Benutzeraccounts ... Trusted Connections spielen auch eine Rolle.

Aber was willst du genau, bitte ?

Gruß, Frank

[Lude]

Hi,

Wie jetzt bitte?

Das System "MS SQL Server 2000" hat ein Objekt "Benutzername" welches von
allen Nutzern nicht lesbar ist.

das Password, dass diesem Objekt zugeordnet werden kann, ist nicht lesbar, obwohl "im System" gespeichert.

• wo ist dieses "Objekt" angesiedelt? wie und wo ist es nicht lesbar

Du kennst doch die Hilfefunktion des MSSQLEM.

• Benutzername wofür?  DB Zugriff/Datenbank oder eigenes Benutzersystem?

s.o.

• was meinst du mit 'System' .. die Instanz des MS SQL Servers, die du
    über den Enterprise Manager verwalten kanns

exakt

Über dem EM kann ich doch die Benutzernamen der Datenbank(en) sehen ?? Normale User nicht, die haben ja eine andere Rolle.

s. ganz o.

Verschlüsselungen, egal symm./asymm./digest erzeugen im angewendeten Fall
programmatorisch eine Zeichenkette (z.B. Hash), die die Verschlüsselung
repräsentiert. Möglicherweise gibt es Ausnahmefälle, aber das steht hier
nicht zur Diskussion.

Also die Verschluesselung soll vom System angeboten werden, weil dieses es ja schon "kann". Und das es dann kann, weiss ich wegen der internen Sicherheit, die ein Objekt "Benutzernamen" unterstuetzt (oder andersrum).

Pseudosicherheit mag eine MD5 (Digest) Hash-isierung der Ausgangszeichenketten (Passwort) geben, wo der Hash dann in der DB Tabelle als Varchar2 abgelegt wird.
Das Thema Pseudo-Sicherheit durch Verschlüsselung von Daten ist weiter unten neulich unter dem Titel SSL diskutiert worden. Egal wo du bei einer unverschlüsselten _Verbindung_ den Hash erzeugst  (HTTP Digest Authentication mal unbeachtet ... ist Neuland für mich) man-in-the-middle Aktionen sind immer der Schwachpunkt.

Mir geht's mehr um Sicherheit nach innen, wenn Du weisst was ich meine.   :-)

und was ist "systemverschlüsselt" ... wer auch immer dir diese Anforderung angetragen hat, sollte sie auch definieren können.

Dank Deiner Gegenfragen habe ich ja nun die Moeglichkeit, die ich nun auch moeglicherweise halbwegs genutzt habe?!

MS SQL Srv. unterstützt verschiedene Auth-Modi .... MS SQL Srv. basiert und "windows-integrated" ...

letzteres funktioniert auf Basis der am NT-basierten (auch w2ksrv und folgende) Benutzeraccounts ... Trusted Connections spielen auch eine Rolle.

Aber was willst du genau, bitte ?

Hilfe.

Gruss,
Lude