Die sichersten Arten des Logins

[nap]

Hallo.

Ich würde gerne mal wissen was die sichersten Methode(n) sind für ein Login.

Welche Technik?
Wo die Passwörter und Namen ablagern? (Dateien, Datenbanken oder ...)

Mir fällt gerade nur ein so mach ich es immer:
Passwort abfrage per PHP name udn pw in einer datei ausgelagert wie zum bsp. pws.inc.php oder so, Cookie wird gesetzt und anschließend wird man weitergeleitet zu den Seiten. Auf den Seiten wird geprüft ob cookie vorhanden if ja alles anzeigen if nein zurück zur loginseiten + variable die per get ausgelesen wird und dadurch wird ne Fehlermeldung angezeigt.

mfg

nap

[Bio]

Sup!

Am sichersten ist bestimmt, wenn man nicht PHP benutzt ;-)

*scnr*

Gruesse,

Bio

[Daniel (nun registriert)]

und wenns mal probleme mim php interpreter gibt, dann kann man einfach die datei ziehen, oder?
aus diesem grund und aufgrund des komforts bevorzuge ich die db variante.
zu den cookies:
man soltle natürlich nicht nur prüfen, ob ein cookie vorhanden ist, sondern auch ob die daten richtig sind, aber nehme mal an das meintest du?
worauf man noch achten sollte, ist die verschlüsselung und das diese im cookie bzw. beim autologin anders genutzt wird als es in der db steht, so dass es, falls jmd. an die db kommt, nicht möglich ist einfach entsprechende cookies zu erstellen, sondern erst einmal die passwörter cracken muss.
passwörter mehrfach verschlüsseln, z.b. md5("test") wäre sehr einfach zu knacken aber wendet man md5 nochmal auf das ganze an, müsste man ein  passwort mit 32 zeichen knacken, da stoßen dann selbst z.b. im netz verfügbare rainbow tables an ihre grenzen - außer der angreifer hat enormes glück und findet ne kollision.
ansonsten gibt es wohl zur zeit bessere one way verfahren als md5, habe mich allerdings noch nicht damit auseinandergesetzt welche das in php sind, vor allem da z.b. 2 oder mehrmal md5() in der praxis seinen zweck voll erfüllen dürfte.

[nap]

und wenns mal probleme mim php interpreter gibt, dann kann man einfach die datei ziehen, oder?

okay das ist schecht -> werd ich unterlassen

aus diesem grund und aufgrund des komforts bevorzuge ich die db variante.

okay -> werd ich verwenden

zu den cookies:
man soltle natürlich nicht nur prüfen, ob ein cookie vorhanden ist, sondern auch ob die daten richtig sind, aber nehme mal an das meintest du?

nee meinst du die daten die ich dem cokkie gegeben habe?
also setcookie($name,"DATEN") ?

worauf man noch achten sollte, ist die verschlüsselung und das diese im cookie bzw. beim autologin anders genutzt wird als es in der db steht, so dass es, falls jmd. an die db kommt, nicht möglich ist einfach entsprechende cookies zu erstellen, sondern erst einmal die passwörter cracken muss.

Wie mach ich das?
Also soll ich das PW und User verschlüsselt ins cookie schreiben?
Auslesen entschlüsseln?

passwörter mehrfach verschlüsseln, z.b. md5("test") wäre sehr einfach zu knacken aber wendet man md5 nochmal auf das ganze an, müsste man ein  passwort mit 32 zeichen knacken, da stoßen dann selbst z.b. im netz verfügbare rainbow tables an ihre grenzen - außer der angreifer hat enormes glück und findet ne kollision.
ansonsten gibt es wohl zur zeit bessere one way verfahren als md5, habe mich allerdings noch nicht damit auseinandergesetzt welche das in php sind, vor allem da z.b. 2 oder mehrmal md5() in der praxis seinen zweck voll erfüllen dürfte.

Okay wie veranstalte ich das ganze? Hab bisher alles gemacht mti PHP bis auf Verschlüsselungen bzw. Sicherheit von Logins und sowas.

THX

bye

nap

[Daniel (nun registriert)]

kleine anmerkdung zu md5:
es ist keine richtige verschlüsselung, sondern ein one way (nicht reversibles) hash verafhren, man erhält als ausgabe immer einen 32 zeichen langen string.

nee meinst du die daten die ich dem cokkie gegeben habe?
also setcookie($name,"DATEN") ?

ich meine, dass du nicht nur prüfst, ob der nutzer ein cookie "DATEN" hat, sondern auch prüfst, ob ein entsprechender nutzer (mit richtigen pass natürlich) in der db vorhanden ist.

Also soll ich das PW und User verschlüsselt ins cookie schreiben?

Ich würds unverschlüsselt eine User ID statt einem Usernamen speichern. Das Passwort natürlich verschlüsselt.

Beispiel:
Ein Nutzer registriert sich. Das Passwort speicherst du verschlüsselt in der DB, verschlüsseln geht z.b. per MD5: http://de.php.net/manual/en/function.md5.php
ganz einfach $pass=md5($_POST[pass]);
und dann gleich nochmal:
$pass=md5($pass);

