[Chr!s]

@WarrenFaith: benutz es auf jedenfall mit einem salt, dann ist es "sicher"

Hier könnte man jetzt doch auch noch variieren, oder? Z.B. als Salt das crypt, sha1 md5 wie auch immer vom Usernamen.. das würde ich dann für relativ ( ) sicher halten..

[WarrenFaith]

die aufspaltung eines sha1/md5 ergebnisses und neuzusammensetzung erhöht eigentlich auch nochmal die sicherheit. z.B wenn ich die letzten 10 Zeichen an den Anfang des Hashs packe. Zumindest wären dann die Hash-Datenbanken wirkungslos.
Also vielleicht einen eigenen Algorithmus bauen der den Hash verändert.
Aber wer die Passwörter aus der DB auslesen kann, der kann sie meistens auch setzen... hm, wobei sein eingesetzter Hash dann falsch wäre, wenn man ihn wie oben genannt modifiziert. Dann müsste der Angreifer erst noch den Algorithmus finden und seinen Hash dort durchjagen. Würde alles aber wie immer nur mehr Zeitaufwand für den Angreifer bedeuten, aber sicher wäre es dennoch nicht.
Verflixt

Grundsätzlich ist dieser ganze Thread allerdings ziemlich ... ja, ich sags jetzt mal net. Man sollte vielleicht eher mit den Serveradmin reden, damit es gar nicht erst zum Passwortklau kommt.

MfG Fat Tony

[Waq]

Zitat von Fat Tony

Man sollte vielleicht eher mit den Serveradmin reden, damit es gar nicht erst zum Passwortklau kommt.

Nuja, diese Äusserung offenbart ein komplett fehlendes Verständnis für IT-Sicherheit. Der blosse Gedanke, dass man sich auf ein einziges Sicherheitssystem verlässt und sich dahinter auf das Prinzip Hoffnung verlässt...
Schonmal was vom "single point of failure" gehört?
Oder von Insider-Hacks? Die sind für einen substanziellen Anteil der Hacks verantwortlich. Das ist ja gerade das Schöne an der zerhackten Speicherung der Passwörter: Selbst der Betreiber kommt nicht einfach ran.

Nuja, diese Äusserung offenbart ein komplett fehlendes Verständnis für IT-Sicherheit. Der blosse Gedanke, dass man sich auf ein einziges Sicherheitssystem verlässt und sich dahinter auf das Prinzip Hoffnung verlässt...

Hab ich ja auch net gesagt oder steht das irgendwo in meinem Post? Also ich kanns net finden ... .

Passwörter gehören gehashet, genauso gut gehören Kreditkartennummern nicht auf einen Webserver.

Die Frage ob du jetzt md5, sha1 oder sonstwas zum hashen verwenden sollst, kann dir nur ein Experte sagen oder zumindest jemand der sich mit dem ganzen Zeugs wirklich auskennt und deshalb finde ich auch, dass es wohl nicht sehr viel Sinn macht, hashes zu verketten und Xmal "herumzuhashen", wenn man kA hat, so wie ich auch.

MfG Fat Tony

[Waq]

Was lernen wir daraus? Wenn man undeutlich motzt, fühlt sich der falsche angemotzt

[ex³]

Mein Gott ich hab grad wieder was über Rainbow Tables, mod5, sha1 gelesen. So wie ich das sehe geht da gar nichts mehr. Ich muss auch dazu sagen das ich mich da ziemlich hilflos fühle, obwohl es doch mein bestreben möglichst nicht so locker von der Hand zu programmieren.

Also folgendes hab ich festgestellt. Wenn man ein passwort hash in der db speichert ist das nicht gut. man sollte also für md5 oder sha1 ein salt dazugeben. Allerdings was könnte das sein? Ich kann ja nicht irgendwelches Zeug beim erstellen das Passworts mitreinmachen, da bei der Passwortabfrage die gleichen Daten benötigt werden damit ein übereinstimmender Hash zuammenkommt.

[Lars]

Registrierdatum des Users z.B. oder die verwendete IP-Adresse bei der Registierung. Irgendwas, das nicht bei allen gleich ist.

[ex³]

