nedelin

Stimmt, doch der Punkt ist obsolet; ich zitiere Dich:

Ja, Fall b) ist das Extrem. Gerade darum glaube ich nicht, dass es ausreichend ist, die Website mit ein paar "wenigen Requests" zu bemühen, um an interessante Daten heranzukommen. Jedenfalls dann nicht, wenn man löchrige Skripte, schlechtes Software-Design oder dergleichen mal aussen vor lässt.

Wie gesagt, in der Praxis sieht's oft anders aus. Hier gibt's zahlreiche Grautöne.

Das hat doch auch niemand behauptet... warum ist es Dir so wichtig, diesen Punkt immer wieder zu betonen? Ich dachte, wir diskutieren über MD5 und Salts im Speziellen, nicht um das Thema "Sicherheit" im Allgemeinen. Ich glaube, in diesem Unterforum hat diesbezüglich kaum jemand Nachhilfe nötig

Ja, darum sollte man auch das Verhältnis zwischen Aufwand und Nutzen (von Sicherheitsvorkehrungen) im Auge behalten. Das Schöne an dem Ganzen ist: es bleibt stets spannend.

dr. ?

Mister Ad

mepeisen

Ich betone das deswegen jedesmal, weil ich oft genug gefragt werde, warum es keine totale Sicherheit gibt. Oder warum es aufwändig ist. Und weil ich oft genug erlebe, mit welcher Naivität Menschen heutzutage vorgehen nur um dann laut zu schreien, wenn bereits das Kind in den Brunnen gefallen ist.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

fireweasel

Dann wäre aber die Frage "Wie sicher ist MD5 wirklich?" hier unpassend, weil MD5 ein Hashing-Algorithmus ist, für dessen sichere Funktion (wie in "safety") so etwas wie "Sicherheit" (wie in "security") vollkommen irrelevant ist.

Weil Sicherheit ein Prozess ist und kein Zustand. Diesen Unterschied kapieren viele nicht. Bei denen ist Sicherheit so etwa wie ein Vorhängeschloss: Das schnappt zu und damit ist die Sache sicher. Muss sie doch, beim Vorhängeschloss klappt das doch auch ...

Und aus betriebswirtschaftlicher Sicht sollte es in den allermeisten Fällen ausreichen, den Aufwand für einen Angreifer so hochzutreiben, dass das Restrisiko von einer Versicherung übernommen wird oder selbst getragen werden kann. Darauf wolltest du mit deiner Prozent- und Private-Website-Argumentation sicher hinaus.

http://www.ne.anl.gov/capabilities/v...ls/maxims.html
(62 bis 67)

Die brauche ich nicht. Ich hab mir ja eine Kopie der Festplatte gezogen. Da sind alle Daten unverschlüsselt drauf. Wen interessieren da noch wie auch immer gehashte Passwort-Listen?

Ich wollte eigentlich nur darauf hinweisen, dass man (mit PHP-Script-Bastelei) nur für einen Angriff von außen (also über die Website) vorsorgen kann. Da ist ein zufällig gewähltes Salt pro Benutzer ausreichend (und wichtig), weil das den Angreifer dazu zwingt, sich für jeden Benutzer eine neue Rainbowtable bauen zu müssen. Alle weiteren Maßnahmen der Passwortbehandlung dienen höchstens zur Verschleierung ("security by|through obscurity), bieten aber keinen zusätzlichen Schutz.

__________________
Wir schreiben schließlich Code und malen keine ASCII-Bilder.

nikosch

Den Absatz verstehe ich nicht.
Den Witz auch nicht. Gerade dagegen hilft es ja, nur md5-gehashte Passwörter in die DB zu legen. Da kann dann auch der Pförtner nichts dran ändern.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

DEdK4ever

Frage am Rand:
Kann ich mich mit einer Verschlüsselung wie

Client:
Übertragener Wert = hash( hash( Passwort ) + Zufälliger Wert )
Server
hash( Gespeicherter Passworthash + Übertragener Zufallshash ) == Übertragener Wert

Sicher wähnen, oder lieber nicht?

nikosch

MD5 ist keine Verschlüsselung. Das sollte jetzt langsam mal klar sein.

Und der Terminus „sicher“ wurde jetzt hinreichend dargelegt.

[MOD: Thread geschlossen]

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--