Grund:
Nehmen wir als Beispiel das Passwort "test".
Verschlüsselt ergibt dies "098f6bcd4621d373cade4e832627b4f6"
(kannste z.b. unter http://scriptserver.mainframe8.com/md5.php machen oder halt selbst n php script schreiben)
Das lässt sich relativ leicht per BruteForce knacken.
Hierbei werden z.B. alle Kombinationen mit 1-4 Buchstaben mit MD5 verschlüsselt und anschließend mit dem verschlüsselten Passwort, also "098f6bcd4621d373cade4e832627b4f6", verglichen (wie gesagt, md5 ist one way, d.h. lässt sich nicht einfach umkehren). aufgrund der (für einen modernen PC) geringen menge an kombinationen ist sowas innerhalb 1,2 minuten erledigt.
wäre nun jedoch das Passwort "test" 2mal verschlüsselt, d.h.

1. md5("test") --> 098f6bcd4621d373cade4e832627b4f6
2. md5("098f6bcd4621d373cade4e832627b4f6") --> fb469d7ef430b0baf0cab6c436e70375

Wollte man dieses zweimal verschlüsselte Passwort knacken, müsste man alle Kombinationen von 1-32 zeichen ausprobieren - und das sind wesentlich mehr als bei 1-4 zeichen. und dann hätte man auch erst "098f6bcd4621d373cade4e832627b4f6", also das einmal verschlüsselte passwort "test", das man dann wiederrum knacken müsste (das geht nun schnell, aber ist ja nur n beispiel und n passwort mit 32 zeichen zu knacken dürfte jahre dauern, gibt genug tools dafür, kannst es ja mal selbst testen).

wie du evtl. bemerkt hast, beziehe ich mich hier auf angriffe direkt auf den inhalt einer datenbank. beim login musst du natürlich das eingegebene ebenfalls zweimal verschlüssen und mit dem inhalt der datenbank vergleichen, hier müsste ein angreifer dann nur 1-4 zeichen ausprobieren - allerdings übers netz, was bekanntlich wesentlich länger dauert, und du könntest eine ip ja nach z.b. 3 falschen eingaben blocken, sprich praktisch ist sowas nicht rentabel.

nochmal zur übersicht:
registrierung: eingegebenes passwort z.b. 2x verschlüsseln, in der db speichern
login: eingegebenes passwort 2x verschlüsseln und mit dem inhalt der db vergleichen (ist ja bereits 2mal verschlüsselt!)

für cookies/autologin könntest du das ganze z.b. 3 mal verschlüsseln und/oder einen salt hinzufügen. ein salt ist nicht weiter als zusätzliche daten zum passwort, z.b. könntest du als salt "longlong" festlegen.
nehmen wir unser 2x verschlüsseltes passwort "test" von oben:
"fb469d7ef430b0baf0cab6c436e70375"
wir fügen dem ganzen nun den salt hinzu:
"fb469d7ef430b0baf0cab6c436e70375longlong"
das verschlüsseln wir nun mit md5:
"992b808d42f508b41b59f3529326b494"

das könntest du nun in einem cookie speichern.
sollte nun jmd. an die komplette datenbank gelangen, kann er die passwörter nun nicht nutzen, ohne sie zuvor zu knacken. würde das cookie ganz normales das 2x verschlüsselte passwort enthalten, könnte der angreifer das cookie einfach selbst erstellen!
so ist ihm dies nicht möglich, obwohl er die datenbank besitzt.
und was für einen salt du hinzugefügt hast bzw. das du noch ein weiteres mal verschlüsselt hast, das ist an der db ja auch nciht ersichtlich, denn der code dazu befindet sich in den php dateien, und an diese zu kommen ist nocheinmal ein ganzes stück schwieriger.

beim autologin musst du dann natürlich bedenken, dass das verschlüsselte passwort nicht gleich dem in der db ist - einfach das verschlüsselte passwort aus der db auslesen, und das selbe machen wie fürs cookie: "longlong" dranhängen, mit md5 verschlüssen und mit dem inhalt des cookies vergleichen.

hört sich übrigens alles etwas kompliziertes an als es ist, das verschlüsseln des passworts ist absolut kein aufwand, bringt aber sicherheitsmäßig einiges.

[nap]

Uff, erstmal vielen Dank das du dir soviel Mühe gibst.
Das ist ja en ganzer Text auf einmal..

Mit dem Login und der Registrierung hab ich verstanden. Supi, danke!
Mit dem Autologin muss ich nochmal was vertiefen.

mfg und _Danke_

Nap

[Sven Rautenberg]

Moin!

Ein Nutzer registriert sich. Das Passwort speicherst du verschlüsselt in der DB, verschlüsseln geht z.b. per MD5: http://de.php.net/manual/en/function.md5.php
ganz einfach $pass=md5($_POST[pass]);
und dann gleich nochmal:
$pass=md5($pass);

Was vollkommener Schwachsinn ist!

Grund:
Nehmen wir als Beispiel das Passwort "test".

Das ist erstens zu kurz, um sicher zu sein, und außerdem noch durch Wörterbuchattacken erratbar. Dagegen sichert man sich, indem man im Passwort eine Mindestlänge fordert, und neben kleinen Buchstaben auch noch große Buchstaben, Zahlen oder Sonderzeichen.

Verschlüsselt ergibt dies "098f6bcd4621d373cade4e832627b4f6"
(kannste z.b. unter http://scriptserver.mainframe8.com/md5.php machen oder halt selbst n php script schreiben)
Das lässt sich relativ leicht per BruteForce knacken.

Das läßt sich nur deswegen per Brutforce knacken, weil du ein so schlechtes Passwort erlaubt hast.

Hierbei werden z.B. alle Kombinationen mit 1-4 Buchstaben mit MD5 verschlüsselt und anschließend mit dem verschlüsselten Passwort, also "098f6bcd4621d373cade4e832627b4f6", verglichen (wie gesagt, md5 ist one way, d.h. lässt sich nicht einfach umkehren). aufgrund der (für einen modernen PC) geringen menge an kombinationen ist sowas innerhalb 1,2 minuten erledigt.

Du hast keine Ahnung, von was du sprichst, oder?

Gewiß ist es recht simpel, einfach bei "aaaa" anzufangen, alle daraus resultierenden MD5-Strings zu erzeugen, und abzuwarten, bis der gewünschte String rauskommt.

Aber genauso einfach ist es, einfach das vier Zeichen lange Passwort als Loginversuch zu verwenden - das Loginsystem wird sich schon melden, wenn es das Passwort als korrekt erkannt hat.

wäre nun jedoch das Passwort "test" 2mal verschlüsselt, d.h.

1. md5("test") --> 098f6bcd4621d373cade4e832627b4f6
2. md5("098f6bcd4621d373cade4e832627b4f6") --> fb469d7ef430b0baf0cab6c436e70375

Das Passwort doppelt durch MD5 zu jagen bringt gar nichts. Denn du kannst weiterhin diese vier Zeichen als Passwort im Login eingeben - und das ist weiterhin recht schnell herausgefunden.

Umgekehrt bringt es dir recht wenig, wenn du den 32-Zeichen-Hex-String nochmal durch MD5 jagst, weil du pro Zeichen nur 16 verschiedene Möglichkeiten hast - die Auswahlmenge ist im Vergleich zu einem echten 32-Zeichen-String mit allen möglichen Zeichen deutlich kleiner.

Wenn du also monierst, dass das Passwort zu kurz ist, mußt du auch monieren, dass die Zeichenauswahl eines MD5-Strings zu klein ist, um wirkliche Sicherheit zu produzieren.

Im Gegenteil reduziert deine Vorgehensweise sogar die Sicherheit bei den Passworten, die durch ihre Länge und Zeichenwahl deutlich sicherer sind, weil sie mehr als 2^128 verschiedene Kombinationen enthalten können.

Wollte man dieses zweimal verschlüsselte Passwort knacken, müsste man alle Kombinationen von 1-32 zeichen ausprobieren - und das sind wesentlich mehr als bei 1-4 zeichen. und dann hätte man auch erst "098f6bcd4621d373cade4e832627b4f6", also das einmal verschlüsselte passwort "test", das man dann wiederrum knacken müsste (das geht nun schnell, aber ist ja nur n beispiel und n passwort mit 32 zeichen zu knacken dürfte jahre dauern, gibt genug tools dafür, kannst es ja mal selbst testen).

Du behauptest hier Dinge, ohne den Beweis anzutreten. Deshalb widerspreche ich deiner Darstellung einfach mal.

Es ist für das Speichern eines Passwortes absolut irrelevant, ob das im Klartext, mit MD5, mit SHA1, mit doppeltem MD5 oder ROT13 passiert. Entscheidend für die Sicherheit ist, dass das Passwort vom User selbstverständlich immer im Klartext eingegeben wird, der Prüfmechanismus kann also so komplizierte und lange Strings produzieren, wie er will - das hindert einen Angreifer nicht, zu kurze Klartextpassworte durch Ausprobieren im Login herauszufinden.

wie du evtl. bemerkt hast, beziehe ich mich hier auf angriffe direkt auf den inhalt einer datenbank. beim login musst du natürlich das eingegebene ebenfalls zweimal verschlüssen und mit dem inhalt der datenbank vergleichen, hier müsste ein angreifer dann nur 1-4 zeichen ausprobieren - allerdings übers netz, was bekanntlich wesentlich länger dauert, und du könntest eine ip ja nach z.b. 3 falschen eingaben blocken, sprich praktisch ist sowas nicht rentabel.

Es ist für einen Angreifer, der in einer Datenbank MD5 als Passwort vorfindet, praktisch unmöglich, daraus wieder die Originalen Passworte herzustellen. Da würde man extrem viel Rechenzeit sinnlos drauf verschwenden, ohne wirklich Erfolge zu haben. Mit Zufallstreffern kann es dabei immer sein, dass ein längeres Passwort zufällig genau den identischen MD5-Wert liefert, wie ein Passwort mit nur genau einem Zeichen, was natürlich sehr schnell gefunden wäre.

Außerdem wäre noch zu klären, wie der Angreifer denn an den Passwort-Hash kommen kann. Was sagt so ein Vorfall über die Sicherheit?

hört sich übrigens alles etwas kompliziertes an als es ist, das verschlüsseln des passworts ist absolut kein aufwand, bringt aber sicherheitsmäßig einiges.

Das verschlüsselte Ablegen des Passwortes bringt sicherheitsmäßig nach außen relativ wenig. Es hilft, gegen befugte Augen die Passworte zu verschleiern (wer als Admin weiteren Adminkräften nicht traut) - es ändert nichts an der Möglichkeit, von außen über den regulären Login-Mechanismus zu bruteforcen. Und es ändert nichts an der Tatsache, dass die Passworte letztendlich doch per Klartext zur Prüfroutine gelangen müssen, und an dieser Stelle abfangbar sind. Man könnte also, wenn man wollte, einfach an dieser Stelle die Accountdaten anzapfen, ohne sich auch nur einen Deut um doppeltes, dreifaches oder tausendfaches MD5 zu scheren.

- Sven Rautenberg

[Daniel (nun registriert)]

Hallo Sven,

wie ich bereits geschrieben habe, ist das Passwort "test" nur ein Beispiel! Mir ist klar das sowas nicht sicher ist und per Dictionary Attack ohne weiteres zu knacken ist, auch wenn man nur Zugriff auf den Login hat.

"Dagegen sichert man sich, indem man im Passwort eine Mindestlänge fordert, und neben kleinen Buchstaben auch noch große Buchstaben, Zahlen oder Sonderzeichen."
->Technisch/Mathematisch gesehen ist ein längeres Passwort besser als ein kürzeres mit Sonderzeichen. Mit Sonderzeichen lychen einen wahrscheinlich die Besucher der Seite, die Allgemeinheit ist ja allgemein faul und hat von Sicherheti null Ahnung, das wissen wir wahrscheinlich beide. Ansonsten stimme ich dir natürlich zu, das es sicherer wäre.

"Das läßt sich nur deswegen per Brutforce knacken, weil du ein so schlechtes Passwort erlaubt hast."
->War wie gesagt ein Beispiel, recht haste natürlich trotzdem.

"Gewiß ist es recht simpel, einfach bei "aaaa" anzufangen, alle daraus resultierenden MD5-Strings zu erzeugen, und abzuwarten, bis der gewünschte String rauskommt.

Aber genauso einfach ist es, einfach das vier Zeichen lange Passwort als Loginversuch zu verwenden - das Loginsystem wird sich schon melden, wenn es das Passwort als korrekt erkannt hat."
->Beim bruten des Logins kansnt du aber eine IP einfach nach z.B. 3 falschen Versuchen sperren. Natürlich köntne man diverse Proxys nutzen etc. Aber wenn das Passwort nicht grade allzu kurz/simpel ist oder im Wörterbuch steht, ist das nicht wirklich praktikabel.
Würdest du lokal den Hash bruten, hättest du diese Einschränkungen nicht, also muss man schaun hier entsprechend einen Riegel vorzuschieben - also entweder doppelt verschlüsseln, was sowohl schwache als auch bereits starke Passwörter nochmal stärkt oder halt n Salt dazu.

"Es ist für das Speichern eines Passwortes absolut irrelevant, ob das im Klartext, mit MD5, mit SHA1, mit doppeltem MD5 oder ROT13 passiert."
->Ist es absolut garnicht. Stichwort SQL Injection. Hier macht es dann sehr wohl n Unterschied, ob ich das Passwort erst noch bruten muss oder nicht.

"Entscheidend für die Sicherheit ist, dass das Passwort vom User selbstverständlich immer im Klartext eingegeben wird, der Prüfmechanismus kann also so komplizierte und lange Strings produzieren, wie er will - das hindert einen Angreifer nicht, zu kurze Klartextpassworte durch Ausprobieren im Login herauszufinden."
->Dieses Problem wird man aber immer haben. Auch wenn man, wie du richtigerweise vorschlägst, eine Mindestlänge sowie eine Kombination von diversen Zeichen fordert.
Das gibt aber keinen Grund dafür, andere Mögliche Sicherheitslücken nicht zu schließen.

"Du behauptest hier Dinge, ohne den Beweis anzutreten. Deshalb widerspreche ich deiner Darstellung einfach mal."
-> Du kannst es ja selbst ausprobieren bzw. korrigiere mich wenn ich falsch liege, ich will hier ja auch noch was lernen:
4^62 < 32^62 (Zeichen^(26+26+10 für a-z,A-Z,0-9, hoffe ich habe hier jetzt mal keinen Zahlendreher drinne).
Ich kann dir nur sagen, dass ich und viele andere einen MD5 Hash eines Passwortes mit a-z0-9 und max.8 Zeichen in rund 2 Stunden als Klartext haben, wäre es 2mal verschlüsselt allerdings nicht.
Bei den von dir geforderten Zeichen würde ich das Passwort ab einer entsprechenden Länge auch nicht in einer rentablen Zeit herausbekommen, da Stimme ich dir ebenfalls zu. Aber wäre dieses ebenfalls nochmal verschlüsselt, würde es nochmal länger dauern.

"Es ist für einen Angreifer, der in einer Datenbank MD5 als Passwort vorfindet, praktisch unmöglich, daraus wieder die Originalen Passworte herzustellen."
-> Bei entsprechend langen und starken Passwörtern, ja.
Aber schau dir diverse Boards an, da gibt es per Standard keine richtigen "Passwortrichtlinien" und die Passwörter werden (z.B. beim WbbLite) einmalig per md5() verschlüsselt. Und wieviele Nutzer benutzen simple Passwörter, wenn man ihnen nichts anderes vorschreibt?

"Da würde man extrem viel Rechenzeit sinnlos drauf verschwenden, ohne wirklich Erfolge zu haben."
-> Bei entsprechenden Passwörtern nutzt man einfach die verfügbaren Rainbow Tables im Netz, spart ne Menge Zeit.

"Außerdem wäre noch zu klären, wie der Angreifer denn an den Passwort-Hash kommen kann. Was sagt so ein Vorfall über die Sicherheit?"
->Wie bereits erwähnt, SQL Injection, diverse Exploits wenn der Hoster nicht regelmäßig Updates fährt, schwaches SQL Passwort und externer Zugriff etc. Angriffsmöglichkeiten gibs viele.

"Man könnte also, wenn man wollte, einfach an dieser Stelle die Accountdaten anzapfen, ohne sich auch nur einen Deut um doppeltes, dreifaches oder tausendfaches MD5 zu scheren."
->Wie gesagt, das geht aber immer und sit ein anderer Angriffsweg.
In meinen Post ging es vor allem darum, das man evtl. per SQL Injection o.ä. an die DB Daten kommt.

Zuasmmenfassend lässt sich sagen, dass du sicher recht hast, das man Passwortregeln aufstellen muss. Sonderzeichen sind mir dabei icht so ganz geheuer bzw. man müsste diese Einschränken (Gefahr der SQL Injection etc.). Ich persönlich würde ein möglichst langes Passwort erzwingen, soll der Nutzer sein normales Passwort halt 2,3 mal wiederholen. Optimalerweise erzwingt man statt Sonderzeichen einfach die deutschen Umlaute (zumindest bei deutschsprachiger Zielgruppe), denn die gibt es per default bei den meisten Brute Force Programmen nicht, bei den Rainbow Tables im Netz auch nicht.
Die 2fache Verschlüsselung bringt meiner Meinung nach sehr wohl etwas, unabhängig von der stärke des ursprünglichen Passwortes.
Auch wichtig, die Unterscheide der Passwörter in der DB und im cookie, sosnt könnte man ein entsprechendes Cookie ja selbst erstellen, ohne jemals das Passwort im Klartext gekannt zu haben!

[MudGuard]

Hi,

könntest Du bitte die Zitatzeichen stehen lassen? Die erfüllen einen wichtigen Zweck!
Bei Deinen Postings ist nicht mehr unterscheidbar, was von Dir stammt und was von den Vor-Postern - ohne das Vor-Posting zusätzlich zu öffnen.

Danke.

cu,
Andreas

[Daniel (nun registriert)]

könntest Du bitte die Zitatzeichen stehen lassen? Die erfüllen einen wichtigen Zweck!

Sry, werde ich in Zukunft besser drauf achten!

[Sven Rautenberg]

Moin!

Gewiß ist es recht simpel, einfach bei "aaaa" anzufangen, alle daraus resultierenden MD5-Strings zu erzeugen, und abzuwarten, bis der gewünschte String rauskommt.

Aber genauso einfach ist es, einfach das vier Zeichen lange Passwort als Loginversuch zu verwenden - das Loginsystem wird sich schon melden, wenn es das Passwort als korrekt erkannt hat."

Beim bruten des Logins kansnt du aber eine IP einfach nach z.B. 3 falschen Versuchen sperren.

Was bestimmt supergut ankommt, wenn damit der eine blöde Mitarbeiter der gesamten Firma das Login des NAT-Netzwerks sperrt.

Natürlich köntne man diverse Proxys nutzen etc. Aber wenn das Passwort nicht grade allzu kurz/simpel ist oder im Wörterbuch steht, ist das nicht wirklich praktikabel.

Richtig, das lernt man eigentlich doch schon im Cracker-Kindergarten: Wenn man BruteForce nehmen muß, ist es einfacher, ein leichteres Ziel woanders zu suchen.

Es sei denn, der Aufwand lohnt sich. Wenn sich der Aufwand lohnt, gibts allerdings auch nicht solche Pipifax-Passworte, sondern richtige. Wenn überhaupt, denn auch kryptographische Authentifizierungsverfahren sind mit SSL ja recht einfach zu realisieren, und deutlich sicherer, als ein Passwort.

Würdest du lokal den Hash bruten, hättest du diese Einschränkungen nicht, also muss man schaun hier entsprechend einen Riegel vorzuschieben - also entweder doppelt verschlüsseln, was sowohl schwache als auch bereits starke Passwörter nochmal stärkt oder halt n Salt dazu.

Wenn ich lokal den Hash knacken will, muß ich den aber erst mal haben.

Es ist für das Speichern eines Passwortes absolut irrelevant, ob das im Klartext, mit MD5, mit SHA1, mit doppeltem MD5 oder ROT13 passiert.

Ist es absolut garnicht. Stichwort SQL Injection. Hier macht es dann sehr wohl n Unterschied, ob ich das Passwort erst noch bruten muss oder nicht.

SQL.Injection funktioniert nur, wenn a) extrem schlechter Code geschrieben wurde, bei dem sowas möglich ist, und b) SQL überhaupt zur Ermittlung des Accounthashes benutzt wird. Es gibt ja noch diverse andere Methoden, Passwörter zu speichern.

Du behauptest hier Dinge, ohne den Beweis anzutreten. Deshalb widerspreche ich deiner Darstellung einfach mal.
Du kannst es ja selbst ausprobieren bzw. korrigiere mich wenn ich falsch liege, ich will hier ja auch noch was lernen:
4^62 < 32^62 (Zeichen^(26+26+10 für a-z,A-Z,0-9, hoffe ich habe hier jetzt mal keinen Zahlendreher drinne).

Doch.

62 Symbole, 4 Stück = 62^4 = 14776336.

16 Symbole (Hexzahlen), 32 Stück = 16^32 = 3,4e+38

Wenn man weiß, dass doppeltes MD5 benutzt wird, ist das genauso schnell zu bruteforcen, wie einfaches MD5. Kostet nur etwas mehr Rechenzeit für die Doppelberechnung von MD5.

Wenn du argumentierst "Ja, das weiß man eben nicht", dann frage ich mich, was gegen die Verwendung von Salz als Prefix oder Suffix spricht?

Ich kann dir nur sagen, dass ich und viele andere einen MD5 Hash eines Passwortes mit a-z0-9 und max.8 Zeichen in rund 2 Stunden als Klartext haben, wäre es 2mal verschlüsselt allerdings nicht.

36 Möglichkeiten mit 8 Zeichen sind 36^8 = 2,8e+12 - klingt also nicht unrealistisch hinsichtlich Bruteforce. Aber mit Bruteforce doppeltes MD5 zu knacken kosten vielleicht die doppelte Zeit wegen doppeltem Rechenaufwand - mehr aber auch nicht. Also vier statt zwei Stunden.

Bei den von dir geforderten Zeichen würde ich das Passwort ab einer entsprechenden Länge auch nicht in einer rentablen Zeit herausbekommen, da Stimme ich dir ebenfalls zu. Aber wäre dieses ebenfalls nochmal verschlüsselt, würde es nochmal länger dauern.

Es würde die Zeit nur verdoppelt werden, sofern die Programme wirklich ideal wären und 100% in produktive Rechenarbeit stecken, hingegen keinerlei in Organisationsaufgaben.

Es ist für einen Angreifer, der in einer Datenbank MD5 als Passwort vorfindet, praktisch unmöglich, daraus wieder die Originalen Passworte herzustellen.
Bei entsprechend langen und starken Passwörtern, ja.

Das sicherzustellen ist also extrem wichtig! Denn damit schützt man sich nicht nur vor dem eher unwahrscheinlichen Angriff über Bruteforce eines bekanntgewordenen Passworthashes, sondern auch gegen Bruteforce beim Login!

Aber schau dir diverse Boards an, da gibt es per Standard keine richtigen "Passwortrichtlinien" und die Passwörter werden (z.B. beim WbbLite) einmalig per md5() verschlüsselt. Und wieviele Nutzer benutzen simple Passwörter, wenn man ihnen nichts anderes vorschreibt?

Das kann ja nicht mein Problem sein, wenn andere Software schlecht mit den Passwörtern umgeht.

Außerdem wäre noch zu klären, wie der Angreifer denn an den Passwort-Hash kommen kann. Was sagt so ein Vorfall über die Sicherheit?"
Wie bereits erwähnt, SQL Injection, diverse Exploits wenn der Hoster nicht regelmäßig Updates fährt, schwaches SQL Passwort und externer Zugriff etc. Angriffsmöglichkeiten gibs viele.

Das bedeutet also, dass der Angreifer sowohl volle Kenntnis über den Hash als auch den verwendeten Mechanismus zur Generierung desselben hat.

Mit anderen Worten: Er kann munter zuhause bruteforcen, weil ihn das doppelte MD5 nicht überrascht.

In meinen Post ging es vor allem darum, das man evtl. per SQL Injection o.ä. an die DB Daten kommt.

In deinem Post ist von SQL-Injection nicht ein einziges Mal die Rede gewesen. Du mischst hier ganz munter die Angriffsszenarien so, wie es dir in den Kram paßt.

Zuasmmenfassend lässt sich sagen, dass du sicher recht hast, das man Passwortregeln aufstellen muss.

Das ist unabdingbar. Schön, dass du das einsiehst.

Sonderzeichen sind mir dabei icht so ganz geheuer bzw. man müsste diese Einschränken (Gefahr der SQL Injection etc.).

Sorry, aber du hast keinerlei Ahnung, wie Absicherung gegen SQL-Injection funktioniert, oder?

Ich persönlich würde ein möglichst langes Passwort erzwingen, soll der Nutzer sein normales Passwort halt 2,3 mal wiederholen.

Oh, wahnsinn! Super Idee! Statt den Nutzer einmal in die wirklich sichere Methode einer vernünftigen Passworterstellung einzuweisen, schluderst du wieder rum.

Optimalerweise erzwingt man statt Sonderzeichen einfach die deutschen Umlaute (zumindest bei deutschsprachiger Zielgruppe), denn die gibt es per default bei den meisten Brute Force Programmen nicht, bei den Rainbow Tables im Netz auch nicht.

Damit handelst du dir Zeichensatzprobleme ein. Die klassischen ASCII-Zeichen sind überall die gleichen, Umlaute nicht. Schon mal dran gedacht, was passiert, wenn eine Website von ISO auf UTF-8 umstellt?

Die 2fache Verschlüsselung bringt meiner Meinung nach sehr wohl etwas, unabhängig von der stärke des ursprünglichen Passwortes.

Die doppelte Verschlüsselung bringt nichts. Schwache Passworte bleiben schwach!

Auch wichtig, die Unterscheide der Passwörter in der DB und im cookie, sosnt könnte man ein entsprechendes Cookie ja selbst erstellen, ohne jemals das Passwort im Klartext gekannt zu haben!

Zu dem Thema Cookie hatte ich mich noch nicht geäußert - aber das ist auch eine Schwachsinnsidee. Wozu gibt es Session-Mechanismen? Da erhält der Nutzer jedesmal eine andere Session-ID, und man kann an der ID bruteforcen, wie man will - sie hat keinerlei Bedeutung, enthält keine Passworte etc.

Insgesamt kritisiere ich an deiner Vorgehensweise, dass du Glauben machen willst, md5() sein eine Sicherheitsfunktion, und je häufiger man sie anwendet, desto mehr Sicherheit bekäme man.

Diese Ansicht ist grundsätzlich falsch!

- Sven Rautenberg

[Daniel (nun registriert)]

Was bestimmt supergut ankommt, wenn damit der eine blöde Mitarbeiter der gesamten Firma das Login des NAT-Netzwerks sperrt.

Man muss die IP ja nicht dauerhaft sperren. und soltle man feststellen, das dies öfters vorkommt, sollte man sich wohl mal an den Administrator wenden, das der mal in den Logs nachschaut, wer denn da fleißig Passwörter ausprobiert.
Zudem sollte man sich doch schon aus Sicherheitsgründen nicht grade von der Arbeit aus einloggen, wer kennt als Arbeitsnehmer schon den genauen Aufbau des Netzwerkes und weiß ob es sicher ist? (machen tuns halt leider trotzdem viele, aber lieber Sperre ich einen Nutzer für ne gewisse Zeit aus, als das sein Passwort geknackt wird!)

SQL.Injection funktioniert nur, wenn a) extrem schlechter Code geschrieben wurde, bei dem sowas möglich ist

Fehler kommen leider immer vor und unser Threaderöffner hier ist Anfänger - dem wird sowas erst recht leicht passieren.
Zudem kann es ja rein präventiv sicher nicht schaden, anzunehmen das es mal vorkommen kann.

Wenn du argumentierst "Ja, das weiß man eben nicht", dann frage ich mich, was gegen die Verwendung von Salz als Prefix oder Suffix spricht?

Ich habe nie behauptet das etwas dagegen spricht.
Mit dem 2.mal verschlüsseln erreiche ich ja das selbe wie mit einem Prä/Suffix.
Würde man allerdings den Code kennen, könnte man die Angriffszeit reduzieren, man kennt ja bereits einen Teil des Passwortes im Klartext - bei 2facher Verschlüsselung wäre dies nicht der Fall.

Oh, wahnsinn! Super Idee! Statt den Nutzer einmal in die wirklich sichere Methode einer vernünftigen Passworterstellung einzuweisen, schluderst du wieder rum.

Wenn man ein Passwort z.B. 4mal wiederholt und dann noch was beliebiges dranhängt, ist das in der Praxis nicht unsicherer als n entsprechend langes Passwort, wo sich nichts wiederholt, aber leichter zu merken.

-----

Ich bin die ganze Zeit von SQL Injection ausgegangen oder das man auf anderem Wege mal nur auf die DB Zugriff hat (soll ich einem Anfänger Begriffe wie SQL Injection und Exploits um die Ohren hauen?).
Bei selbst erstellten Scripts verfügt der "Angreifer" ja normalerweise nicht über den Code. SQL Injection ist trotzdem möglich ("Blind SQL Injection"). Sieht man ja auf vielen Seiten, wenn man an den GET Parametern was ändert - da häufen sich dann gleich die SQL Fehlermeldungen.

Die doppelte Verschlüsselung bringt nichts. Schwache Passworte bleiben schwach!

Wenn man von der doppelten Verschlüsselung weiß, dann ja. Sonst nicht.

Insgesamt kritisiere ich an deiner Vorgehensweise, dass du Glauben machen willst, md5() sein eine Sicherheitsfunktion, und je häufiger man sie anwendet, desto mehr Sicherheit bekäme man.

In besonderen Fällen schon. Abgesehn davon ist mir bekannt, das md5() nicht mehr das sicherste ist, und es schon Wege gibt, die Angriffszeit zu reduzieren.

Zu dem Thema Cookie hatte ich mich noch nicht geäußert - aber das ist auch eine Schwachsinnsidee. Wozu gibt es Session-Mechanismen? Da erhält der Nutzer jedesmal eine andere Session-ID, und man kann an der ID bruteforcen, wie man will - sie hat keinerlei Bedeutung, enthält keine Passworte etc.

Ich wollte mich als Nutzer nicht jedesmal einloggen müssen. Und wenn jmd Zugriff auf den PC bekommt, kann er statt sich das Cookie anzuschauen auch n Keylogger installieren, da bringen dann auch Sessions wenig, XSS jetzt mal ausgenommen.
Und Sessions lassen sich genauso bruten oder es kann passieren das technisch weniger versierte Nutzer diese in diversen boardposts mit hineinkopieren. Normal sollte die Session an die IP gebunden sein, aber das ist eben auch nicht immer der Fall.
Beide Verfahren haben ihre vor und nachteile. Man sollte dem Nutzer beides zur Auswahl stellen, aber pauschal zu sagen das eines der Verafahren sicherer sei als das andere, halte ich für falsch.

Naja insgeasmt denke ich könnten wir hier noch Stunden diskutieren, es gibt so oder so zig verschiedene Angriffswege, und wenn man sich anschaut, wie weit sich z.B. Sasser verbreitet hat, obwohl es schon einen Monat zuvor das entsprechende Update gab, ist doch klar, das die meisten Nutzer zu wenig Ahnung haben. Es fehlt unabhängig von der Sicherheit der eigenen Website auch das Wissen bei den Besuchern. Und nein, damit meine ich nicht, hey es bringt ja eh nix seine Seite abzusichern ;)

