|
|
|
|
Hähä, v!pes Kommentare sind lustig.
|
|
|
|
|
|
|
| Zitat von GH@NDI
// Wieviel Zeit hast du denn allein dafür aufgwandt, auf einigermaßen gescheite art und weise angeforderte seiten zu includen? module=X&subpages=y&subsubpage=z? Alles humbug
Ich hab nen objektorientierten dispatcher. Ich kann nach belieben Methoden in meinem Controller direkt als URL-Aufrufbar machen. Kann aber auch einfach bestimmte Methoden->Url mittels Regulärem Ausdruck binden. Ich kann einfach innerhalb des Dispatchers forwarden oder eine andere methode dispatchen, ohne das sich die url ändert | | Kann Django genau so.
| Zitat von GH@NDI
Objektorientiertes Datenbank mapping. Jede Tabelle ein Objekt. Jede selektierte Zeile ein Objekt. Ich habe verknüpfte Tabellen? Kein Problem, Relationen werden erkannt $resultRow->rowName()->relatedRowInAnotherTable() zack alles da | | Das auch
| Zitat von GH@NDI
Kann drüber itereiere, ach einfach alles machen | | Das auch
| Zitat von GH@NDI
Und dabei schreibe ich nicht eine Zeile SQL selber
| | Ja
| Zitat von GH@NDI
Ändert sich was an der DB? Kein Problem, struktur wirde während der Entwicklungszeit dynamisch neu ausgelesen und zur Verfügung gestellt | | Jupp
| Zitat von GH@NDI
Ich kümmer mich einfach ums wesentliche. Kein rumgekacke mehr, mit den immer gleichen Vorgängen, Einstellungen, etc | | Dito.
Man kann sogar durch eine änderung von einer Zeile das komplette DB-Backend von SQLLight zu Mysql zu PostgreeSQL ändern
---
Apropo, wo bleibt der Gehirnsalat als SQLLight-Datei?
|
|
|
|
|
|
|
Tja mathu, damit hast du dich gerade angeboten für jedes Perl-Script das Ghandi hier abliefert das Python-Äquivalent zu posten. Die Ruby-Seite übernehme ja schon ich.
|
|
|
|
|
|
|
Mach ich doch ohnehin häufgier mal
Wobei ich natürlich zugeben muss, dass der Regex-Support unter Python wirklich nicht so dolle ist. Das re-Modul kann zwar alles und das auch ordentlich, aber di Benutzung über import re[...]strring2 = re.match("a",string, re.MULTILINE)[0] ist einfach unschön.
Das könnte mich glatt zu Ruby treiben
|
|
|
|
|
|
|
| Zitat von SirSiggi
Hähä, v!pes Kommentare sind lustig.
| | Nein.
|
|
|
|
|
|
|
Nicht von, sondern über. Doch sind sie, weil sie nichts mit dir zu tun haben.
|
|
|
|
|
|
|
Dann möge man sie mir vortragen.
Was ich nicht weiß, ist nicht lustig.
|
|
|
|
|
|
|
Diese Informationen sind intern! steht da ganz groß und rot
|
|
|
|
|
|
|
Irgendwann bin ich mal irgendwo Mod und dann trag ich irgendetwas irgendwo über dich ein.
Hahaha!
|
|
|
|
|
|
|
| Zitat von Achse-des-boesen
Django ftw!
| |
Würde ich Python programmieren, würde ich wohl Django einsetzen
|
|
|
|
|
|
|
Aber wer will das schon.
|
|
|
|
|
|
|
Uh, die Datenbank zeit schon erste ausfallerscheinungen
|
|
|
|
|
|
|
|
|
|
|
| Zitat von TriggerTG
Uh, die Datenbank zeit schon erste ausfallerscheinungen
| |
was? wo?
|
|
|
|
|
|
|
Das kriegen nur leute mit, die alle 5 sekunden refreshen
|
|
|
|
|
|
|
|
|
|
|
Ihr zerstört das Internet mit eurem Refresh-Wahn!
Ich bin entrüstet!
|
|
|
|
|
|
|
Kann mir mal jemand bitte erklaren warum es Sinn macht ein Passwort zweimal mit md5 zu encrypten, aber nicht mehr als zweimal?
Sprich:
einaml gut - $encrypted_password = md5(&password)
zweimal besser - $encrypted_password = md5(md5(&password))
aber dreimal oder mehr - sinnlos...
|
|
|
|
|
|
|
Weil es für gängige Passwortlängen mittlerweile Rainbowtables gibt. Das sind ganz einfach Datenbanken in denen auf der einen Seite der md5 Hash steht und auf der anderen Seite das Klartextpasswort. Ausserdem können intelligentere Bruteforcer wie john selbst längere md5 Passwörter oft schnell herausfinden, wenn diese nicht völlig zufällig sind.
Dagegen hilft: 2 mal hashen bzw. den den zu hashenden String vorher mit einem weiteren String salzen. Sicher sind diese Methoden auch keineswegs sicher, aber sie sind gegen die verfügbare Rechenzeit geschützt, die schon vergangen ist.
|
|
|
|
|
|
|
Inder:
RegEx das auf [*] mit beliebigem Text am Ende matcht bis zum nächsten [*]?
Geht mit (?=\[\*\]|$) .
Warum? =)
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von v!pe am 26.03.2007 15:51]
|
|
|
|
|
|
Wer hat dir denn erzählt, das es gut/sinnvoll wäre, das 2mal zu machen?
Weil soweit ich weis, bringt das rein gar nichts, ausser verschwendete Rechenleistung
// ich ziehe meine Aussage zurück und gebe SirSiggi in der Passwortfrage recht
Hab ich doch einfach die Lookup-Tables vergessen
Aber besser als 2mal Hashen ist dann doch das verwenden von einer eigenen Salt. Weil bei der Methode 2 mal MD5 Hashen ist es nur eine Frage der Zeit, bis dafür wieder fertige Rainbow-Tables da sind
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 26.03.2007 15:50]
|
|
|
|
|
|
| Zitat von v!pe
Inder:
RegEx das auf [*] mit beliebigem Text am Ende matcht bis zum nächsten [*]?
| |
Was?
|
|
|
|
|
|
|
|
|
|
|
Was ich aber nicht verstehe ist warum man Passwörter in Sessions oder Cookies ablegt.
Wenn sich jemand authentifiziert hat, dann bekommt er ein authed-Bit gesetzt und bei jedem Aufruf wird geprüft ob er noch er ist (IP passend zur Session ID z.B.). Es wird keinen deut sicherer, wenn man jetzt anfängt und gehashte Passwörter in der Session oder dem Cookie ablegt und diese dann jedesmal prüft.
|
|
|
|
|
|
|
| Zitat von GH@NDI
| Zitat von v!pe
Inder:
RegEx das auf [*] mit beliebigem Text am Ende matcht bis zum nächsten [*]?
| |
Was?
| | Siehe Edit.
|
|
|
|
|
|
|
| Zitat von GH@NDI
Aber besser als 2mal Hashen ist dann doch das verwenden von einer eigenen Salt. Weil bei der Methode 2 mal MD5 Hashen ist es nur eine Frage der Zeit, bis dafür wieder fertige Rainbow-Tables da sind | | So sehe ich das auch, alledings nur was das salten angehet. Am einfachsten ist es bei jeder "Installation" der Applikation, eine eingabe vom User zu verlangen, mit der ein wenig rumzuhashen und einen Teil von dem Ergebnis abzuspeichern und bei jedem MD5() dazu zu packen.
Hat den Vorteil das jede Rainbowtable, kläglich scheitert, selbst wenn sie speziell für die Applikation erstellt wurde (da swäre ein Risiko wenn man einen fest einkodierten Salt verwendet). Und trotzdem kann man bei einer Neuinstallation noch die alten Passwörter benutzn, sofern man den selben Salt eingibt.
Allerdings ist eine Rainbowtable für einen alle möglichen MD5 Hashes nicht wirklich praktikabel, da sich bei 2^128 verschiedenen Hashes die jeweils 128 Bit groß wären eine Gesamtgröße von 4.50359963 * 10^15 Yottabyte ergeben würden (unkomprimiert versteht sich)
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achse-des-boesen am 26.03.2007 16:02]
|
|
|
|
|
|
irgendwie kann ich mich nicht so recht mit dem Stundenplan des neuen Semesters anfreunden :x
e\ man muss dazu erwähnen, dass ich beim letzten semester montags, donnerstags und freitags quasi frei hatte
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TriggerTG am 26.03.2007 16:03]
|
|
|
|
|
|
Tja, das Studentenlotterleben ist vorbei mein Lieber.
|
|
|
|
|
|
|
[mathu,] das will man auch garnicht. die table muss nur die standarddictionaries abdecken. und die sind deutlich kleiner.
ghandi, die verschwendete rechenleistung ist gerade das, was man will. fakt ist, dass zu einem gewissen zeitpunkt jede problemlos verfügbare hardware gewissen grenzen ausgesetzt ist. man kann also algorithmen mit abschätzbarer mindestlaufzeit entwerfen. auf speziellen maschinen sind die schneller, aber die sind nicht so einfach zu kriegen. wenn man also jemanden zwingt, jeweils eine halbe sekunde rechnerleistung für einen authenifizierungsversuch einer kommunikation aufzuwenden, dann kann man damit (aufgrund der undehnbarkeit des jetzt) recht einfach verhindern, dass derjenige bruteforce mit 1e6 versuchen pro sekunde fährt. auch deswegen ist doublehashing toll. außerdem kann man auch md5(sha1(wert)) nehmen. oder andere kombinationen. es ist einfach zu aufwendig, für jeden scheiß rainbowtables anzulegen.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von rABBI am 26.03.2007 16:06]
|
|
|
|
|
|
Naja, doublehashing ist definitiv besser als nichts machen, da dafür einfach keine effektiven Rainbowtables-Existieren. Ein Salt ist trotzdem immernoch die bessere Lösung.
Da aber im Normalfall sowas eh nicht gemacht wird und auch sonst bei Webapplikationen oft wenig auf Sicherheit geachtet wird, werden wir noch lange unseren Spass damit haben.
Mein Arbeitskollege hat sich vor einiger Zeit mal an ein lokales Community-Party-Portal rangemacht. Dem fliegen die Benutzerpasswörter quasi so zu.
Der Trick ist einfach: Per JS gehashtes Benutzerpasswort aus Cookie lesen und an sich selbst senden. Ich wollte das knacken mit john auch mal automatisieren... aber mir verging mal wieder die Lust. Das JS bringt man über das eigene Benutzerprofil an und dann braucht man nur noch ein Benutzerprofil einer willig aussehenden Pseude-Frau und schon gehts rund.
|
|
|
|
|
|
Thema: Gehirnsalat ( wir unter uns ) |