Hallo,
Icg finde einfach keine Lösung für die Abfrage von Usernummer und
Passwort.
Die Daten sind in einer Tabelle auf dem Server. Der User soll seine
Kunden-Nr. und ein Passwort eingeben.
Nun muss mit einer Schleife geprüft werden, ob beides in der Datenbank
zusammenpassend vorhanden und wenn ja im Programm weitergehen, wenn
nein, Feflermeldung ausgeben.
Kann jemand helfen?
Gruß Hoffi
Klaus J. Hofmann
Radeberg
Klaus J. Hofmann schrieb:
> Icg finde einfach keine Lösung für die Abfrage von Usernummer und
> Passwort.
Was hast du probiert?
> Die Daten sind in einer Tabelle auf dem Server. Der User soll seine
> Kunden-Nr. und ein Passwort eingeben.
Dann schickt mans per Post an den Server.
> Nun muss mit einer Schleife geprüft werden, ob beides in der Datenbank
> zusammenpassend vorhanden...
Wozu brauchst du eine Schleife? Kann es sein, dass du WHERE in SQL noch
nicht kennst?
> und wenn ja im Programm weitergehen, wenn
> nein, Feflermeldung ausgeben.
if {...} else {...}
könnte helfen.
> Kann jemand helfen?
Tschuldigung, aber es sieht danach aus, als hättest du von Grundlagen
ein bisschen zu wenig Ahnung.
gruss, heli
Hallo
>Wozu brauchst du eine Schleife? Kann es sein, dass du WHERE in SQL noch
>nicht kennst?
Weil ich nicht davon ausgehe, dass die richtige User-Nr. eingetragen
wurrde. Das wollte ich in einer Schleife prüfen, ob diese Nr.
überhaupt da ist.
Gleichzeitig bei Vorhandensein, das Passwort mit abrufen.
Hier liegt sicherlich mein Fehler.
>if {...} else {...}
if-else zum Vergleich ist klar.
>Tschuldigung, aber es sieht danach aus, als hättest du von Grundlagen
>ein bisschen zu wenig Ahnung.
der Kommentar war überflüssig, nicht jeder ist sofort ein Meister,
wenn er etwas Neues beginnt.
Tschüß, Hoffi
Klaus J. Hofmann
Radeberg
Klaus J. Hofmann schrieb:
> Hallo
>
>
>> Wozu brauchst du eine Schleife? Kann es sein, dass du WHERE in SQL noch
>> nicht kennst?
>
> Weil ich nicht davon ausgehe, dass die richtige User-Nr. eingetragen
> wurrde. Das wollte ich in einer Schleife prüfen, ob diese Nr.
> überhaupt da ist.
Halte ich sicherheitstechnisch fuer bedenklich. Deine Anwendung sollte
bei einer fehlgeschlagenen Authentifizierung keine Angaben machen ob der
User und oder nur das Password falsch war.
Aber wenn du das unbedingt machen willst dann waere dies ein einfaches
"SELECT COUNT(*) AS anzahl FROM user_account WHERE account_name = '%s'"
*NACHDEM* die Authentifizierung fehlgeschlagen ist. Wenn 'anzahl' dann
ungleich 0 ist gibts den Useraccount und das Passwort war nur falsch.
Gruss
Joerg
--
TakeNet GmbH Mobil: 0171/60 57 963
D-97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
Klaus J. Hofmann schrieb:
>> Wozu brauchst du eine Schleife? Kann es sein, dass du WHERE in SQL noch
>> nicht kennst?
>
> Weil ich nicht davon ausgehe, dass die richtige User-Nr. eingetragen
> wurrde. Das wollte ich in einer Schleife prüfen, ob diese Nr.
> überhaupt da ist.
Nochmals: wozu brauchst du da die Schleife? In einer Datenbank zu
prüfen, ob ein Datensatz mit einem bestimmten Kriterium da ist, macht
man mit WHERE.
PEAR::Auth zum Beispiel selektiert den Datensatz per übergebenem
Username und vergleicht das selektierte Passwort dann auf
Applikationsebene mit dem übergebenen.
>> Tschuldigung, aber es sieht danach aus, als hättest du von Grundlagen
>> ein bisschen zu wenig Ahnung.
>
> der Kommentar war überflüssig,...
Nein. Ich wollte dich nämlich dazu anregen, grundsätzlich über das, was
du realisieren möchtest, weiter nachzudenken: Wie sehen für
Authentifizierungsmechanismen grundsätzliche Konzepte aus? Welche
Einzelschritte sind dafür notwendig? Und wie setzt man die um?
Hier hatte ich anhand deines Originalpostings den Eindruck, du hast eben
zu wenig Ahnung von den Grundlagen.
Also:
* Normalerweise ist ein Benutzername eindeutig, ein Passwort nicht
unbedingt.
* Man benötigt eine Loginmaske, die solange aufgerufen wird, bis die
Authentifizierung stimmt. In der FAQ gibts dazu etwas unter dem
Stichwort Affenformular.
* Man muss die übergebenen Daten prüfen. Also selektiert man den
Datensatz, dessen Benutzername mit dem übergebenen übereinstimmt. Das
macht man *nicht*, indem man die ganze Tabelle aus der Datenbank holt
und dann auf Applikationsebene in einer Schleife durchläuft und schaut,
obs bei einem Datensatz passt. Das macht man mit WHERE und passenden
Indizes auf den Feldern. Dafür gibts RDBMS.
* Hat man einen passenden Datensatz gefunden, prüft man das Passwort.
Ist das korrekt, muss man speichern, dass der Benutzer sich korrekt
authentifiziert hat. Das macht man normalerweise mit Sessions.
* Genau diese Prüfung muss in jedem Skript erfolgen, das zu diesem
geschützten Bereich gehört:
Prüfen, ob sich der Benutzer bereits authentifiziert hat.
Ja / Nein
| |
| +- Loginmaske zeigen <------------------------------------+
| | |
| +- Request verarbeiten: Gibt es den übergebenen Benutzer? ^
| Ja / Nein |
| | | |
| v +----------------------------------------------->-+
| | |
| +- Ist das Passwort korrekt? ^
| Ja / Nein |
| | | |
| v +-------------------------------------------->-+
| |
v +- Authentifizierung speichern
| |
+-<-----------+
|
v
|
+- "normales" Skript
> ...nicht jeder ist sofort ein Meister,
> wenn er etwas Neues beginnt.
Das hab ich weder behauptet noch gemeint.
gruss, heli
Klaus J. Hofmann schrieb:
> Weil ich nicht davon ausgehe, dass die richtige User-Nr. eingetragen
> wurrde. Das wollte ich in einer Schleife prüfen, ob diese Nr.
> überhaupt da ist.
Wie meinen? Was soll das bringen? Entweder der User gibt richtiges
Passwort *und* Benutzerkennung ein oder er fliegt raus. Funktioniert auf
allen mir bekannten Websites so.
> Gleichzeitig bei Vorhandensein, das Passwort mit abrufen.
> Hier liegt sicherlich mein Fehler.
Dann bräuchtest du immer noch keine Schleife.
>> Tschuldigung, aber es sieht danach aus, als hättest du von Grundlagen
>> ein bisschen zu wenig Ahnung.
>
> der Kommentar war überflüssig, nicht jeder ist sofort ein Meister,
> wenn er etwas Neues beginnt.
Für "was Neues" sind Authentifizierungs-Lösungen genau das richtige...
Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
>Halte ich sicherheitstechnisch fuer bedenklich. Deine Anwendung sollte
>bei einer fehlgeschlagenen Authentifizierung keine Angaben machen ob der
>User und oder nur das Password falsch war.
Ist richtig Jörg, ich teile es auch nicht mit. Ich habe jetzt einen
anderen Weg eingeschlagen..
Über if (!empty($kunden_nr) && !empty($password)) prüfe ich, ob
überhaupt Einträge da sind und dann
$sql = "SELECT password FROM kunde WHERE
kunden_nr={$kunden_nr}";
$result = mysql_query($sql) or
die($sql.'
'.mysql_error());
$ds = mysql_fetch_object($result);
$password = $ds->password;
hole ich das Passwort und vergleiche es mit der Eingabe.
Gruß, Hoffi
Klaus J. Hofmann
Radeberg
>* Normalerweise ist ein Benutzername eindeutig, ein Passwort nicht
>unbedingt.
Danke, heli, ich glaube, ich habe schon den richtigen Weg gefunden.
Siehe Antwort an Jörg Behrens.
Werde nochmal alles korrekt prüfen.
Gruß, Hoffi.
Klaus J. Hofmann
Radeberg
>Wie meinen? Was soll das bringen? Entweder der User gibt richtiges
>Passwort *und* Benutzerkennung ein oder er fliegt raus. Funktioniert auf
>allen mir bekannten Websites so.
Richtig, Gregor, ich habe das bereits erkannt.
Klaus J. Hofmann
Radeberg
Klaus J. Hofmann schrieb:
>> Halte ich sicherheitstechnisch fuer bedenklich. Deine Anwendung sollte
>> bei einer fehlgeschlagenen Authentifizierung keine Angaben machen ob der
>> User und oder nur das Password falsch war.
>
> Ist richtig Jörg, ich teile es auch nicht mit. Ich habe jetzt einen
> anderen Weg eingeschlagen..
>
> Über if (!empty($kunden_nr) && !empty($password)) prüfe ich, ob
> überhaupt Einträge da sind und dann
> $sql = "SELECT password FROM kunde WHERE
> kunden_nr={$kunden_nr}";
> $result = mysql_query($sql) or
> die($sql.'
'.mysql_error());
> $ds = mysql_fetch_object($result);
> $password = $ds->password;
> hole ich das Passwort und vergleiche es mit der Eingabe.
Warum kein einzelnes Select in dem du nach Passwort *und* KundenNr
selektierst? Wenn kein Datensatz zurückkommt, ist die Anmeldung ungültig.
Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Klaus J. Hofmann schrieb:
>> Halte ich sicherheitstechnisch fuer bedenklich. Deine Anwendung
>> sollte bei einer fehlgeschlagenen Authentifizierung keine Angaben
>> machen ob der User und oder nur das Password falsch war.
>
> Ist richtig Jörg, ich teile es auch nicht mit. Ich habe jetzt einen
> anderen Weg eingeschlagen..
>
> Über if (!empty($kunden_nr) && !empty($password)) prüfe ich, ob
je nachdem, in welcher methode sie übermittelt wurden heisst es:
$_POST['kunden_nr'] oder $_GET['kunden_nr']
$_POST['password'] oder $_GET['password']
wenns beides sein kann, dann auch:
$_REQUEST['kunden_nr'] und $_REQUEST['password']
siehe dazu:
[FAQ]
11.20. Warum funktionieren meine Formulare nicht?
http://www.php-faq.de/q/q-formular-register-globals.html
> überhaupt Einträge da sind und dann
> $sql = "SELECT password FROM kunde WHERE
> kunden_nr={$kunden_nr}";
hier sollte man SQL-Injection vorbeugen siehe:
leider nicht ganz aktuell -> mysql_real_escape_string()
[FAQ]
16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
http://www.php-faq.de/q/q-sql-injection.html
....a pros pos schonmal über folgendes nachgedacht:
SELECT * FROM kunde WHERE kunden_nr={$kunden_nr} AND
password={$ds->password}
übrigens sollte man das Passwort nicht im Klartext speichern, sondern
in einer verschlüsselten form. Dann ist es auch nicht ganz so fatal,
wenn mal einer in die Tabelle geschaut hat.
Grüße
Johannes
--
Emails ohne "[nospam]" im Betreff werden kommentarlos gelöscht.
Klaus J. Hofmann schrieb:
> Hallo,
> Icg finde einfach keine Lösung für die Abfrage von Usernummer und
> Passwort.
> Die Daten sind in einer Tabelle auf dem Server. Der User soll seine
> Kunden-Nr. und ein Passwort eingeben.
> Nun muss mit einer Schleife geprüft werden, ob beides in der Datenbank
> zusammenpassend vorhanden und wenn ja im Programm weitergehen, wenn
> nein, Feflermeldung ausgeben.
> Kann jemand helfen?
Ich persönlich Prüfe bei Authentifizierungen mit Name und Password immer
nach folgendem Schema:
$query = "SELECT name,pass FROM users WHERE name = '{$_POST['name']}' &&
PASSWORD( '{$_POST['pass']}' )";
Bevor jemand schreit! Natürlich habe ich den Inhalt des $_POST-Arrays
zuvor an anderer Stelle auf Sicherheit geprüft.
Anschliessend noch nachsehen ob ein Datensatz zurückgegeben wurde und
fertig ist. Bei einer Kundennummer sieht das ganze dann Natürlich
entsprechend aus mit der Kundennummer statt dem Namen.
Bei einer Abfrage mit diesem Querry muss das PW natürlich auch schon mit
PASSWORD eingetragen werden.
Norbert Melzer schrieb:
> Ich persönlich Prüfe bei Authentifizierungen mit Name und Password immer
> nach folgendem Schema:
>
> $query = "SELECT name,pass FROM users WHERE name = '{$_POST['name']}' &&
> PASSWORD( '{$_POST['pass']}' )";
>
> Bei einer Abfrage mit diesem Querry muss das PW natürlich auch schon mit
> PASSWORD eingetragen werden.
Du weist aber schon, dass man die PASSWORD-Funktion nicht für eigene
Tabellen benutzen soll? Schätzungweise geht es hier ja nicht um einen
MySQL-User aus der DB `mysql`.
MD5() o.ä ist hier besser für die Passwortspalte.
Gruß
Carsten
Norbert Melzer wrote:
> Ich persönlich Prüfe bei Authentifizierungen mit Name und Password immer
> nach folgendem Schema:
>
> $query = "SELECT name,pass FROM users WHERE name = '{$_POST['name']}' &&
> PASSWORD( '{$_POST['pass']}' )";
>
> Bevor jemand schreit! Natürlich habe ich den Inhalt des $_POST-Arrays
> zuvor an anderer Stelle auf Sicherheit geprüft.
*schrei*
if(MySQL):
mysql_real_escape_string()
MySQL ignoriert Groß- und Kleinschreibung bei
"SELECT...WHERE FIELD=VALUE"
gruß, Frank
Hi Norbert
Norbert Melzer am Wed, 12 Apr 2006 16:50:48 +0200:
> $query = "SELECT name,pass FROM users WHERE name = '{$_POST['name']}' &&
> PASSWORD( '{$_POST['pass']}' )";
>
> Bevor jemand schreit! Natürlich habe ich den Inhalt des $_POST-Arrays
> zuvor an anderer Stelle auf Sicherheit geprüft.
Was prüfst Du denn?
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Carsten Wiedmann schrieb:
> Norbert Melzer schrieb:
>> Bei einer Abfrage mit diesem Querry muss das PW natürlich auch schon
>> mit PASSWORD eingetragen werden.
>
> Du weist aber schon, dass man die PASSWORD-Funktion nicht für eigene
> Tabellen benutzen soll? Schätzungweise geht es hier ja nicht um einen
> MySQL-User aus der DB `mysql`.
>
> MD5() o.ä ist hier besser für die Passwortspalte.
>
> Gruß
> Carsten
>
Nein wusste ich nicht, aber ich werde es mir für die Zukunft merken und
MD5 nutzen.
Frank Schenk schrieb:
> Norbert Melzer wrote:
> *schrei*
>
> if(MySQL):
> mysql_real_escape_string()
> MySQL ignoriert Groß- und Kleinschreibung bei
> "SELECT...WHERE FIELD=VALUE"
>
>
> gruß, Frank
Ist mir neu, aber da ich ja beim Anlegen eines neuen Users auf Existenz
des Usernamen prüfe und ggf Fehlermeldungen schmeiße, ist es
ausgeschlossen daß es einen User ABC und abc gibt
Bodo Kaelberer schrieb:
> Hi Norbert
>
> Norbert Melzer am Wed, 12 Apr 2006 16:50:48 +0200:
>> $query = "SELECT name,pass FROM users WHERE name = '{$_POST['name']}' &&
>> PASSWORD( '{$_POST['pass']}' )";
>>
>> Bevor jemand schreit! Natürlich habe ich den Inhalt des $_POST-Arrays
>> zuvor an anderer Stelle auf Sicherheit geprüft.
>
> Was prüfst Du denn?
>
Ich überprüfe grundsätzlich ob übergebene Variablen einen SQL-Statement
enthalten bevor ich sie an die DB weiterreiche.
Abend
Norbert Melzer am Wed, 12 Apr 2006 20:30:36 +0200:
> Ist mir neu, aber da ich ja beim Anlegen eines neuen Users auf Existenz
> des Usernamen prüfe und ggf Fehlermeldungen schmeiße, ist es
> ausgeschlossen daß es einen User ABC und abc gibt
Ist aber auch beim Passwort von Bedeutung. Ist der Vergleich nicht
case-sensitive, ist es sicher noch schwierig ein Passwort zu erraten
aber immerhin schon um längen einfacher.
Bye
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Abend
Norbert Melzer am Wed, 12 Apr 2006 20:33:29 +0200:
> >> Bevor jemand schreit! Natürlich habe ich den Inhalt des $_POST-Arrays
> >> zuvor an anderer Stelle auf Sicherheit geprüft.
> >
> > Was prüfst Du denn?
> >
>
> Ich überprüfe grundsätzlich ob übergebene Variablen einen SQL-Statement
> enthalten bevor ich sie an die DB weiterreiche.
Es muss nicht ein ganzes Statement enthalten sein. Ein einzelner in
Wert mit einem ' reicht schon um einem Statement einen ganz anderen
Sinn zu geben.
Daher sollten Werte vor der Verwendung im Statement immer mittels
mysql_real_escape_string() escaped werden. Und abhängig von der
Einstellung für magic_quotes_gpc zusätzlich noch vorher stripSlashes()
anwenden
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Bodo Kaelberer schrieb:
>
> Ist aber auch beim Passwort von Bedeutung. Ist der Vergleich nicht
> case-sensitive, ist es sicher noch schwierig ein Passwort zu erraten
> aber immerhin schon um längen einfacher.
>
> Bye
>
Der Hash den mit PASSWORD liefert beschränkt sich IMHO auf nur eine Art
von Schreibung, oder bin ich da jetzt falsch informiert?
Aber da ich ja eh demnächst auf md5 umstellen werde, muss ich das dort
eh noch einmal prüfen.
Wie kann ich denn nötigenfalls Casesensitiv abfragen?
Bodo Kaelberer schrieb:
>
> Es muss nicht ein ganzes Statement enthalten sein. Ein einzelner in
> Wert mit einem ' reicht schon um einem Statement einen ganz anderen
> Sinn zu geben.
> Daher sollten Werte vor der Verwendung im Statement immer mittels
> mysql_real_escape_string() escaped werden. Und abhängig von der
> Einstellung für magic_quotes_gpc zusätzlich noch vorher stripSlashes()
> anwenden
>
OK Danke für den Hinweis!
Mit freundlichen Grüßen
Norbert
Hi Norbert
Norbert Melzer am Wed, 12 Apr 2006 21:41:26 +0200:
> Der Hash den mit PASSWORD liefert beschränkt sich IMHO auf nur eine Art
> von Schreibung, oder bin ich da jetzt falsch informiert?
Ja, der wird wohl für jede Schreibweise einen anderen Wert liefern.
Der Vergleich des Hash ist dann aber trotzdem noch case-insensitiv.
Wobei bei Deiner Schreibweise ja gar kein Vergleich stattfindet. Da
steht einfach
.....&& PASSWORD( '{$_POST['pass']}' )
Wenn ich das korrekt deute, wird da einfach ein kodiertes Passwort
erzeugt, aber nicht verglichen. Funktioniert das überhaupt oder wird
das einfach als wahr gedeutet? Was passiert, wenn das Passwort nicht
stimmt? (-:
Oder funktioniert das mit PASSWORD() ganz anders, als ich jetzt denke?
> Aber da ich ja eh demnächst auf md5 umstellen werde, muss ich das dort
> eh noch einmal prüfen.
Da gilt genau dasselbe. Der Vorteil von md5(), dass am es auch ohne
Datenbank verwenden kann.
> Wie kann ich denn nötigenfalls Casesensitiv abfragen?
Weiss grad nicht genau (-;
Man kann glaub im Statement ein BINARY vor dem Vergleich notieren.
Oder man verwendet einen Feldtyp, der case-insensitiv vergleicht. Ein
VARBINARY statt VARCHAR? Weiss nicht - muss jemand nachschauen.
Bye
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Norbert Melzer am Wed, 12 Apr 2006 21:42:40 +0200:
> > Daher sollten Werte vor der Verwendung im Statement immer mittels
> > mysql_real_escape_string() escaped werden. Und abhängig von der
> > Einstellung für magic_quotes_gpc zusätzlich noch vorher stripSlashes()
> > anwenden
> >
>
> OK Danke für den Hinweis!
>
> Mit freundlichen Grüßen
Und dann natürlich, hast Du schon aber besser noch mal gesagt, den
Wert im Statement in '' notieren. Sonst hast du mindestens einen
Syntax-Fehler, wenn jemand ein ' verwendet.
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
On Wed, 12 Apr 2006 17:16:58 +0200, Frank Schenk wrote:
> MySQL ignoriert Groß- und Kleinschreibung bei
> "SELECT...WHERE FIELD=VALUE"
Wenn du es so einstellst, dann ja.
Gruß,
Matthias
Bodo Kaelberer schrieb:
> Wobei bei Deiner Schreibweise ja gar kein Vergleich stattfindet. Da
> steht einfach
>
> .....&& PASSWORD( '{$_POST['pass']}' )
OK! Du machst mich da gerade auf nen ganz gewaltigen Fehler aufmerksam,
Gottseidank ist davon noch nix am Netz.... Ich werde meinen
Auth-Mechanismuss noch mal neumachen müssen :-)
Norbert Melzer am Thu, 13 Apr 2006 06:32:16 +0200:
> Bodo Kaelberer schrieb:
>
> > Wobei bei Deiner Schreibweise ja gar kein Vergleich stattfindet. Da
> > steht einfach
> >
> > .....&& PASSWORD( '{$_POST['pass']}' )
>
> OK! Du machst mich da gerade auf nen ganz gewaltigen Fehler aufmerksam,
> Gottseidank ist davon noch nix am Netz.... Ich werde meinen
> Auth-Mechanismuss noch mal neumachen müssen :-)
Heisst das, einen richtigen Benutzernamen gekannt zu haben, hat
gereicht, um sich einzuloggen - egal welches Passwort? (-:
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Nochmal eine Frage zu Passwort:
Wie stelle ich in der Tabelle in MySQ das Password auf md5 um und wie
ist die Rückantwort bei Abfrage, HASH-Wert oder entschlüsseltes
Passwort.
Wenn HASH-Wert, wie entschlüssele ich es?
Gruß Hoffi
Klaus J. Hofmann
Radeberg
Hi Klaus
Klaus J. Hofmann am Thu, 13 Apr 2006 11:06:47 +0200:
> Wie stelle ich in der Tabelle in MySQ das Password auf md5 um und wie
> ist die Rückantwort bei Abfrage, HASH-Wert oder entschlüsseltes
> Passwort.
Beim Anlegen des Benutzers wird für das Password md5() aufgerufen und
der erzeugte Wert in die die Datenbank geschrieben.
Beim Login wird ebenfalls md5() auf das übergebene Passwort ausgeführt
und dann im Statement verglichen.
Vorteil ist, dass das Passwort in der Datenbank nicht in Klarschrift
steht. Selbst wenn jemand mal einen Blick in die Datenbank oder ein
Backup erhascht, hat er danach noch keine Passwort.
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Klaus J. Hofmann schrieb:
> Nochmal eine Frage zu Passwort:
> Wie stelle ich in der Tabelle in MySQ das Password auf md5 um und wie
Also in der VORHANDENEN mysql.user Tabelle ist nichts umstellen. Du
meintest die Tabellen deiner Applikation, richtig?.
Folgende Frage muss vorher beantwortet werden.
1. Reicht einem md5() oder moechte man sha1() usw. (Bedingt laengere
Spalte aber dafuer mehr Zufaelligkeit und Sicherheit)
2. Kann die DB( an abstraktionslayer denken und was passiert wenn man
den DB Typ mal wechselt) den gewuenschten HASH erzeugen?
Hinweis:
Die Apps koennen durchaus verschiedene Algorithmen haben was die
generierung einen md5 Hashes angeht. Zum Beispiel sieht ein APR (Apache)
md5 anders aus als der von PHP/Mysql.
Mein Rat waere den Hash von deiner App (php) erzeugen zulassen.
> ist die Rückantwort bei Abfrage, HASH-Wert oder entschlüsseltes
> Passwort.
> Wenn HASH-Wert, wie entschlüssele ich es?
Garnicht das es OneWay ist. Du vergleichst die verschluesselten Werte
und die DB sagt dir ob es nen Treffer gibt-
Sinngemaess
$sql = sprintf("SELECT user from account where username = '%s' and
userpassword = '%s'",
mysql_real_escape_string($eingabe['user']),
mysql_real_escape_string(md5($eingabe['password']))
);
Sofern es da ein Resultset gibt waren die Eingaben richtig.
Beim anlegen dann entsprechend
$sql = sprint("INSERT INTO account (username, userpassword) values('%s',
'%s')",
mysql_real_escape_string('admin'),
mysql_real_escape_string(md5('geheim'))
);
Ich wuerde hier nicht auf die MySQL MD5() Funktion zurueck greifen.
Einer der Gruende warum du nie die Mysql password() Funktion nehmen
solltest ist der das der int. Algorithmus sich geändert beim wechsel auf
4.1. Deine Authentifizierung wuerde nun nicht mehr klappen wenn dein
Benutzer von < 4.1 auf eine akt. Version wechseln. Es gibt ein Extra
Kapitel zum Thema auf dev.mysql.com.
Gruss
Joerg
--
TakeNet GmbH Mobil: 0171/60 57 963
D-97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
Matthias Esken wrote:
> On Wed, 12 Apr 2006 17:16:58 +0200, Frank Schenk wrote:
>
>
>> MySQL ignoriert Groß- und Kleinschreibung bei
>> "SELECT...WHERE FIELD=VALUE"
>
>
> Wenn du es so einstellst, dann ja.
>
http://dev.mysql.com/doc/refman/5.1/en/features.html
....
All data is saved in the chosen character set. All comparisons for
normal string columns are case-insensitive.
....
Mir wär jetzt neu, daß man das Verhalten bei einem Vergleich "=" durch
die Konfiguration verändern kann aber ich lass mich gerne eines besseren
belehren. Ansonsten wäre da noch CAST() was auch das Handbuch vorschlägt.
gruß, Frank
Hallo
Klaus J. Hofmann schrieb:
> Icg finde einfach keine Lösung für die Abfrage von Usernummer und
> Passwort.
Hab mich mit demselben Problem beschäftigen müssen, wie vermutlich jeder
hier irgendwann mal.
Das ist rausgekommen, vielleicht hilft es ja:
http://4haus.de/tips/login.html
(auf die Schnelle etwas formatiert)
Gruß
Irmgard
Frank Schenk wrote:
> Matthias Esken wrote:
>> On Wed, 12 Apr 2006 17:16:58 +0200, Frank Schenk wrote:
>>
>>
>>> MySQL ignoriert Groß- und Kleinschreibung bei
>>> "SELECT...WHERE FIELD=VALUE"
>>
>>
>> Wenn du es so einstellst, dann ja.
>>
>
> http://dev.mysql.com/doc/refman/5.1/en/features.html
>
> ...
> All data is saved in the chosen character set. All comparisons for
> normal string columns are case-insensitive.
> ...
Ich könnte mir gut vorstellen, dass niemand diesen kleinen Absatz seit
MySQL 4.1 geändert hat als Collations eingeführt wurden.
>
> Mir wär jetzt neu, daß man das Verhalten bei einem Vergleich "=" durch
> die Konfiguration verändern kann aber ich lass mich gerne eines besseren
> belehren. Ansonsten wäre da noch CAST() was auch das Handbuch vorschlägt.
Man kann pro Spalte(!) festlegen, welche Collation (für Vergleiche)
benutzt werden soll. Dabei sind Collations, die auf _ci enden, "case
insensitive" und solche, die auf _cs enden, "case sensitive". Zusätzlich
gibt es noch _bin. Dabei werden dann noch gewisse ähnliche Buchstaben
als verschieden angesehen.
Beispielsweise gilt bei utf8_general_ci
u=U=ü=Ü
Bei utf8_bin ist dagegen jeder Buchstabe von jedem verschieden.
u<>U
U<>Ü
Es ist also alles eine Frage der Einstellung.
Grüße
Kai
--
This signature is left as an exercise for the reader.
Kai Ruhnau wrote:
> Man kann pro Spalte(!) festlegen, welche Collation (für Vergleiche)
> benutzt werden soll. Dabei sind Collations, die auf _ci enden, "case
> insensitive" und solche, die auf _cs enden, "case sensitive". Zusätzlich
> gibt es noch _bin. Dabei werden dann noch gewisse ähnliche Buchstaben
> als verschieden angesehen.
>
> Beispielsweise gilt bei utf8_general_ci
> u=U=ü=Ü
> Bei utf8_bin ist dagegen jeder Buchstabe von jedem verschieden.
> u<>U
> U<>Ü
>
> Es ist also alles eine Frage der Einstellung.
Oh, wieder was gelernt, danke. Leider arbeiten wir hier mit veralteten
Versionen und ich war noch nicht gezwungen, mir die Neuerungen näher
anzusehen ;)
happy eastern, Frank
Danke für die vielen Hinweise und Tips.
Das mit dem "OneWay " der Verschlüsselung war mir sofort nach der
Absendung klar, wäre ja keine Sicherheit.
Schönes Osterfest
Hoffi
Klaus J. Hofmann
Radeberg
Bodo Kaelberer wrote:
> Und dann natürlich, hast Du schon aber besser noch mal gesagt, den
> Wert im Statement in '' notieren.
ACK - wqgen SQL-Standard.
> Sonst hast du mindestens einen Syntax-Fehler, wenn jemand ein '
> verwendet.
NACK - mysql_real_escape_string kümmert sich sowohl um ' als auch um ".
Thomas
--
Diese .sig st def kt.
Joerg Behrens wrote:
> Zum Beispiel sieht ein APR
> (Apache) md5 anders aus als der von PHP/Mysql.
Richtig, MD5 ist zwar wohldefiniert, aber die Darstellung kann abweichen.
Der MD5-Algorithmus generiert eine Folge von 16 Bytes. Meistens werden
die in Form von 32 Hex-Ziffern angegeben; Apache verwendet, um kürzere
Strings zu haben (oder warum auch immer) eine base64-ähnliche
Darstellung.
> Mein Rat waere den Hash von deiner App (php) erzeugen zulassen.
[...]
> Ich wuerde hier nicht auf die MySQL MD5() Funktion zurueck greifen.
Jeweils: Warum (nicht)? Das ist beides gehupft wie gesprungen - sofern
das Format stimmt. Wenn es abweicht, muà nur sichergestellt sein, daÃ
alle auf das Feld zugreifende Funktionen die gleiche Methode verwenden.
Thomas
--
>Ich bin anscheinend nicht so geschmacklos, ich habe meine Frau in
>de.talk.romance kennengelernt...
Man sagt "aus de.talk.romance gedownloaded". (K. Koehntopp in d.a.f.u)
Bodo Kaelberer wrote:
>> Aber da ich ja eh demnächst auf md5 umstellen werde, muss ich das dort
>> eh noch einmal prüfen.
>
> Da gilt genau dasselbe.
Was gilt da? Du meinst die GroÃ-/Kleinschreibung? Die Ergebnisse der
üblichen md5-Funktionen sind aber Hexstrings, bei denen ist
GroÃ-Kleinschreibung irrelevant.
Thomas
--
Die Verwendung von mehreren Ausrufezeichen macht die Aussage nicht
ausrufender sondern ausufernder. [Michael Bauer in dnq]
Hi
> Was gilt da? Du meinst die Groß-/Kleinschreibung? Die Ergebnisse der
> üblichen md5-Funktionen sind aber Hexstrings, bei denen ist
> Groß-Kleinschreibung irrelevant.
Stimmt. Hatte ich nie genau angeschaut. Ich dachte, die wären
alphanumn.
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Thomas Rachel am Fri, 14 Apr 2006 17:17:15 +0200:
[Wert im Statement in '' notieren]
> > Sonst hast du mindestens einen Syntax-Fehler, wenn jemand ein '
> > verwendet.
>
> NACK - mysql_real_escape_string kümmert sich sowohl um ' als auch um ".
Mir geht's um folgendes:
SELECT * FROM t WHERE id = $id;
Kommt da ein nicht nummerischer Wert, so hat man einen Syntax-Fehler.
Schreibt man aber:
SELECT * FROM t WHERE id = '$id';
So wird man bei einem nicht nummerischen Wert wahrscheinlich 0
Einträge finden, erspart sich aber den Syntax-Fehler.
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Bodo Kaelberer schrieb:
> Mir geht's um folgendes:
>
> SELECT * FROM t WHERE id = $id;
>
> Kommt da ein nicht nummerischer Wert, so hat man einen Syntax-Fehler.
> Schreibt man aber:
>
> SELECT * FROM t WHERE id = '$id';
>
> So wird man bei einem nicht nummerischen Wert wahrscheinlich 0
> Einträge finden, erspart sich aber den Syntax-Fehler.
Ganz schlechter Stil.
$id = intval($id);
$sql = "SELECT * FROM t WHERE id={$id}";
intval() ist für Ganzzahl-Werte, was mysql_real_escape_string() für
Strings ist.
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----
Niels Braczek am Fri, 14 Apr 2006 21:02:07 +0200:
> > SELECT * FROM t WHERE id = '$id';
> >
> > So wird man bei einem nicht nummerischen Wert wahrscheinlich 0
> > Einträge finden, erspart sich aber den Syntax-Fehler.
>
> Ganz schlechter Stil.
>
> $id = intval($id);
> $sql = "SELECT * FROM t WHERE id={$id}";
>
> intval() ist für Ganzzahl-Werte, was mysql_real_escape_string() für
> Strings ist.
Jetzt nerv Du mich nicht auch noch (-;
Das war nur das naheliegenste Beispiel für einen nummerischen Wert,
das mir gerade eingefallen ist, um zu erklären, warum die
Anführungszeichen auch Sinn machen, um Syntaxfehler zu vermeiden.
Im Übrigen hat intval() den Nachteil, dass dann im Statement nicht
mehr zu sehen ist, welcher Wert eigentlich verwendet werden sollte -
interessant bei Manipulationen an Parametern.
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.
Bodo Kaelberer schrieb:
> Niels Braczek am Fri, 14 Apr 2006 21:02:07 +0200:
>
>> intval() ist für Ganzzahl-Werte, was mysql_real_escape_string() für
>> Strings ist.
>
> Jetzt nerv Du mich nicht auch noch (-;
Muss ich anscheinend ja ;-)
> Das war nur das naheliegenste Beispiel für einen nummerischen Wert,
> das mir gerade eingefallen ist, um zu erklären, warum die
> Anführungszeichen auch Sinn machen, um Syntaxfehler zu vermeiden.
Sie machen außer bei String-Typen keinen Sinn. Das Bedürfnis sie bei
Zahlen zu verwenden, beweist eine mangelhafte Vorbereitung der Daten.
> Im Übrigen hat intval() den Nachteil, dass dann im Statement nicht
> mehr zu sehen ist, welcher Wert eigentlich verwendet werden sollte -
> interessant bei Manipulationen an Parametern.
Das hat man schon vorher abgeprüft.
Außerdem kann man ja den alten Wert aufheben:
$id = intval($orig_id);
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
------------------------------------------------------------ ----
Abend
Niels Braczek am Sat, 15 Apr 2006 00:51:22 +0200:
> > Das war nur das naheliegenste Beispiel für einen nummerischen Wert,
> > das mir gerade eingefallen ist, um zu erklären, warum die
> > Anführungszeichen auch Sinn machen, um Syntaxfehler zu vermeiden.
>
> Sie machen außer bei String-Typen keinen Sinn. Das Bedürfnis sie bei
> Zahlen zu verwenden, beweist eine mangelhafte Vorbereitung der Daten.
Oder ein ausgeprägtes Bedürfnis nach gleichartiger Behandlung - was
beim Programmieren ja gar nicht schlecht ist (-;
Z.B. habe ich Funktionen, die Statements basierend auf übergebenen
Spaltennamen und Werten zusammenbasteln. Da erspare ich es mir gerne,
auch noch für jede Spalte anzugeben, ob ein '' drum muss oder nicht.
> > Im Übrigen hat intval() den Nachteil, dass dann im Statement nicht
> > mehr zu sehen ist, welcher Wert eigentlich verwendet werden sollte -
> > interessant bei Manipulationen an Parametern.
>
> Das hat man schon vorher abgeprüft.
> Außerdem kann man ja den alten Wert aufheben:
> $id = intval($orig_id);
Ja schoooon. Aber da musst Du erst mal ein Handling für machen. Ist
doch bequemer, wenn man einfach das Statement in ein Logfile schreiben
kann.
Gutnacht!
--
1 Bodo Kaelberer
123 http://www.webkind.de/ http://www.kaelberer-aio.de/
3 Dem Verständnis ist meist gut getan, wenn man richtig lesen
4 kann.