Webseite gehackt

[franktron]

Hallo alle miteinander ich möchte mal ein Szenario durchgehen um das besser zu verstehen.

Also wir nehmen an das unser Webserver gehackt wurde, jetzt hat der Hacker ja zugriff auf den Server kann alose die PHP Dateien und die DB Sehen.
Aber was bringt dann das PW Hash+Salt wenn er doch den Code sehen kann.

[Bernhard Geyer]

Zitat:

Zitat von franktron (Beitrag 1234096)

Aber was bringt dann das PW Hash+Salt wenn er doch den Code sehen kann.

Wenn er sich die DB gezogen hat braucht er keine Hashes mehr. Er hat ja alles was er will. Außer dem PW. Denn die Funktion Hash + Salt ist nicht umkehrbar.
Ich würde trotzdem alle Kunden informieren das eingebrochen wurde und alles PW trotzdem zurücksetzen.

[arnof]

i.d.R. sollte es so sein, das er damit noch nicht das Passwort hat.

Er müsste solange die Passwörter durchtesten bis ein Hash passt.

[sx2008]

Deine eigentliche Frage ist also "Was bringt das Salt beim Hashen eines Passworts" wenn ich das richtig verstanden habe?

Übrigens ist der Anfangstitel dieses Threads falsch geschrieben. Versuch mal ob du das nicht ändern kannst.

[Daniel]

Zitat:

Zitat von sx2008 (Beitrag 1234102)

Übrigens ist der Anfangstitel dieses Threads falsch geschrieben. Versuch mal ob du das nicht ändern kannst.

Das habe ich eben erledigt. ;-)

[Mavarik]

ich hatte das vor Jahren auch mal auf meinem Server...

Der Hacker hat im Bootloader ein Teil der Festplatte reserviert (Unsichtbar für Windows) und einen Keylogger.
Im unsichtbaren Teil wurden Dateien für Filesharing hinterlegt und mein Traffic ist explodiert!

Mavarik

[franktron]

Zitat:

Zitat von Daniel (Beitrag 1234103)

Zitat:

Zitat von sx2008 (Beitrag 1234102)

Übrigens ist der Anfangstitel dieses Threads falsch geschrieben. Versuch mal ob du das nicht ändern kannst.

Das habe ich eben erledigt. ;-)

Danke fürs ändern.

Und ja was bringt Salt und Hash wenn der Hacker doch weis wie der HASH aufgebaut wird.

Dann kann er doch ganz schnell ein Algo bauen und muss nur noch durch Testen.

Und das ganz ist nicht passiert ich will nur Vorsichtmastnahmen treffen wenn das passieren soll, und deshalb das ganz besser Verstehen.

[Meflin]

Zitat:

Zitat von franktron (Beitrag 1234122)

Und ja was bringt Salt und Hash wenn der Hacker doch weis wie der HASH aufgebaut wird.
Dann kann er doch ganz schnell ein Algo bauen und muss nur noch durch Testen.
Und das ganz ist nicht passiert ich will nur Vorsichtmastnahmen treffen wenn das passieren soll, und deshalb das ganz besser Verstehen.

Salt schützt vor allem davor, dass bereits vorberechnete Rainbow-Tables verwendet werden können, was das "knacken" der Passwörter zu einer Sache von Sekunden machen würde. So müsste der Angreifer erst eine spezielle Rainbow-Table mit dem Salt aufbauen, was teuer ist. Noch besser wird es dann offensichtlich, wenn du für jeden User einen eigenen Salt verwendest. Denn dann müsste der Angreifer für jeden einzelnen Hash eine eigene Rainbow-Table aufbauen, was schlicht nicht praktikabel ist. Und ohne die Rainbow-Tables bleibt eben nur ein stupider Brute-Force-Angriff... was ebensowenig praktikabel ist.

[himitsu]

Das Stalz schützt vorallem die Kunden, denn Viele verwenden fast überall das selbe Passwort.

Derjenige, welche jetzt die versalzenen Hashs der Passwörter besitzt, kann sich nun nicht so leicht auch in andere Systeme schleichen.
Es gibt ja leider immernoch große Webseiten, welche die Passwörter im Klartext zu speichern scheinen (irgendeine Seite hatte mir mal vor einer Weile mein Passwort zugeswchickt, als ich auf "Passwort vergessen" klickte).

Mit diesem Passwort und den anderen persönlichen Daten kann man sich nun sehr leicht die Zugriffsdaten für andere Webseiten/Systeme zusammenstellen. das Zählt dann bestimmt schon zum Social Hacking.

[franktron]

Was ich mich frage wie schützt man den PHP Code, sodass ihn keiner mehr lesen kann.

[hstreicher]

a) Garnicht , ist ja eine interpretierte Sprache , da gibt's nur Obfuskatoren