[Sven Rautenberg]

Moin!

Was bestimmt supergut ankommt, wenn damit der eine blöde Mitarbeiter der gesamten Firma das Login des NAT-Netzwerks sperrt.
Man muss die IP ja nicht dauerhaft sperren. und soltle man feststellen, das dies öfters vorkommt, sollte man sich wohl mal an den Administrator wenden, das der mal in den Logs nachschaut, wer denn da fleißig Passwörter ausprobiert.

Wenn du ein größerer Anbieter mit einigen hunderttausend bis Millionen Accounts bist, und mehrere Mitarbeiter einer Firma oder sonst eines per NAT am Internet angeschlossenen Netzwerkes sich bei dir einloggen, und deren IP durch irgendeinen blöden oder absichtlichen Zufall gesperrt wird - dann wird es dich als Anbieter vermutlich nicht sonderlich interessieren können, und es wird in der Firma wohl kaum einen Administrator geben, der dort irgendwelche Logs nachsehen kann.

Ergo: Du erzürnst deine Kunden, ohne gegen wirklich gut gemachte Bruteforces eine Chance zu haben. Daraus folgt: IP-Sperrung ist kein Mittel der Wahl.

Zudem sollte man sich doch schon aus Sicherheitsgründen nicht grade von der Arbeit aus einloggen, wer kennt als Arbeitsnehmer schon den genauen Aufbau des Netzwerkes und weiß ob es sicher ist? (machen tuns halt leider trotzdem viele, aber lieber Sperre ich einen Nutzer für ne gewisse Zeit aus, als das sein Passwort geknackt wird!)

