kostenloser Webspace werbefrei: lima-city


Sicherheitsfrage $_SESSION und md5

lima-cityForumDie eigene HomepageSicherheit im Internet

  1. Autor dieses Themas

    atraxoo

    atraxoo hat kostenlosen Webspace.

    Hallo Leute :wave:

    Ich habe 2 Fragen zur Sicherheit einer Seite und ich wäre sehr dankbar, wenn ihr mir die beantworten könntet

    1.: Ist md5() wirklich unsicher?

    Ich habe schon gelesen, dass md5 nicht mehr das Sicherste ist, und das man auf andere Methoden ausweichen sollte, weil mit etwas Aufwand ein gleicher Hash erzeugt werden kann.
    Ich frage mich allerdings, wieso es unsicher sein sollte, wenn man, wie in meinem Fall, den md5 - Hash nie zu sehen bekommt. In meinem Fall kann sich ein Benutzer registrieren, sein Passwort wird dann md5 verschlüsselt in die Datenbank geladen und dann eben beim Login wieder abgerufen. Den md5 Hash in der Datenbank bekommt ja niemand zu sehen, also meine Frage, ist md5 dann trotzdem auch in diesem Fall unsicher?

    2.: $_SESSION[]

    Momentan wird bei meiner Seite dem User anhand der Datenbank beim Einloggen eine $_SESSION mit dem Namen status verpasst und deren Inhalt ist dann z.B. 1, 2 oder 3. Im Adminbereich frage ich dann anhand von if($_SESSION['status'] != 3) {exit();} ob der Benutzer auch wirklich Admin, bzw status = 3 hat.
    Meine Frage: Ist diese Methode unsicher? Bzw kann man diese $_SESSION['status '] = 1 irgendwie manipulieren, sodass man aufeinmal status 3 hat?

  2. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

  3. Zu 1.
    Ich würde von md5 eher abraten. Wieso erzeugt man überhaupt Hashes?
    Grundgedanke war: Liest ein Hacker die Datenbank aus, kann er sich trotzdem noch nicht mit den Passwörtern anmelden. Ich bin leider nicht informiert, ob es möglich ist, aus einem gegebenen MD5-Hash ein gültiges Passwort zu berechnen. Aber falls nicht, dauert das vielleicht nicht mehr lange. Und dann wäre die Hashfunktion nutzlos. Ich empfehle daher Verfahren aus der SHA-2 Reihe.

    Und zu 2.
    Das ist so auf jeden Fall sicher. Man kann den Inhalt einer Session nicht einfach so verändern. (Im Gegensatz zu Cookies) Es gibt natürlich Methoden wie Session-Hijacking, also die Session von einem anderen zu klauen. Aber das ist ein anderes Thema.
  4. Autor dieses Themas

    atraxoo

    atraxoo hat kostenlosen Webspace.

    Danke für die schnelle Antwort,

    Zu 1) Ja ok, das macht Sinn, wenn ein Hacker in die Datenbank kommt sieht er natürlich die Hashs.
    sha256 wäre zum Beispiel besser ja?

    Zu 2)
    fuerderer schrieb:

    Das ist so auf jeden Fall sicher.


    Gut dann bin ich ja beruhigt, danke ;-)
  5. Hallo,

    bei md5 ist es inzwischen möglich relativ einfach Kollisionen zu erzeugen, d.h. in deinem Fall ein Passwort zu finden wo
    md5('geheimes_richtiges_Passwort') == md5('vom_Angreifer_erzeugtes_Passwort')
    gilt.

    verwende lieber
    string password_hash ( string $password , integer $algo [, array $options ] )
    und setze auf die in PHP integrierte Passwort-Hashing-API.
    (http://php.net/manual/de/function.password-hash.php)

    Lies dir auch mal Sicheres Password Hashing in PHP durch.

    edit zu Klarstellung: Nö, SHA256 wäre nicht besser (siehe obigen Link).

    Beitrag zuletzt geändert: 29.3.2015 12:00:24 von ikatools
  6. Autor dieses Themas

    atraxoo

    atraxoo hat kostenlosen Webspace.

    Ok vielen Dank werde ich mir mal durchlesen ;)

    Edit
    ikatools schrieb:
    verwende lieber
    string password_hash ( string $password , integer $algo [, array $options ] )
    und setze auf die in PHP integrierte Passwort-Hashing-API.


    zum Beispiel einfach so? password_hash("userpassword", PASSWORD_DEFAULT)

    Beitrag zuletzt geändert: 29.3.2015 12:46:26 von atraxoo
  7. Ja.

    Randbemerkung:
    PASSWORD_DEFAULT steht momentan für den bcrypt-Algorithmus, das kann sich aber in künftigen PHP-Versionen ändern - und damit die Länge des Hashes auch.
    Deswegen: Datenbankfeld groß genug anlegen (empfohlen sind 255 Zeichen) und nicht z.B. auf 60 Zeichen (soviel Zeichen erzeugt bcrypt) beschränken.

    Ich würd auch noch einen Kommentar mit der URL zur Dokumentation von password_hash in den Quellcode packen, auch wegen der Sache mit dem Datenbankfeld...
  8. Autor dieses Themas

    atraxoo

    atraxoo hat kostenlosen Webspace.

    Alles klar mach ich, danke

    ikatools schrieb:

    PASSWORD_DEFAULT steht momentan für den bcrypt-Algorithmus, das kann sich aber in künftigen PHP-Versionen ändern


    Ist es dann sinnvoll statt PASSWORD_DEFAULT gleich brypt zu schreiben? Weil falls es sich ändern sollte, ergibt ja dann PASSWORD_DEFAULT einen anderen hash, was dann dazu führen würde, dass sich die Benutzer nicht mehr anmelden können.
  9. , das wäre sogar kontraproduktiv.

    Der Rückgabewert von password_hash() enthält alle nötigen Informationen:
    $hash = password_hash($password, PASSWORD_DEFAULT);
    $hash ist dabei so aufgebaut:
    [Hash-Algoritmus][Hash-Optionen][salt][hash des Passworts]

    (siehe http://php.net/manual/de/faq.passwords.php#faq.password.storing-salts)

    Du benutzt ja dann boolean password_verify ( string $password , string $hash ) zum Überprüfen, und die Funktion schaut in $hash nach, welcher Hash-Algorithmus usw. genutzt wurde und kann das Passwort so prüfen.

    Ändert sich der Standard-Hashalgorithmus, wird bei neuen Benutzern der neue Algorithmus verwendet, die Rückwärtskompatibelität zu alten Benutzern bleibt aber erhalten (sobald die aber ihr Passwort ändern, wird der neue Algorithmus genutzt und sie profitieren von mehr Sicherheit).
  10. Autor dieses Themas

    atraxoo

    atraxoo hat kostenlosen Webspace.

    Ahh super jetzt versteh ichs!

    Vielen Dank :wink:
  11. m***3

    $string = 'test';
    $salt = 'PasswortSalt';
    
    $hash = hash( 'sha512' , $string.$salt );


    $salt (Salz) in deinem Script ändern!!!

    Gruß mg
  12. Und all das ist nicht gegen Rainbow-Tables gesichert...
    In Zeiten von Botnets, ist die notwendige Leistung solche zu erstellen sicherlich vorhanden.
  13. fsrhalle schrieb:
    Und all das ist nicht gegen Rainbow-Tables gesichert...

    Ein Salt ist bei password_hash mit drin. Was willst du denn noch mehr machen?
  14. muellerlukas schrieb:
    fsrhalle schrieb:
    Und all das ist nicht gegen Rainbow-Tables gesichert...

    Ein Salt ist bei password_hash mit drin. Was willst du denn noch mehr machen?

    Mein Fehler... geht ja um Sessions. Ich war bei Datenbank im Kopf zu Passwörtern geswitcht. Sessions sind ja vermutlich nach einem Angriff eh schon abgelaufen. Für Passwörter kann man nur die DB und den Server immer schön updaten, wenn man kann, auftretende Sicherheitslücken sofort fixen und den Zugang sicher wählen.

    Also ich habe auch schon IPs für Salts verwendet.:king:Nicht alleine, da es ja VPNs und Proxies gibt, aber so kann zum, Beispiel von Lieschen Müller nicht/schlechter die Session übernommen werden.

    Beitrag zuletzt geändert: 25.6.2015 21:55:36 von fsrhalle
  15. Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!

    lima-city: Gratis werbefreier Webspace für deine eigene Homepage

Dir gefällt dieses Thema?

Über lima-city

Login zum Webhosting ohne Werbung!