ja gut aber wenn sich der User anmelden will dann bekomm ich doch nur den Passwort hash, aber der stimmt ja dann nicht überein mit dem Hash aus der Datenbank.

Ich bräuchte doch dann die gleichen Infos wie bei der Registrierungen um den passenden Hash zu bekommen, aber das geht doch nicht.

[Lars]

Man speichere den Zeitpunkt der Registrierung irgendwo ab, rufe ihn beim Loginversuch auf und verwende ihn als Salt

[$traight-$hoota]

das finde ich ja mal net schlecht...
nix md5 oder SHA-1 sondern SHA-512
nice
siehe auch das hier

[Waq]

Zitat von WarrenFaith

die aufspaltung eines sha1/md5 ergebnisses und neuzusammensetzung erhöht eigentlich auch nochmal die sicherheit.

Nur unter der Annahme, dass der Angreifer an die Datenbank kommt, aber nicht an den PHP-Quellcode.

Zitat von ex³

ja gut aber wenn sich der User anmelden will dann bekomm ich doch nur den Passwort hash

Den Salt speichert man ebenfalls ab, und zwar getrennt.
Bei den crypt()-Algorithmen sind es einfach die ersten 2, 12 oder 16 Zeichen der Rückgabe (je nach Algorithmus).

[ex³]

Ich komm grad echt nicht drauf...
Klassisch läuft das doch so ab ohne jetzt mal auf injections oder reg globals zu achten:

PHP-Code:

$query = "SELECT userid FROM user WHERE pwd = '".md5($pass)."' AND name = '".$name."'"; 


Nehme ich beispielsweise nun einen timestamp als Salt wie komme ich daran? Vom User hab ich nur Name und Passwort wie also hole ich bei der Abfrage das regdatum damit ich einen passenden hash bauen kann der mit dem in der DB übereinstimmt?

[WarrenFaith]

Du checkst den Timestamp und den pass-hash des Users $name ab und machst dann damit den $pass-hash und checkst ob $pass-hash(login) == pass-hash(db)

[Lars]

SELECT
  id
FROM
  tbl__users
WHERE
  name = 'username'
    AND
  password = MD5('passwort' + `regDate`);

So oder so ähnlich

[ex³]

Ah ja so läuft das...dazu noch ein paar Fragen

1. Sehe ich das also richtig das ich in der WHERE Bedingung, Werte aus der Tabelle verwenden kann? Anders komme ich ja nicht an das regdate oder?
2. Ich muss das SQL MD5() benutzen, weil anders kann ich ja nicht auf das regdate zugreifen um den passenden Hash zu bauen, oder?

[WarrenFaith]

hast beide fragen selbst beantwortet. lass einfach das "oder?" weg

[ex³]

Ok danke für die Hilfe.
Ich muss schon sagen durch das was ich so gelesen habe die letzten Tage mit Rainbow Tables und md5 bin ich doch schon etwas erschüttert. Nun ja das mit dem Salt kann man in seinem Projekt ja variieren wie man will...mal sehen wie lange es dauert bis das ausgehebelt wurde.

[Chr!s]

Ich grab den Thread mal wieder aus, und frag euch:
was haltet ihr hiervon? (SHA256 implementation für PHP)
http://dev.barad-dur.nl/sha256/index.php

Rein Theoretisch: Wäre das in Verbindung mit (einem) Salt sicherer als sha_1 mit einem Salt?

[Bookworm]

Ich weiß es ja nicht, aber imho sind gehashte oder verhschlüsselte Passwörter in Datenbanken doch eigentlich nonsens, oder? Ich meine, wenns ein Hacker soweit schafft, da nützt auch eine Verschlüsselung nichts mehr... Denn dann kann er auch den Wert des Feldes beliebig manipulieren...
Der einzige Vorteil ist, das er die Passwörter nicht sieht, aber was nützt ihm das? Ich meine, sicherheitsbewusste Menschen benutzen bei jeder Anwendung ein anderes Kennwort, da nützt einem ein einzelnes doch überhaupt nichts...

Entschuldigt mich, wenn das nicht stimmt, aber das war der Ergebnis von einer ICQ Sitzung mit nem anderen, etwas erfahreren (als ich ) PHP-Coder...