Du denkst gerade in die falsche Richtung. Wenn der Arbeitnehmer sich im Auftrag der Firma zur Nutzung als Arbeitsmittel einloggen will, und ein anderer Arbeitnehmer den Kollegen böse ist und Trouble macht (Mobbing, Kündigung, Spionage), ist das Szenario gar nicht so abwegig.

SQL.Injection funktioniert nur, wenn a) extrem schlechter Code geschrieben wurde, bei dem sowas möglich ist
Fehler kommen leider immer vor und unser Threaderöffner hier ist Anfänger - dem wird sowas erst recht leicht passieren.

Dann informiere ihn, wie man SQL-Injection sicher verhindern kann - und verwirre ihn nicht mit derartig abstrusen "Sicherheitsideen".

Zudem kann es ja rein präventiv sicher nicht schaden, anzunehmen das es mal vorkommen kann.

Natürlich kann man annehmen, dass der Hashwert des Passwortes bekannt werden könnte. Das ist einer der Szenarien, die man bei der Sicherheitsbetrachtung beachten sollte. Und darauf folgt dann, eine Risikoabschätzung und mögliche Gegenmaßnahmen zu erörtern. Was immer auch dazu führt, dass man Wahrscheinlichkeiten betrachtet, sowie das Kosten-Nutzen-Verhältnis.

