nicht angemeldet
Programmiertechnik Session (Cookie)
Struppi
AugeMoin;
angeregt durch entsprechende Threads zu diesem Thema hier im Forum, hab ich heute einen kleinen aber feinen Artikel dazu geschrieben, hier ist er nun.
Viel Spaß damit,
Horst Haselhuhn
--
Kommentare im ProgrammCode widerspiegeln die Stimmung des Verfassers und dürfen durchaus auch Bemerkungen zum Wetter enthalten.
Kommentare im ProgrammCode widerspiegeln die Stimmung des Verfassers und dürfen durchaus auch Bemerkungen zum Wetter enthalten.
-
Hallo,
angeregt durch entsprechende Threads zu diesem Thema hier im Forum, hab ich heute einen kleinen aber feinen Artikel dazu geschrieben, hier ist er nun.
Oh du schreibst immer noch Programme in dieser komischen Sprache? Wäre es nicht mal langsam an der Zeit sich etwas moderneres zu suchen?
Horst Haselhuhn
Huch? was ist denn das für ein komischer Name?
Jeena
-
Hallo,
»» angeregt durch entsprechende Threads zu diesem Thema hier im Forum, hab ich heute einen kleinen aber feinen Artikel dazu geschrieben, hier ist er nun.
Oh du schreibst immer noch Programme in dieser komischen Sprache? Wäre es nicht mal langsam an der Zeit sich etwas moderneres zu suchen?*G*
Naja, ab und zu schreib ich auch mal was in c...
Neulich im Team-Meeting: Wir haben einen Kollegen in den Ruhestand verabschiedet. Dann dreht sich mein Chef um zu mir, guckt mich feundlich an und sagt: Tja, mein Lieber, Du bist der Nächste.
»» Horst Haselhuhn
Huch? was ist denn das für ein komischer Name?Das ist mein Künstlername!
Eine Pseudoklasse der Rauhfußhühner, denen auch die Moor-, Schnee-, Auer- und auch Perlhühner angehören bzw. daraus abgeleitet sind :-)
Viele Grüße,
schönen Sonntag,
Horst Haselhuhn--
# Bitte ignorieren-
Hallo,
Neulich im Team-Meeting: Wir haben einen Kollegen in den Ruhestand verabschiedet. Dann dreht sich mein Chef um zu mir, guckt mich feundlich an und sagt: Tja, mein Lieber, Du bist der Nächste.
Hahaha, sehr geil! :D So lange das nicht bei einer Beerdigung passiert ist ja noch alles in Ordnung ;)
Jeena
-
-
Oh du schreibst immer noch Programme in dieser komischen Sprache? Wäre es nicht mal langsam an der Zeit sich etwas moderneres zu suchen?
Für diese Aussage müßte man die Sprache auch kennen, tust du?
Bzw. was vermißt du an Perl, was andere "moderne Sprachen" können?Struppi.
-
Hallo Struppi,
<trollposting>
Bzw. was vermißt du an Perl, was andere "moderne Sprachen" können?
Eine Syntax, die nicht zum Erbrechen führt. *scnr*
</trollposting>
Viele Grüße,
Christian-
» Bzw. was vermißt du an Perl, was andere "moderne Sprachen" können?
Eine Syntax, die nicht zum Erbrechen führt. *scnr*
Mir macht die Syntax und vor allem die Freiheit die Perl bietet, eigentlich nur Freude.
Struppi.
-
Hello,
» Bzw. was vermißt du an Perl, was andere "moderne Sprachen" können?
Eine Syntax, die nicht zum Erbrechen führt. *scnr*
Mir macht die Syntax und vor allem die Freiheit die Perl bietet, eigentlich nur Freude.
Was unterscheidet einen Masochisten von einem Anwendungsprogrammierer für C und Perl?
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Was unterscheidet einen Masochisten von einem Anwendungsprogrammierer für C und Perl?
Er liebt Fesseln, Ketten und Schläge? Denke ich auch immer, wenn ich Java Code sehe.
Struppi.
-
Hello,
Was unterscheidet einen Masochisten von einem Anwendungsprogrammierer für C und Perl?
Er liebt Fesseln, Ketten und Schläge? Denke ich auch immer, wenn ich Java Code sehe.
Das einzig wahre Programmiersystem ist sowieso Embarcadero :-D
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
-
Moin!
angeregt durch entsprechende Threads zu diesem Thema hier im Forum, hab ich heute einen kleinen aber feinen Artikel dazu geschrieben, hier ist er nun.
Ein schlechter Artikel, der vor allem durch die unwissentlichen Nebendetails Schaden anrichtet.
1. Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext. Problematisch ist dabei insbesondere das Abschneiden des Passworts auf 8 Zeichen maximal, sowie der schwache und heutzutage leicht knackbare DES-Algorithmus mit nur 56 Bit.
Minimum wäre an dieser Stelle sowas wie MD5 - auch das ist schon böse angegriffen worden, aber für kurze Passwortstrings vielleicht noch als gerade so ok anzusehen. Da aber überall, wo MD5 existiert, auch SHA-1, SHA-256 oder ggf. SHA-512 existieren, sollte man direkt diese Funktionen verwenden.
2. Die Zufälligkeit der Funktion makeSID wäre auch erst mal anzuzweifeln. Da stecken mir zu viele Informationen drin, die keinesfalls zufällig sind: Zeit in Sekunden, Prozess-ID, und eine "Auswahl" an Textzeichen, die aus irgendeinem Grund in ihrer Zeichenvielfalt eingeschränkt wurden.
Das allein sind für mich drei Anzeichen für "Vorsicht". Und da hilft auch nicht das Argument, dass die Funktion ja ausreichend "verschiedene" SIDs produziert und bei 500.000 Aufrufen kein Duplikat ausspuckt. Eine Zählschleife von 1 bis 500.000 produziert nämlich denselben Effekt.
Nur mal so angedacht: Wenn der eine Request dem Opfer eine SID generiert, dann hat ein Angreifer im besten Fall eine ganze Sekunde lang Zeit, mit massenhaften Requests dieselbe Prozess-ID wie das Opfer zu bekommen - wenn er dann noch den Zufallsgenerator passend auf Startwert setzen kann (seed), dann kann er dieselbe SID bekommen.
Wo kommt die Funktion her? Wer garantiert für ihre Zuverlässigkeit? Mit Eigenproduktionen erleidet man sehr leicht Schiffbruch!
3. Die Forderung, die Session-ID in einer Datenbank explizit mit UNIQUE-Index abzuspeichern, um Duplikate zu verhindern, ist absurd. Eine vernünftige SID-Funktion produziert ausreichend sicher keine Duplikate.
4. Warum wird kein Session-Framework aus CPAN benutzt? CPAN ist doch der Stolz der Perl-Community, weil da die Perlen der beliebig erweiterbaren Perl-Funktionalität gespeichert sind. Mit Apache::Session und CGI::Session stehen zwei Pakete bereit, die ausreichend hohe Versionsnummern haben und sich irgendwie anbieten.
Bei PHP würde niemand auf die Idee kommen, den Standardmechanismus zu ignorieren und immer selbst was zu schreiben. Klassischer Fall von NIH-Syndrom, würde ich meinen.
- Sven Rautenberg
-
Minimum wäre an dieser Stelle sowas wie MD5 -
tut er doch?
- Die Zufälligkeit der Funktion makeSID wäre auch erst mal anzuzweifeln. Da stecken mir zu viele Informationen drin, die keinesfalls zufällig sind: Zeit in Sekunden, Prozess-ID, und eine "Auswahl" an Textzeichen, die aus irgendeinem Grund in ihrer Zeichenvielfalt eingeschränkt wurden.
- Warum wird kein Session-Framework aus CPAN benutzt? CPAN ist doch der Stolz der Perl-Community, weil da die Perlen der beliebig erweiterbaren Perl-Funktionalität gespeichert sind. Mit Apache::Session und CGI::Session stehen zwei Pakete bereit, die ausreichend hohe Versionsnummern haben und sich irgendwie anbieten.
Die Standardvariante von CGI::Session arbeitet ähnlich dem von Rolf gezeigten Beispiel, es verwendet statt eines Zufallszeichenkette halt eine Zufallszahl.
sub generate_id { my $self = shift; my $md5 = new Digest::MD5(); $md5->add($$ , time() , rand(9999) ); return $md5->hexdigest(); }Wobei ich hier noch statt time() auf Sekundenbasis, mit dem time von dem Modul HiRes::Time auf Millisekunden arbeiten würde. Das dürfte für eine Session ID ausreichen, zumal diese ja gar keine Information enthält, die es zu entschlüsseln gäbe.
Der Hinweis auf die Module bei CPAN ist sicher richtig, aber in einem Artikel, der die Technik beschreiben soll, bringt das ja nicht viel.
Struppi.
-
hi,
Der Hinweis auf die Module bei CPAN ist sicher richtig, aber in einem Artikel, der die Technik beschreiben soll, bringt das ja nicht viel.
Ja, genauso ist das und auch daher dieser Artikel, danke Struppi. Er soll das Hintergrundwissen vermitteln, was denen evntl. abgeht, die mit Funktionen von 4GL nur so um sich schmeißen, dabei gar nicht wissen, was dabei gemacht wird und dann eine ganze Programmiersprache in die Tonne treten, weil auf heise.de irgendwelche Sicherheitslücken bekannt werden.
Das ist wie mit denen, die ständig ihre Fotos verwackeln und dann von schlechten Gläsern sprechen.
Btw., Sven#, es ist ja nun egal, wie stark die Verschlüsselung eines Passworts ist, wenn dies auf einem Server liegt, auf dem sich ohnehin vertrauliche Daten befinden. Das Prinzip einer Einwegverschlüsselung zu erklären, das habe ich nun mal mit crypt() gemacht und wer das dann mit anderen Mechanismen programmiert, die gleichermaßen funktionieren, der kann das auch nur dann, wenn er das Prinzip verstanden hat.
Ja und Tom, danke für Deinen Hinweis zum Abschnitt Sicherheit, ein falsches Passwort eintippen, das kann jedem mal passieren, aber mit einer ungültigen Session-ID daherkommen, das ist programmiertechnisch auf jeden Fall als Betrug zu werten, darum werde ich den Artikel noch ergänzen.
Und überhaupt würde ich mich sehr freuen, einen ähnlichen Artikel zu diesem Thema im SELF-Raum lesen zu dürfen und nicht ständig irgendwelche Hinweise auf eine dämliche Wette, die jedesmal zitiert wird, wenn das Thema Encryption zur Sache kommt.
Viele Grüße an Alle,
Horst--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Moin!
»» Der Hinweis auf die Module bei CPAN ist sicher richtig, aber in einem Artikel, der die Technik beschreiben soll, bringt das ja nicht viel.
Ja, genauso ist das und auch daher dieser Artikel, danke Struppi. Er soll das Hintergrundwissen vermitteln, was denen evntl. abgeht, die mit Funktionen von 4GL nur so um sich schmeißen, dabei gar nicht wissen, was dabei gemacht wird und dann eine ganze Programmiersprache in die Tonne treten, weil auf heise.de irgendwelche Sicherheitslücken bekannt werden.
Wenn der Artikel das soll, dann scheitert er auch an diesem Anspruch.
Btw., Sven#, es ist ja nun egal, wie stark die Verschlüsselung eines Passworts ist, wenn dies auf einem Server liegt, auf dem sich ohnehin vertrauliche Daten befinden. Das Prinzip einer Einwegverschlüsselung zu erklären, das habe ich nun mal mit crypt() gemacht und wer das dann mit anderen Mechanismen programmiert, die gleichermaßen funktionieren, der kann das auch nur dann, wenn er das Prinzip verstanden hat.
Wenn der Artikel auf das Publikum abzielt, welches kein Hintergrundwissen hat, dann ist der Absatz zur Passwortbehandlung eindeutig mangelhaft. Der Punkt ist: Gerade diejenigen, denen das Hintergrundwissen eher fehlt, werden sich aufgrund des Artikele eher nicht dazu berufen fühlen, nach noch besseren Mechanismen zu suchen, sondern verwenden das, was vorgestellt wird.
Und crypt() schneidet nun mal Passworte nach 8 Zeichen ab. Und das ist MEGASCHLECHT. Egal wie leicht man ansonsten den Hashwert rückrechnen bzw. ein dazu passendes Passwort ermitteln könnte. Denn der Verzicht auf crypt bringt kurioserweise eine deutlich höhere Passwortsicherheit in dem Artikel-Szenario, weil sie dann wesentlich länger sein können.
Und überhaupt würde ich mich sehr freuen, einen ähnlichen Artikel zu diesem Thema im SELF-Raum lesen zu dürfen und nicht ständig irgendwelche Hinweise auf eine dämliche Wette, die jedesmal zitiert wird, wenn das Thema Encryption zur Sache kommt.
Der Hinweis kommt immer dann, wenn jemand glaubt, in Kryptodingen durch selbstausgedachtes schlauer zu sein, als die Wissenschaft. Und er ist in 100% der Fälle berechtigt.
Deshalb kriegst du die Verwendung von crypt um die Ohren gehauen, und auch deine in dem anderen Thread aufgetauchte Verschlüsselungsfunktion. Und zwar immer zu Recht, und immer mit dem leuchtenden Beispiel des hier im Forum dokumentierten Scheiterns solch einer Funktion - als warnendes Beispiel für alle diejenigen, die in derselben Situation sind und sich überlegen, ebenfalls selbst erdachtes Krypto anzuwenden.
Die Tatsache, dass du aus dieser Geschichte nichts lernst oder lernen willst, ist eigentlich bezeichnend.
- Sven Rautenberg
-
Und crypt() schneidet nun mal Passworte nach 8 Zeichen ab. Und das ist MEGASCHLECHT.
Kommt aber durchaus zum Einsatz, z.b. bei .htaccess
und deine Aussage: "Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext" - ist nicht zielführend, da jede Art von Verschlüsselung besser ist als keine. Jeder Versuch eine Verschlüsselung zu knacken ist strafbar.
Deshalb kriegst du die Verwendung von crypt um die Ohren gehauen, und auch deine in dem anderen Thread aufgetauchte Verschlüsselungsfunktion.
Falls du die meinst, um eine SID zu erzeugen, ich habe hier im Forum bisher noch keine andere gesehen, auch die beiden von dir erwähnten Module verwenden genau den gleichen Mechanimus, nur mit einem noch geringeren Zufall. Insofern scheint deine Kritik daran unberechtigt zu sein (wie die "ausreichend hohe Versionsnummern" ja zeigen).
Struppi.
-
Hallo
»» Und crypt() schneidet nun mal Passworte nach 8 Zeichen ab. Und das ist MEGASCHLECHT.
Kommt aber durchaus zum Einsatz, z.b. bei .htaccess
*Kann* dort zum Einsatz kommen.
und deine Aussage: "Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext" - ist nicht zielführend, da jede Art von Verschlüsselung besser ist als keine. Jeder Versuch eine Verschlüsselung zu knacken ist strafbar.
Unabhängig davon, wie geknackt, wie kurz und dementsprechend unsicher crypt ist, kann man mit *dem* Argument auch den Waffenbesitz völlig freigeben. Mord ist mithin auch strafbar.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3-
» und deine Aussage: "Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext" - ist nicht zielführend, da jede Art von Verschlüsselung besser ist als keine. Jeder Versuch eine Verschlüsselung zu knacken ist strafbar.
Unabhängig davon, wie geknackt, wie kurz und dementsprechend unsicher crypt ist, kann man mit *dem* Argument auch den Waffenbesitz völlig freigeben. Mord ist mithin auch strafbar.
Diese Argumentation verstehe ich nicht.
Wenn du einen Brief in einem geschlossenem Umschlag öffnest, begehst du eine Straftat, wenn du eine Postkarte liest nicht. Wenn du dein Auto nicht abschliest begeht du eine Ordnungswidrigkeit, wenn du es zumachst, egal mit was für einen noch so leicht knackbaren Schloss, ist es ok.
Es geht nicht darum ob und wie leicht etwas knackbar ist, sondern dass in dem Moment wo es jemand versucht, eine Straftat begeht, die verfolgt werden kann, wenn das Passwort unverschlüsselt ist (und es öffentlich zugänglich wäre), dann wäre es keine.
Struppi.
-
Hallo
»» » und deine Aussage: "Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext" - ist nicht zielführend, da jede Art von Verschlüsselung besser ist als keine. Jeder Versuch eine Verschlüsselung zu knacken ist strafbar.
»»
»» Unabhängig davon, wie geknackt, wie kurz und dementsprechend unsicher crypt ist, kann man mit *dem* Argument auch den Waffenbesitz völlig freigeben. Mord ist mithin auch strafbar.Diese Argumentation verstehe ich nicht.
Wenn du einen Brief in einem geschlossenem Umschlag öffnest, begehst du eine Straftat, wenn du eine Postkarte liest nicht. Wenn du dein Auto nicht abschliest begeht du eine Ordnungswidrigkeit, wenn du es zumachst, egal mit was für einen noch so leicht knackbaren Schloss, ist es ok.
Es geht nicht darum ob und wie leicht etwas knackbar ist, sondern dass in dem Moment wo es jemand versucht, eine Straftat begeht, die verfolgt werden kann, wenn das Passwort unverschlüsselt ist (und es öffentlich zugänglich wäre), dann wäre es keine.
Schön und gut. Bleiben wir bei .htaccess. Oft wird nur der authType basic verwandt, bei dem das Passwort im Klartext an den Server übermittelt wird. Fällt das dann auch unter $ 202 a oder nicht (weil es nach meiner Interpretation deiner Ausführungen und des Gesetzestexts[1] "öffentlich zugänglich" übermittelt wird)?
Meine Polemik bezog sich im übrigen darauf, _dass_ etwas strafrechtlich verfolgbar ist. Wie gesagt, Mord ist es auch. *Wenn wir uns darauf verließen* (was wir aus gutem Grund nicht tun), dass wegen des Verbots Morde unterlassen würden bzw. die Verfolgung der erfolgten Straftat ausreichen, bräuchten wir keinerlei Einschränkung im Waffenrecht.
[1] ... wobei ich mir beim Gesetzestext nicht ganz sicher bin.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3-
» Es geht nicht darum ob und wie leicht etwas knackbar ist, sondern dass in dem Moment wo es jemand versucht, eine Straftat begeht, die verfolgt werden kann, wenn das Passwort unverschlüsselt ist (und es öffentlich zugänglich wäre), dann wäre es keine.
Schön und gut. Bleiben wir bei .htaccess. Oft wird nur der authType basic verwandt, bei dem das Passwort im Klartext an den Server übermittelt wird. Fällt das dann auch unter $ 202 a oder nicht (weil es nach meiner Interpretation deiner Ausführungen und des Gesetzestexts[1] "öffentlich zugänglich" übermittelt wird)?
Keine Ahnung ich bin kein Jurist, da steht nur etwas von "unter Überwindung der Zugangssicherung", und ob das ausspähen von unverschlüsselten Passwörtern darunter fällt, kann ich nicht sagen
Meine Polemik bezog sich im übrigen darauf, _dass_ etwas strafrechtlich verfolgbar ist.
Genau darauf zielte aber meine Aussage nicht ab. Durch das verschlüsseln, wird das lesen von Daten ja strafrechtlich verfolgbar. Deshalb habe ich deine Ausführung auch nicht verstanden. Mord wird ja nicht erst durch das Verbot von Waffen strafbar.
Struppi.
-
Hallo
»» » Es geht nicht darum ob und wie leicht etwas knackbar ist, sondern dass in dem Moment wo es jemand versucht, eine Straftat begeht, die verfolgt werden kann, wenn das Passwort unverschlüsselt ist (und es öffentlich zugänglich wäre), dann wäre es keine.
»»
»» Schön und gut. Bleiben wir bei .htaccess. Oft wird nur der authType basic verwandt, bei dem das Passwort im Klartext an den Server übermittelt wird. Fällt das dann auch unter $ 202 a oder nicht (weil es nach meiner Interpretation deiner Ausführungen und des Gesetzestexts[1] "öffentlich zugänglich" übermittelt wird)?Keine Ahnung ich bin kein Jurist, da steht nur etwas von "unter Überwindung der Zugangssicherung", und ob das ausspähen von unverschlüsselten Passwörtern darunter fällt, kann ich nicht sagen
<zitat src="[link:http://dejure.org/gesetze/StGB/202a.html]">Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.</zitat>Tja, Juristensprache eben. *Falls* ich das richtig interpretiere, kommt es auf das "und" an (... Zugang zu Daten, die nicht für ihn bestimmt *und* die gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung ...). Die Daten müssen eben nicht nur für jemanden nicht bestimmt sein, sie müssen *auch* gegen unberechtigten Zugriff besonders gesichert sein. Dazu dürfte neben einem gecrypteten Passwort ansich auch das per Passwort gesicherte und/oder verschlüsselte Verzeichnis oder die entsprechend behandelte Partition zählen.
»» Meine Polemik bezog sich im übrigen darauf, _dass_ etwas strafrechtlich verfolgbar ist.
Genau darauf zielte aber meine Aussage nicht ab. Durch das verschlüsseln, wird das lesen von Daten ja strafrechtlich verfolgbar. Deshalb habe ich deine Ausführung auch nicht verstanden. Mord wird ja nicht erst durch das Verbot von Waffen strafbar.
Ach Mönsch, du suchst *zu tief* in den Details.
Tschö, Auge
--
Verschiedene Glocken läuteten in der Stadt, und jede von ihnen vertrat eine ganz persönliche Meinung darüber, wann es Mitternacht war.
Terry Pratchett, "Wachen! Wachen!"
Veranstaltungsdatenbank Vdb 0.3
-
-
-
-
-
Moin!
»» Und crypt() schneidet nun mal Passworte nach 8 Zeichen ab. Und das ist MEGASCHLECHT.
Kommt aber durchaus zum Einsatz, z.b. bei .htaccess
Nur, wenn man tatsächlich gecryptete Passworte explizit will - was man nicht tun sollte. Apache kann schon seit geraumer Zeit auch MD5 und SHA, vgl. Kommandozeilenoptionen -m und -s des Tools "htpasswd".
und deine Aussage: "Die Verwendung von crypt ist in der klassischen Variante gemeingefährlich und entspricht de facto der Verwendung von Klartext" - ist nicht zielführend, da jede Art von Verschlüsselung besser ist als keine. Jeder Versuch eine Verschlüsselung zu knacken ist strafbar.
Pfft. Erstmal: Es ist keine Verschlüsselung. Zweitens ist die Kürzung des Passwortes auf 8 relevante Zeichen gemeingefährlich gegenüber dem User. Drittens: Was interessiert den kriminellen Angreifer irgendein weiteres Gesetz, gegen das er verstößt?
»» Deshalb kriegst du die Verwendung von crypt um die Ohren gehauen, und auch deine in dem anderen Thread aufgetauchte Verschlüsselungsfunktion.
Falls du die meinst, um eine SID zu erzeugen, ich habe hier im Forum bisher noch keine andere gesehen, auch die beiden von dir erwähnten Module verwenden genau den gleichen Mechanimus, nur mit einem noch geringeren Zufall. Insofern scheint deine Kritik daran unberechtigt zu sein (wie die "ausreichend hohe Versionsnummern" ja zeigen).
Man gut, dass du so aufmerksam liest und nicht merkst, worauf sich dieser letzte Satz bezieht. Nein, von der SID ist nicht die Rede. https://forum.selfhtml.org/?t=187307&m=1244817
- Sven Rautenberg
-
Pfft. Erstmal: Es ist keine Verschlüsselung. Zweitens ist die Kürzung des Passwortes auf 8 relevante Zeichen gemeingefährlich gegenüber dem User. Drittens: Was interessiert den kriminellen Angreifer irgendein weiteres Gesetz, gegen das er verstößt?
Ich gehe also davon aus, dass du deine Wohnung oder dein Auto mit immer dem neuesten und besten Schlössern sicherst, da du ansonsten ja auch alles offen lassen könntest?
Man gut, dass du so aufmerksam liest und nicht merkst, worauf sich dieser letzte Satz bezieht. Nein, von der SID ist nicht die Rede. https://forum.selfhtml.org/?t=187307&m=1244817
Tschuldigung das habe ich nicht rausgelesen. Ich dachte halt, weil du die SID Funktion auch bemäkelt hattest, dass du diese meinst. Dann hast du die falsche Kritik daran eingesehen?
Struppi.
-
Moin!
Tschuldigung das habe ich nicht rausgelesen. Ich dachte halt, weil du die SID Funktion auch bemäkelt hattest, dass du diese meinst. Dann hast du die falsche Kritik daran eingesehen?
Nein. Denn die Frage ist: Wo kriegt Perl seinen "Zufall" her? Und wird der Zustand des Zufallsgenerators eventuell irgendwie fix setzbar, bzw. ist er auslesbar. Wo wird beispielsweise überall srand() verwendet?
Weiterhin ist die Frage nicht diskutiert, warum zur Bildung eines Zufallsstrings nur eine eingeschränkte Zeichenmenge verwendet wird, und warum der gebildete String genauso lang ist, wie die Anzahl der Zeichen, aus denen er gebildet wird.
Zu guter letzt ist natürlich die Grundsatzkritik: Warum etwas selbst programmieren, was bestenfalls nur genauso gut, wahrscheinlich aber schlechter und unsicherer ist, wenn es dafür schon fertige Module gibt?
- Sven Rautenberg
-
Zu guter letzt ist natürlich die Grundsatzkritik: Warum etwas selbst programmieren, was bestenfalls nur genauso gut, wahrscheinlich aber schlechter und unsicherer ist, wenn es dafür schon fertige Module gibt?
wie gesagt, um die Technik zu erklären (allerdings fehlt dann berechtigterweise der Hinweis auf die Module).
und wegen dem "wahrscheinlich schlechter".
Das ist aus CGI::Session::ID::MD5
sub generate_id { my $self = shift; my $md5 = new Digest::MD5(); $md5->add($$ , time() , rand(9999) ); return $md5->hexdigest(); }Das von Rolf
sub makeSID{ my @chars = ('A' .. 'Z', 'a' .. 'z', 0 .. 9, '+', '-'); my $len = scalar @chars; my $id .= time(); $id .= $$; for(my $i = 0; $i < $len; $i++){ $id .= $chars[int(rand($len))]; } $id = substr($id, 0, $len); $id = md5_hex($id); return $id; }Da ist, soweit ich das erkennen kann, die Version von Rolf um einiges mehr zufällig.
Struppi.
-
-
Hello,
Ich gehe also davon aus, dass du deine Wohnung oder dein Auto mit immer dem neuesten und besten Schlössern sicherst, da du ansonsten ja auch alles offen lassen könntest?
Das ist lustig.
Ich habe hier noch ein uraltes Chubbschloss in meiner Haustür.Neulich habe ich mit unserem örtlichen Schlüsseldienst mal beim Bier darüber gewitzelt, dass ich ja sowieso ein "öffenes Haus" hätte...
Er meinte dann, dass er sich an dem Schloss schon mal die Zähne ausgebissen hat, als er mal für meine Mutter die Tür öffnen sollte. Mit einem "modernen" Zylinderschloss braucht er Dank des Besitzes der passenden Schlagschlüssel nur ca. 3-5 Sekunden. Für das Chubbschloss (mit hinterschnittener Matritze) hat er über eine Stunde benötigt.
Und dabei ist das doch nur Safety by Obscurity :-)
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
-
-
Hello,
- Die Zufälligkeit der Funktion makeSID wäre auch erst mal anzuzweifeln. Da stecken mir zu viele Informationen drin, die keinesfalls zufällig sind: Zeit in Sekunden, Prozess-ID, und eine "Auswahl" an Textzeichen, die aus irgendeinem Grund in ihrer Zeichenvielfalt eingeschränkt wurden.
Das allein sind für mich drei Anzeichen für "Vorsicht". Und da hilft auch nicht das Argument, dass die Funktion ja ausreichend "verschiedene" SIDs produziert und bei 500.000 Aufrufen kein Duplikat ausspuckt. Eine Zählschleife von 1 bis 500.000 produziert nämlich denselben Effekt.
Nur mal so angedacht: Wenn der eine Request dem Opfer eine SID generiert, dann hat ein Angreifer im besten Fall eine ganze Sekunde lang Zeit, mit massenhaften Requests dieselbe Prozess-ID wie das Opfer zu bekommen - wenn er dann noch den Zufallsgenerator passend auf Startwert setzen kann (seed), dann kann er dieselbe SID bekommen.
Das verstehe ich jetzt nicht ganz. Bitte stelle das noch klarer:
a) man muss eine zur Zeit gültige SID auswürfeln oder besser sauber ermitteln...
soweit stimme ich Dir zu, dass eine Zählschleife bis 500.000 schnell durchlaufen istb) ob die SID gültig ist, kann man jedoch nur mittels passendem Request feststellen
der muss also auch durchgeführt werden und kostet Zeit, auch wenn ich 1000 zur gleichen
Zeit absenden kann (sie müssen ja auch angenommen werden).c) ob ich nun z.B. bei einer 200er Antwort den Anzugreifenden mit seiner SID getroffen habe
oder nur irgendeine gerade gültige Session-ID, ist ungeklärt. Auch das muss noch
ermittelt werden und kostet (etwas) Zeit.d) was sollte bezüglich der Sicherheit bei einer falschen oder abgelaufenen Session-ID
geschehen?Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin!
»» 2. Die Zufälligkeit der Funktion makeSID wäre auch erst mal anzuzweifeln. Da stecken mir zu viele Informationen drin, die keinesfalls zufällig sind: Zeit in Sekunden, Prozess-ID, und eine "Auswahl" an Textzeichen, die aus irgendeinem Grund in ihrer Zeichenvielfalt eingeschränkt wurden.
»»
»» Das allein sind für mich drei Anzeichen für "Vorsicht". Und da hilft auch nicht das Argument, dass die Funktion ja ausreichend "verschiedene" SIDs produziert und bei 500.000 Aufrufen kein Duplikat ausspuckt. Eine Zählschleife von 1 bis 500.000 produziert nämlich denselben Effekt.
»»
»» Nur mal so angedacht: Wenn der eine Request dem Opfer eine SID generiert, dann hat ein Angreifer im besten Fall eine ganze Sekunde lang Zeit, mit massenhaften Requests dieselbe Prozess-ID wie das Opfer zu bekommen - wenn er dann noch den Zufallsgenerator passend auf Startwert setzen kann (seed), dann kann er dieselbe SID bekommen.Das verstehe ich jetzt nicht ganz.
Erneutes Lesen hilft vielleicht.
a) man muss eine zur Zeit gültige SID auswürfeln oder besser sauber ermitteln...
soweit stimme ich Dir zu, dass eine Zählschleife bis 500.000 schnell durchlaufen istDu hast nicht verstanden, worauf sich 500.000 bezieht.
b) ob die SID gültig ist, kann man jedoch nur mittels passendem Request feststellen
der muss also auch durchgeführt werden und kostet Zeit, auch wenn ich 1000 zur gleichen
Zeit absenden kann (sie müssen ja auch angenommen werden).Ja und? Erstmal will ich innerhalb einer Sekunde mit gesetztem identischen Zufallszahlengenerator alle 65536 Prozess-IDs - oder zumindest alle die, die derzeit von einem Webserverprozess belegt sind - abgreifen und in nutzbare Session-IDs verwandeln. Die Prüfung auf Gültigkeit kommt dann später und hat Zeit.
c) ob ich nun z.B. bei einer 200er Antwort den Anzugreifenden mit seiner SID getroffen habe
oder nur irgendeine gerade gültige Session-ID, ist ungeklärt. Auch das muss noch
ermittelt werden und kostet (etwas) Zeit.Ja und? Ob die Session "aktiv" ist im Sinne von "wurde gerade von einem User initiiert, und ich habe die SID richtig geraten", zeigt sich recht schnell, wenn man dann einfach die Seite mit den Benutzereinstellungen aufruft, oder sonst wahrnehmbare Zeichen für den Namen des eingeloggten Users betrachtet.
d) was sollte bezüglich der Sicherheit bei einer falschen oder abgelaufenen Session-ID
geschehen?Nichts. Die Session-ID hat außer der Identifikation "desselben" Browsers keine Bedeutung und insbesondere keine zeitliche Begrenzung ihrer Gültigkeitsdauer.
- Sven Rautenberg
-