Passwortprüfung unter SQL

[netcrawler]

Hallo, hallo,

Ich denke hier ist das richtige Forum für eine solche Frage. Nun denn...

Ich arbeite einem ganz normalen Betriebsdaten-Erfassungs-Programm mit Benutzeranmeldung (mit dem Borland C++-Builder, nur so zur Info).

Vor langer, langer Zeit programmierte ich Stuss, wie das hier z.B.:

select count(*) from USERS where USER_ID = *input_benutzer* and USER_PWD = *input_password*

wenn das Resultat 1 war (ich weiß, das ist Amateurhaft, aber ich war jung :rolleyes:), konnte man sich also erfolgreich einloggen... Benutzer und zugehöriges Passwort wurden gefunden!

Nunja, letztes Jahr, während einer Vorlesung laaberte irgendsoein Prof. allerdings von sehr einfachen Maßnahmen, um genau so ein System Ruck Zuck auszuhebeln... Er nannte sogar einen Namen dafür! Der Trick ist einfach was spezielles für "*input_password*" einzugeben und SQL liefert nicht wirklich das richtige zurück => Zugang erfolgreich!
Mensch, wenn ich damals nur besser aufgepasst hätte :(

Frage 1: Wie lautet dieses Verfahren? Funktioniert das wirklich mit allen SQL-Varianten? (arbeite grad mit Oracle)

Frage 2: Wie programmiert man am sichersten eine Passwort-Abfrage, die hauptsächlich in SQL erfolgt!

[pate33]

hehe, jo.

du kannst ne AND oder IN (subselect) klausel z.b. einbauen und somit die abfrage aushebeln. ;) nur so ne idee, aber wuerde sicherlich funktionieren.

liegen die pw's in verschluesselter form vor?

select pw from users where username = 'username';

damit bekommst das pw zurueck, welches du in der applikation dann abgleichst. musst halt dann vorher noch nen md5() oder so anwenden, je nachdem ob die passwoerter verschluesselt sind.

so long

[netcrawler]

Du meinst man könnte das irgendwie so aushebeln?

select count(*) from USERS where USER_ID = *input_benutzer* and USER_PWD = ' IN oder AND '

aber wie kann das innerhalb von ' ' funktionieren? Da kann ich doch keinen subselect reinschreiben?

Und zweitens: ist klar, dass ich das Passwort auch im Programm prüfen kann und es bestimmt besser so ist. Aber rein interessehalber möchte ich eine sichere Methode für SQL wissen! Vielleicht gibt's ja gar keine? :rolleyes:

[pate33]

wie das genau funktioniert, weiss ich nicht. wie gesagt, war nur eine idee ...

sicheres abfragen ueber sql ... hmm ...

ich hab das bisher immer auf dem client gemacht, da es eben immer wieder moeglichkeiten gibt, den mechanismus zu knacken. sei es ueber die netzverbindung eine man-in-the-middle attacke (statt der 0 eine 1 zurueck senden, dass eben eintrag gefunden sei) oder nen bug im sql. Am sichersten ist auf jeden fall die methode auf dem client, da man das pw verschluesselt uebertragen kann.

[MaSie]

Meines Erachtens geht es aber auch leichter, die Manipulation des Selects (was dein Prof wahrscheinlich gemeint hat) zu verhindern. Gehen wir mal davon aus, daß er durch geschicktes Eingeben von user und pass das so hinbekommt, daß er den select so umbauen kann, daß das einfache Auffinden eines richtigen Usernamens reichen würde.
Dann bekommt er ein richtiges Ergebniss(weil er z.B. durch die query-manipulation alle Passworter zulassen würde) und in deinen Augen wäre er dann als user akzeptiert.

Wenn du aber nicht nur schaust, ob es einen Datensatz gibt, sondern auch die Werte des Datensatzes mit den Eingaben vergleichst (und zwar als Strings), dann würde auffalen, wenn bei dir das gefundene Passwort "hallo" heißt und das eingegebene Passwort irgendwie "1 or passwort like '%'" oder halt so in der art.