Wenn du argumentierst "Ja, das weiß man eben nicht", dann frage ich mich, was gegen die Verwendung von Salz als Prefix oder Suffix spricht?
Ich habe nie behauptet das etwas dagegen spricht.
Mit dem 2.mal verschlüsseln erreiche ich ja das selbe wie mit einem Prä/Suffix.

Das bestreite ich.

Würde man allerdings den Code kennen, könnte man die Angriffszeit reduzieren, man kennt ja bereits einen Teil des Passwortes im Klartext - bei 2facher Verschlüsselung wäre dies nicht der Fall.

Was hilft es dir, einen Teil des gehashten Passwortes, nämlich einen konstanten Prefix oder Suffix, zu kennen? Daraus berechnen sich die MD5-Hashes nicht schneller. Im Gegenteil: Das schlichte Nachgucken eines möglicherweise tabellarisch erfaßten schwachen Passwortes wird garantiert verhindert.

Oh, wahnsinn! Super Idee! Statt den Nutzer einmal in die wirklich sichere Methode einer vernünftigen Passworterstellung einzuweisen, schluderst du wieder rum.
Wenn man ein Passwort z.B. 4mal wiederholt und dann noch was beliebiges dranhängt, ist das in der Praxis nicht unsicherer als n entsprechend langes Passwort, wo sich nichts wiederholt, aber leichter zu merken.

Experte für Kryptoanalyse?

Ich bin die ganze Zeit von SQL Injection ausgegangen oder das man auf anderem Wege mal nur auf die DB Zugriff hat (soll ich einem Anfänger Begriffe wie SQL Injection und Exploits um die Ohren hauen?).

Das hattest du erfolgreich verschwiegen und nicht als Begründung geliefert.

Bei selbst erstellten Scripts verfügt der "Angreifer" ja normalerweise nicht über den Code. SQL Injection ist trotzdem möglich ("Blind SQL Injection"). Sieht man ja auf vielen Seiten, wenn man an den GET Parametern was ändert - da häufen sich dann gleich die SQL Fehlermeldungen.

Wie erwähnt: Erstmal muß sich überhaupt etwas injizieren lassen. Zweitens muß das dann wirklich genau passen. Drittens muß es dann auch noch anstelle der normalen, programmierten Funktion den Passworthash sichtbar ausgeben.