b) Compilieren http://en.wikipedia.org/wiki/HipHop_for_PHP

[himitsu]

Zitat:

Zitat von hstreicher (Beitrag 1234146)

a) Garnicht , ist ja eine interpretierte Sprache , da gibt's nur Obfuskatoren

Die Funktion bleibt dennoch die Selbe.

- es wird da eventuell nur nutzloser Zusatzcode eingeschoben
- Bezeichner von Variablen und Funktionen werden wirre umbenannt
- und code wird "verschlüsselt", gepackt und zur Laufzeit wieder entpackt, entschlüsseln und per Eval ausgeführt.

Ja, so kann man den PHP-Code "erstmal" nicht mehr lesen, aber genauso, wie der Interpreter, kann man sich das auch selber zurückübersetzen.

[Meflin]

Zitat:

Zitat von franktron (Beitrag 1234144)

Was ich mich frage wie schützt man den PHP Code, sodass ihn keiner mehr lesen kann.

Gegenfrage: was soll das bringen?

[franktron]

Zitat:

Zitat von Meflin (Beitrag 1234162)

Zitat:

Zitat von franktron (Beitrag 1234144)

Was ich mich frage wie schützt man den PHP Code, sodass ihn keiner mehr lesen kann.

Gegenfrage: was soll das bringen?

Dem Hacker das leben schwer machen und den eigenen Code schützen

[Bernhard Geyer]

Zitat:

Zitat von franktron (Beitrag 1234144)

Was ich mich frage wie schützt man den PHP Code, sodass ihn keiner mehr lesen kann.

[OT]Ist nicht ein Key-Feature der Sprache das dies das normale Ergebnis von PHP-Entwicklung ist? :-)[/OT]

[BUG]

Zitat:

Zitat von franktron (Beitrag 1234096)

Aber was bringt dann das PW Hash+Salt wenn er doch den Code sehen kann.

Es geht darum, die Passworte des Benutzers zu schützen. Die meisten Leute benutzen das gleiche Passwort für alle/viele Dienste.
Wenn in deiner Datenbank auch eine eMail-Adresse steht, kommt der Hacker bei einem großen Teil der Leute auch an ihr eMail-Konto ... was meist der Schlüssel zu sämtlichen anderen Online-Aktivitäten ist.
In einem industriellen Umfeld ließe sich mit einem erbeutetem eMail-Konto sicher auch einiges an Schaden anrichten.

Zitat:

Zitat von arnof (Beitrag 1234101)

Er müsste solange die Passwörter durchtesten bis ein Hash passt.

Was bei den meisten Hashfunktionen nicht das größte Problem ist.
Hier wurde das wichtigste schonmal gesagt. Insbesondere, wenn die zu erbeutenden Identitäten etwas wert sind, sollte man beim Speichern der Passworte vorsichtig sein.

Ein Fehler wäre es, ein Passwort

• im Klartext
• ungesalzen gehasht
• mit einem für die Datenbank festen Salt gehasht
• mit einer ressourcensparenden Funktion gehasht

zu speichern.

Deswegen: bcrypt, scrypt oder PBKDF2 mit einer der Sicherheit angemessenen Anzahl an Runden verwenden.
bcrypt gibt es zB. hier für PHP von der Community, die auch hinter John the Ripper steckt.

[grl]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1234191)

[OT]Ist nicht ein Key-Feature der Sprache das dies das normale Ergebnis von PHP-Entwicklung ist? :-)[/OT]

*lach* - da hab ich jetzt instinktiv den "Gefällt mir" Button gesucht....

GRL

[Dalai]

Zitat:

Zitat von franktron (Beitrag 1234188)

Zitat:

Zitat von Meflin (Beitrag 1234162)

Zitat:

Zitat von franktron (Beitrag 1234144)

Was ich mich frage wie schützt man den PHP Code, sodass ihn keiner mehr lesen kann.

Gegenfrage: was soll das bringen?

Dem Hacker das leben schwer machen und den eigenen Code schützen

Dann mach das, indem du deinen Server ordentlich absicherst. Ich halte es generell für eine schlechte Idee, die Symptome behandeln zu wollen (PHP-Code schützen), wenn man lieber an der Ursache ansetzen sollte bzw. muss (Einbruch in den Server verhindern).

Davon abgesehen glaube ich nicht, dass Leute, die in Server einbrechen, Interesse an irgendeinem Code haben. Die sind eher dahinter, Malware bei einem Einbruch zu hinterlegen, um möglichst viele Opfer zu erreichen. Klar, es gibt solche und solche Einbrecher. Aber in der Regel geht es doch darum, noch mehr Rechner (dann Clients) zu kapern, um die zu einem Botnetz zu machen, um damit entweder Geld zu verdienen (Botnetz "vermieten") oder es selbst zu einem Angriff auf irgendein Ziel zu benutzen.

MfG Dalai