Natürlich kann man auch wie glaube ich schon angesprochen versuchen die Verbindung zu überwachen und dann sich anderer Leute Daten zum einloggen herzunehmen, da muß das dann verschlüsselt gesendet werden (und natürlich sollte der Verschlüsselungsalgorithmus nicht so leicht zu "erraten" sein).

[Jack]

Das dürfte wohl eine SQL Injection gewesen sein. Dabei versucht man mittels der übergebenen Werte die SQL Anweisung auszuhebeln und eigene Anweisungen auszuführen. In Deinem Fall wäre das dann eben eine Manipulation des gegebenen SQL Statements.
Normalerweise verhindert man das dadurch, daß man die String Begrenzer im übergebenen String nicht vorkommen läßt .
Beispiel:

SELECT * FROM User WHERE Name="[username]"

Ersetze vorher alle Vorkommnisse von " in [username].

[netcrawler]

Exakt...

SQL Injection war der Begriff den er benutzte!
Wie könnte man solche Risiken umgehen?

Ok, zwei Möglichkeiten haben wir ja schon:

1. Abfrage gänzlich beim Client
2. Übergebenes Passwort nochmal prüfen (Methode von MaSie)

Sonst noch Methoden?

[pate33]

wenn du alle " und ' zeichen aus dem uebergebenen benutzernamen und passwort filters (inkl. ascii-codes etc. ;)) dann hast auch sicheres sql, bzw. kannst die authentifizierung als sicher bezeichnen ...

[netcrawler]

Ooooopppppppssshhh...

das Sicherheitsproblem das dadurch entsteht ist ja RIESIG! HILFE!!! Und das betrifft ja nicht unbedingt nur Passwortabfragen...

Ich hab im Netz gerade diesen Befehl entdeckt:

select count(*) from users where UserName='' DELETE Users --' AND UserPassword=''

Der löscht mir z.B. sämtliche Benutzer!

Bei welchen Systemen funktioniert das (MySQL, MSSQL, Oracle, etc.)?

[pate33]

select count(*) from users where UserName='';
DELETE Users;

so funtzt es auf jeden fall ... bei deinem beispiel fehlt ein linebreack sowie ein semikolon (gerade getestet. ;))

so long

[Buxo]

Hi,
wie wärs mit ner Verschlüsselung lokal, mit Key,
entschlüsselung auf dem Server anhand Algorhytmus des Keys und Antwort true or False?
lässt sich natürlich noch ausbauen;)

Ich seh da kein Problem mehr mit ner SQL Injection, obwohl ich davon noch nix gehört hab.

[netcrawler]

Ich weiß, es klingt absurd, aber vielleicht findet jemand genau einen String, der chiffriert wieder den Klartext:

' or '1'='1'

ergibt! Würde mich nicht wundern, wenn in einschlägigen Hacker-Foren solche Strings für jeden symetrischen Verschlüsselungsalgo rumgeistern!

[Jack]

Ja, SQL Injection ist heftig. Beliebige SQL Anweisungen auf Deiner Datenbank. Kann Dir alles löschen, verändern, ...

Wie gesagt, es hängt an den String Begrenzern. mySQL verwendet Hochkommata um Strings einzugrenzen, die dürfen dann natürlich nicht im Usernamen und Passwort vorkommen, also muß man sie vorher ersetzen und erst dann in die SQL Anweisung einbauen. Danach können da SQL Befehle kommen wie sie wollen, sie sind als Strings gekennzeichnet und werden dementsprechend auch nicht ausgeführt.

Verschlüsselung gegen sowas ist da etwas übertrieben. Nichtsdestotrotz sollten Passwörter am besten verschlüsselt werden zur Übertragung und auch verschlüsselt in der Datenbank abgelegt werden (MD5 oder auch bei mySQL die PASSWORD Funktion)

[Jonas]

Naja und wenn man z.B. mit PHP arbeitet, dann wird magic_quotes sowieso aktiviert sein, und somit wird jede Benutzereingabe (Cookie, Get, Post) sowieso escaped, also gerade das für MySQL relevante ' durch \' ersetzt...