Das ist alles so unwahrscheinlich, dass es mir schwerfällt, daran zu glauben, dass ein Anfänger wirklich so dermaßen bösen Skriptcode schreiben könnte. Die üblichen bösen Fallen hinsichtlich SQL-Injection sind mir aus diesem Form ja hinreichend bekannt. Die überwiegend eingebauten Lücken erlauben vielleicht Injection, aber keine Bestimmung der abgefragten DB-Felder.

Oder sind dir aus der Praxis solche Lücken, die von Anfängern typischerweise eingebaut werden, bekannt?

Die doppelte Verschlüsselung bringt nichts. Schwache Passworte bleiben schwach!
Wenn man von der doppelten Verschlüsselung weiß, dann ja. Sonst nicht.

Man muß zwingend wissen, durch welche Transformation das Klartextpasswort durchgeleitet wird, ansonsten kann man nicht sinnvoll bruteforcen. Ein beliebiger, in einer DB gefundener 32-Zeichen-Hexstring kann ja alles mögliche sein. Wer sagt mir, dass da MD5 am Werke war?

Es könnte auch MD4 gewesen sein, oder die ersten 128 Bit von SHA1, oder CRC128, oder sonst irgendeine selbst erstellte Checksummenfunktion.

Ansonsten wird man feststellen, dass man unter der Annahme, es sei MD5, viel Rechenzeit in ein wertloses Ergebnis gesteckt hat - das ist in der Tat so.

Insgesamt kritisiere ich an deiner Vorgehensweise, dass du Glauben machen willst, md5() sein eine Sicherheitsfunktion, und je häufiger man sie anwendet, desto mehr Sicherheit bekäme man.
In besonderen Fällen schon.

In welchen Fällen?

Abgesehn davon ist mir bekannt, das md5() nicht mehr das sicherste ist, und es schon Wege gibt, die Angriffszeit zu reduzieren.

Du bist schlecht informiert. Die angesprochenen Angriffe gegen MD5 betreffen Kollisionen, und damit den Einsatz von MD5 als Signaturfunktion. Damit hat die hier diskutierte Problematik für Passworte nicht viel zu tun.

Zu dem Thema Cookie hatte ich mich noch nicht geäußert - aber das ist auch eine Schwachsinnsidee. Wozu gibt es Session-Mechanismen? Da erhält der Nutzer jedesmal eine andere Session-ID, und man kann an der ID bruteforcen, wie man will - sie hat keinerlei Bedeutung, enthält keine Passworte etc.
Ich wollte mich als Nutzer nicht jedesmal einloggen müssen. Und wenn jmd Zugriff auf den PC bekommt, kann er statt sich das Cookie anzuschauen auch n Keylogger installieren, da bringen dann auch Sessions wenig, XSS jetzt mal ausgenommen.

Ja, aber wozu dann überhaupt das ganze Gehampel?

Und Sessions lassen sich genauso bruten

Nein. Lies die diversen Postings von mir im Archiv, die deutlich zeigen, dass das mit heutigen Rechnern und Netzen nicht machbar ist.

oder es kann passieren das technisch weniger versierte Nutzer diese in diversen boardposts mit hineinkopieren.

Wer das als Anbieter vermeiden möchte, nutzt eben ausschließlich Cookies.

Normal sollte die Session an die IP gebunden sein

Was technischer Schwachsinn ist, weil User nicht an die IP gebunden sind.

aber das ist eben auch nicht immer der Fall.

Beide Verfahren haben ihre vor und nachteile. Man sollte dem Nutzer beides zur Auswahl stellen, aber pauschal zu sagen das eines der Verafahren sicherer sei als das andere, halte ich für falsch.

Welche Verfahren? Und warum muß der Nutzer sicherheitskritische Entscheidungen treffen? Das kann der gar nicht! Der Anbieter ist gefordert, zu entscheiden, welchen Level an Sicherheit er haben will.

Naja insgeasmt denke ich könnten wir hier noch Stunden diskutieren, es gibt so oder so zig verschiedene Angriffswege,

Nein, eigentlich gibt es vom Grundsatz her nur relativ wenige Angriffswege.

und wenn man sich anschaut, wie weit sich z.B. Sasser verbreitet hat, obwohl es schon einen Monat zuvor das entsprechende Update gab

Das ist ein ganz anderes Thema.

ist doch klar, das die meisten Nutzer zu wenig Ahnung haben.

Gerade schlägst du noch vor, der Nutzer soll sich ein sicherheitsrelevantes Verfahren aussuchen dürfen!

Es fehlt unabhängig von der Sicherheit der eigenen Website auch das Wissen bei den Besuchern.

Und genau deshalb ist der Anbieter gefordert, die Nutzer zu entsprechend sicheren Passworten oder sonstigen Loginverfahren zu zwingen.

- Sven Rautenberg

[Daniel (nun registriert)]

Wenn du ein größerer Anbieter mit einigen hunderttausend bis Millionen Accounts bist, und mehrere Mitarbeiter einer Firma oder sonst eines per NAT am Internet angeschlossenen Netzwerkes sich bei dir einloggen, und deren IP durch irgendeinen blöden oder absichtlichen Zufall gesperrt wird - dann wird es dich als Anbieter vermutlich nicht sonderlich interessieren können, und es wird in der Firma wohl kaum einen Administrator geben, der dort irgendwelche Logs nachsehen kann.

Ergo: Du erzürnst deine Kunden, ohne gegen wirklich gut gemachte Bruteforces eine Chance zu haben. Daraus folgt: IP-Sperrung ist kein Mittel der Wahl.

Naja, eigentlich tut man den Kunden ja n gefallen, denn bei nem Firmennetz weiß man als Nutzer nicht, wie das sicherheitsmäßig aufgebaut ist. Auf der anderen Seite werden die wenigsten Nutzer dafür Verständnis haben und die miesten Heim PCs auch nicht grade sicherer sein, insofern ist es wohl wirklich keine Lösung.

Aber mich interessiert, wie deiner Meinung nach ein gut gemachter Bruteforce aussieht? Was anderes als die Nutzung von zig Proxys bleibt dem Angreifer ja nicht übrig, und zig Proxys wären je nach Passwort Millionen (da hätte man dann am Ende eher n DDos statt nem Login?)

Du denkst gerade in die falsche Richtung. Wenn der Arbeitnehmer sich im Auftrag der Firma zur Nutzung als Arbeitsmittel einloggen will, und ein anderer Arbeitnehmer den Kollegen böse ist und Trouble macht (Mobbing, Kündigung, Spionage), ist das Szenario gar nicht so abwegig.

Ich verstehe, dass man das missbrauchen kann. Aber von der Formulierung werde ich aus "ist das Szenario gar nicht so abwegig." nicht schlau, das klingt so, als sollte da noch zwischendrin etwas stehen. Aber ich vermute mit "Szenario" meinst du den Missbrauch?

Was hilft es dir, einen Teil des gehashten Passwortes, nämlich einen konstanten Prefix oder Suffix, zu kennen? Daraus berechnen sich die MD5-Hashes nicht schneller. Im Gegenteil: Das schlichte Nachgucken eines möglicherweise tabellarisch erfaßten schwachen Passwortes wird garantiert verhindert.

Nehmen wir wieder unser tolles Passwort "test" und ignorieren jetzt mal, dass es dictionary attacks gibt.
ist mir das präfix oder suffix bekannt, muss ich, würde ich am anfang beginnen (was ja sinn macht, wenn man nicht gerade weiß, das es passwortregeln gibt, die dies verhindern) 52^4 kombinationen ausprobieren, Salza, Salzb - das Präfix/Suffix ist ja konstant, d.h. erzeugt nicht mehr Kombinationen.
Hätte ich das ganze 2x verschlüsselt, wäre dies in diesem Fall sogar efefktiver, denn hier habe ich genausoviele Möglichkeiten, aber aufgrund der doppelten Verschlüsselung doppelte Rechenzeit.
(zumindest in der Theorie, das einfügen des Suffix zusätzlich zur aktuellen Zeichenkombination nimmt ja auch Zeit in Anspruch, aber zumindest sollte man durch die doppelte Verschlüsselung in diesem Fall keinen Nachteil gegenüber einem Präfix/Suffix haben)

Das hattest du erfolgreich verschwiegen und nicht als Begründung geliefert.

Es ging die ganze Zeit um die DB und ich habe ja auch geschrieben, dass man an den PHP Code selbst dann meistens schwerer drankommt, wobei das je nach (my)sql konfiguration ja dann auch über (my)sql möglich ist... (php datei über (my)sql erstellen ("export" von (my)sql in php datei, also den code in der db schreiben und dann dumpen), die dann die anderen dateien ausliest/darstellt)

Oder sind dir aus der Praxis solche Lücken, die von Anfängern typischerweise eingebaut werden, bekannt?

Erschreckenderweise passieren sie selbst fortgeschrittenen Entwicklern. Warum sollten sie einem Anfänger dann nicht passieren (ok, dessen Skripte sind weniger komplex, aber da können dann doch trotzdem genauso Fehler drinne sein). Und ich habe mir bisher nicht die Mühe gemacht, irgendwelche Seiten auf SQL Injection zu untersuchen, weder kleine, noch große.

Was technischer Schwachsinn ist, weil User nicht an die IP gebunden sind.

Sicherheitstechnisch würde es aber was bringen und kaum ein Nutzer ändert dauernd seine IP, selbst die Nutzer, die nen Proxy benutzen, nutzen dann meistens ne weile einen, so das dies in der praxis eher weniger ein problem darstellen sollte.

was hälst du denn von session cookies?
man könnte sie ja etwas anders nutzen als sie definiert sind (session im sinne von zerfällt beim schließen des browsers) - kein verschlüsseltes passwort oder so, sondern eine session id drinne speichern. da diese kann nicht per url übertragen wird, könnte der nutzer sie auch nicht versehentlich mitkopieren. dann wäre auch eine ip überprüfung unrelevant.

[Sven Rautenberg]

Moin!

Aber mich interessiert, wie deiner Meinung nach ein gut gemachter Bruteforce aussieht? Was anderes als die Nutzung von zig Proxys bleibt dem Angreifer ja nicht übrig, und zig Proxys wären je nach Passwort Millionen (da hätte man dann am Ende eher n DDos statt nem Login?)

Einen Bruteforce kann man nicht realisieren, wenn die zugrundeliegenden Passworte nicht in endlicher Zeit erratbar sind.

Und wie mach man Passworte nicht erratbar? Indem man sie lang und zufällig macht!

Und wie kriegt man User dazu, Passworte lang und zufällig zu machen? Indem man z.B. dem User das Passwort vorschreibt, anstatt ihn selbst eines aussuchen zu lassen. Gleich bei der Registrierung kriegt er eines verpaßt, das man ihm mitteilt (auf dem Bildschirm oder per Mail), und fertig. Wenn er sein Passwort wechseln möchte oder es vergessen hat, kriegt er wieder ein neues, generiertes Passwort.

Du denkst gerade in die falsche Richtung. Wenn der Arbeitnehmer sich im Auftrag der Firma zur Nutzung als Arbeitsmittel einloggen will, und ein anderer Arbeitnehmer den Kollegen böse ist und Trouble macht (Mobbing, Kündigung, Spionage), ist das Szenario gar nicht so abwegig.
Ich verstehe, dass man das missbrauchen kann. Aber von der Formulierung werde ich aus "ist das Szenario gar nicht so abwegig." nicht schlau, das klingt so, als sollte da noch zwischendrin etwas stehen. Aber ich vermute mit "Szenario" meinst du den Missbrauch?

Ich meine, dass es genug Gelegenheiten gibt, wo jemand innerhalb einer Firma Trouble machen wollen würde, wenn er denn könnte. Also besser keine Sperre einbauen (jedenfalls nicht als pauschale Lösung), weil man damit als Bösewicht den Zugang für legitime User versperren kann.

Was hilft es dir, einen Teil des gehashten Passwortes, nämlich einen konstanten Prefix oder Suffix, zu kennen? Daraus berechnen sich die MD5-Hashes nicht schneller. Im Gegenteil: Das schlichte Nachgucken eines möglicherweise tabellarisch erfaßten schwachen Passwortes wird garantiert verhindert.

Nehmen wir wieder unser tolles Passwort "test" und ignorieren jetzt mal, dass es dictionary attacks gibt.

Der Punkt ist der: Es gibt nur zwei mögliche Angriffsformen gegen Hashfunktionen wie MD5 (von kryptographischen Angreifbarkeiten abgesehen): Entweder weiß ich zum Hash den Input durch eine Tabelle, oder ich muß durchprobieren.

Wenn das Passwort 1:1 durch MD5 durchgeht, sind solche Tabellen erfolgreich. Wenn irgendein Faktor mir den direkten Lookup versaut, muß ich durchprobieren, also Variationen von Input generieren und den Mechanismus komplett durchrechnen, um das Ergebnis auf Identität mit dem ausspionierten Wert zu prüfen.

ist mir das präfix oder suffix bekannt,

Wenn du das als bekannt voraussetzt, dann mußt du als bekannt voraussetzen, dass der Angreifer den gesamten Hash-Mechanismus kennt.

muss ich, würde ich am anfang beginnen (was ja sinn macht, wenn man nicht gerade weiß, das es passwortregeln gibt, die dies verhindern) 52^4 kombinationen ausprobieren, Salza, Salzb - das Präfix/Suffix ist ja konstant, d.h. erzeugt nicht mehr Kombinationen.
Hätte ich das ganze 2x verschlüsselt, wäre dies in diesem Fall sogar efefktiver, denn hier habe ich genausoviele Möglichkeiten, aber aufgrund der doppelten Verschlüsselung doppelte Rechenzeit.

Verdopplung der Rechenzeit ist aber irrelevant. Dann nimmt der böse Angreifer einfach die doppelte Menge an Rechenpower (zwei statt eine CPU), und schon hat sich die Sache wieder erledigt.

Es ist nicht praktikabel, den Weg vom Input zum Hash mit extrem viel Rechenzeit zu belasten, damit das Brute Force lange dauert. Denn auch die gewollte Anwendung innerhalb der Applikation würde ja darunter leiden, denn das Prüfen von Passworten wird andauernd vorkommen. Unter Umständen bei jedem einzelnen Request. Solch ein Hashvorgang sollte daher möglichst schnell ablaufen.

MD5 bezieht seine Stärke nicht aus seiner Langsamkeit, sondern aus den 2^128 verschiedenen möglichen Hashwerten. Das sind so viele, dass es mit heutigen Methoden länger braucht, alle Möglichkeiten durchzurechnen, als das Universum alt ist.

Angenommen, du hättest die Möglichkeit, pro Sekunde eine Billiarde MD5-Hashes nachzurechnen. Dann würdest du für den kompletten Bereich 1,07e+16 Jahre benötigen.

Unser Universum ist 13,7e+9 Milliarden Jahre alt. Du bräuchtest also die Lebenszeit von knapp einer Million Universen, um einmal alles durchzurechnen.

Das macht extrem deutlich, dass mit Brute Force bei MD5 nicht wirklich viel zu holen ist.

Oder sind dir aus der Praxis solche Lücken, die von Anfängern typischerweise eingebaut werden, bekannt?
Erschreckenderweise passieren sie selbst fortgeschrittenen Entwicklern. Warum sollten sie einem Anfänger dann nicht passieren (ok, dessen Skripte sind weniger komplex, aber da können dann doch trotzdem genauso Fehler drinne sein). Und ich habe mir bisher nicht die Mühe gemacht, irgendwelche Seiten auf SQL Injection zu untersuchen, weder kleine, noch große.

Nun ja, angesichts deines Levels auf PHP-Basis, der sich aus deinen anderen Fragen ergibt, sehe ich nicht, dass du das wirklich beurteilen könntest.

Was technischer Schwachsinn ist, weil User nicht an die IP gebunden sind.
Sicherheitstechnisch würde es aber was bringen und kaum ein Nutzer ändert dauernd seine IP, selbst die Nutzer, die nen Proxy benutzen, nutzen dann meistens ne weile einen, so das dies in der praxis eher weniger ein problem darstellen sollte.

Du hast keine Ahnung, was z.B. bei AOL abläuft! AOL setzt eine ganze Farm von Proxys ein, die zur Lastverteilung beliebig User-Requests verteilt bekommen. Ein User wechselt bei dieser Farm unter Umständen mit jedem Request seine IP.

Also ist es Schwachsinn. Eine IP identifiziert keine User, folglich kann man sie nicht für irgendwelche allgemeinen Sicherheitsmaßnahmen heranziehen.

was hälst du denn von session cookies?

Session Cookies sind absolut in Ordnung.

man könnte sie ja etwas anders nutzen als sie definiert sind (session im sinne von zerfällt beim schließen des browsers)

So sind Sessions nicht zwingend definiert.

kein verschlüsseltes passwort oder so, sondern eine session id drinne speichern. da diese kann nicht per url übertragen wird, könnte der nutzer sie auch nicht versehentlich mitkopieren. dann wäre auch eine ip überprüfung unrelevant.

Und genau so arbeiten Sessions in eigentlich allen mir bekannten Session-Systemen: Der User kriegt eine vollkommen zufällig generierte, x-beliebige ID zur Wiedererkennung, an der intern im Server dann diverse Werte drangehängt werden, die den Server aber niemals verlassen.

Bei einem Login tauscht man dann sozusagen die Kenntnis über Username und Passwort mit der Kenntnis über die Session-ID. PHP verwendet für die ID auch wieder das Resultat von MD5, also eine Hexzahl mit 32 Ziffern. Und deshalb wird man eine aktive Session-ID auch niemals erraten können, weil man genau wie beim Brute Force einfach viel zu lange bräuchte, alle IDs durchzuprobieren.

- Sven Rautenberg

[Der Martin]

Hallo,

Und wie kriegt man User dazu, Passworte lang und zufällig zu machen? Indem man z.B. dem User das Passwort vorschreibt, anstatt ihn selbst eines aussuchen zu lassen. Gleich bei der Registrierung kriegt er eines verpaßt, das man ihm mitteilt (auf dem Bildschirm oder per Mail), und fertig. Wenn er sein Passwort wechseln möchte oder es vergessen hat, kriegt er wieder ein neues, generiertes Passwort.

das klingt zwar überzeugend, aber nicht wirklich praktikabel. Ein Passwort muss sich der Anwender schließlich auch einprägen und merken können. Und wo viele Leute schon Mühe haben, sich die 4stellige numerische PIN ihrer ec-Karte zu merken, möchtest du ihnen einen womöglich 12stelligen alphanumerischen Code zum Auswendiglernen vorsetzen? Kommt mir ziemlich abwegig vor.

Und wenn ein Passwort so kompliziert ist, dass ich es auf einem Zettel notieren und mit mir rumtragen muss, ist die Sicherheit plötzlich wieder um Größenordnungen schlechter. Dann verliere ich den Zettel mal irgendwo und jemand findet ihn, oder die Jacke mit der Brieftasche hängt mal einen Moment unbeaufsichtigt rum - solche Fälle sind ja durchaus alltäglich.

Wenn ich ein "sicheres" Passwort generieren möchte, das ich mir dann auch merken kann, dann denke ich mir a) einen sinnvollen Satz aus und b) ein Datum oder eine Zahl, das/die mit diesem Satz im Zusammenhang steht. Und dann mische ich im Wechsel ja eine Ziffer und den Anfangsbuchstaben eines Wortes aus meinem Beispielsatz (unter berücksichtigung von Groß- und Kleinschreibung, versteht sich). Das sieht dann am Schluss ziemlich zufällig aus, aber man kann es sich leicht einprägen bzw. herleiten.

Aber vom Anbieter willkürlich vorgegebene Passworte finde ich nicht besonders praxistauglich.

Schönes Wochenende,
 Martin

PS: Unabhängig von der hier diskutierten grundsätzlichen Problematik wird IMHO die Passwort-Paranoia in sehr vielen Fällen grundlos übertrieben, weil mit dem Passwort nichts wirklich Wichtiges oder Kritisches geschützt wird.

[Robert Bienert]

Moin!

Und wie kriegt man User dazu, Passworte lang und zufällig zu machen? Indem man z.B. dem User das Passwort vorschreibt, anstatt ihn selbst eines aussuchen zu lassen. Gleich bei der Registrierung kriegt er eines verpaßt, das man ihm mitteilt (auf dem Bildschirm oder per Mail), und fertig. Wenn er sein Passwort wechseln möchte oder es vergessen hat, kriegt er wieder ein neues, generiertes Passwort.

das klingt zwar überzeugend, aber nicht wirklich praktikabel. Ein Passwort muss sich der Anwender schließlich auch einprägen und merken können.

Genau hier setzen einige Programme an, die zufällig Passwörter generieren, die in einem sicheren (was auch immer das heißt) Speicher aufbewahren und bei Bedarf nur das passende herausrücken. Das kann man natürlich auch selbst machen: Man trägt alle zufällig generierten in eine Datei, die man mit PGP verschlüsselt. Man braucht sich nur das PGP-Passwort zu merken, alles Andere bekommt man per Copy&Paste oder abschreiben.

Und wo viele Leute schon Mühe haben, sich die 4stellige numerische PIN ihrer ec-Karte zu merken, möchtest du ihnen einen womöglich 12stelligen alphanumerischen Code zum Auswendiglernen vorsetzen?

Ich glaube, dass bei PIN auch eine gewisse Technikphobie mit der Angst ums eigene Vermögen zum Tragen kommt, schließlich können sich die meisten Leute problemlos haufenweise Telefonnummern merken, nur ausgerechnet die PIN nicht.

PS: Unabhängig von der hier diskutierten grundsätzlichen Problematik wird IMHO die Passwort-Paranoia in sehr vielen Fällen grundlos übertrieben, weil mit dem Passwort nichts wirklich Wichtiges oder Kritisches geschützt wird.

Da hast du wohl vollkommen Recht.

Schönes Wochenende,
Robert

[Robert Bienert]

Moin!

Eines fällt mir zu diesem Seitenarm der Ausgangsfrage noch ein:

Beispiel:
Ein Nutzer registriert sich. Das Passwort speicherst du verschlüsselt in der DB, verschlüsseln geht z.b. per MD5: http://de.php.net/manual/en/function.md5.php
ganz einfach $pass=md5($_POST[pass]);
und dann gleich nochmal:
$pass=md5($pass);

Grund:
Nehmen wir als Beispiel das Passwort "test".
Verschlüsselt ergibt dies "098f6bcd4621d373cade4e832627b4f6"
(kannste z.b. unter http://scriptserver.mainframe8.com/md5.php machen oder halt selbst n php script schreiben)
Das lässt sich relativ leicht per BruteForce knacken.

Das lässt sich auch recht leicht per Bruteforce knacken, selbst wenn ich keinen direkten Zugriff auf die Datenbank habe. Dein ganzer Ansatz geht davon aus, dass ich aber durch eine Fehlkonfiguration des Webservers an die DB komme. Für Svens und meine Attacke ist es aber vollkommen unerheblich, wie das Passwort in der Datenbank verschlüsselt ist, weil wir vorne ansetzen. Aber das dürfte geklärt sein, deshalb weiter:

wäre nun jedoch das Passwort "test" 2mal verschlüsselt, d.h.

Legen wir mal deine Logik dem folgenden Verschlüsselungsverfahren zu Grunde, unter der Prämisse, dass Rot13 ein Verschlüsselungsverfahren darstellt. Dann erhalten wir nach zweimal verschlüsseln wieder den Ausgangstext. Was haben wir dabei außer CPU-Abwärme gewonnen?

Viele Grüße,
Robert

[Robert Bienert]

Moin!

Ich würde gerne mal wissen was die sichersten Methode(n) sind für ein Login.

HTTP-Auth mit SSL schlage ich vor.

Wo die Passwörter und Namen ablagern? (Dateien, Datenbanken oder ...)

Das ergibt sich schon fast daraus, allerdings kannst du dem Apachen auch sagen, dass er statt einer .htuser irgendeine Datenbank nehmen soll. Generell gilt allerdings: Keine Account-Daten innerhalb der Document-Root ablegen.

Mir fällt gerade nur ein so mach ich es immer:
Passwort abfrage per PHP name udn pw in einer datei ausgelagert wie zum bsp. pws.inc.php oder so, Cookie wird gesetzt und anschließend wird man weitergeleitet zu den Seiten. Auf den Seiten wird geprüft ob cookie vorhanden if ja alles anzeigen if nein zurück zur loginseiten + variable die per get ausgelesen wird und dadurch wird ne Fehlermeldung angezeigt.

Diese Lösung hat einige Nachteile: Cookies lassen sich manipulieren und nicht immer werden Kekse akzeptiert. Ich musste z.B. den Admin-Bereich eines Blogs von Cookies auf HTTP-Auth umstellen, weil der Benutzer von Internetcafes aus geblogt hat.

Viele Grüße,
Robert

[nap]

Also ich kann folgendes verwenden:

PHP5 (safemode off)
Apache 2.0 (mod_rewrite)
MySQL 5
Perl
SSI
CGI

Wie lässt sich also daraus den sichersten Login erstellen?

mfg

nap