Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]5766[/thread]

zeitlimitierter Zugangscode: mal wieder so ne abgedrehte Idee



<< |< 1 2 >| >> 16 Einträge, 2 Seiten
macMeck
 2003-09-26 07:06
#57146 #57146
User since
2003-08-04
162 Artikel
BenutzerIn
[default_avatar]
Ich hab da mal wieder so n Problemchen wo ich eure Hilfe brauche. Ich will einen Zugangscode erstellen, der nur fuer eine gewisse Zeit gueltig ist. Soll heissen, dass irgendwie die Zeit darin verschluesselt sein soll, der Code natuerlich nicht zu knacken sein soll ( :laugh: ) und der Zugangscode jedesmal wie wirklich zufaellig aussehen soll.
Habt ihr da ein paar Tipps, was man dabei beachten sollte (und kommt jetzt nicht mit: das Verfallsdatum sollte nicht im Klartext drinstehen) oder ein paar Snipplets falls ihr sowas in der Art schon mal was gemacht habt...

macMeck
It all works, as long as it's documented!
eisbeer
 2003-09-26 08:30
#57147 #57147
User since
2003-08-29
347 Artikel
BenutzerIn
[Homepage] [default_avatar]
Du könntest einen Mix aus zufälligen Zahlen
und der Funktion time() machen. die verschlüsselst
du dann auch und splitest sie vielleicht auf
und beim auswerten decodierst du sie wieder
und hast den genauen Zeitpunkt, wann der
Schlüssel generiert wurde !
Die meisten PC Probleme befinden sich zwischen Bildschirm und Stuhl...
macMeck
 2003-09-29 05:21
#57148 #57148
User since
2003-08-04
162 Artikel
BenutzerIn
[default_avatar]
Okay, ich hab mir das am Wochenende nochmal durchdacht und dabei festgestellt, dass ich die Problemstellung etwas genauer erklaeren sollte, so wie sie mir jetzt im Kopf rumgeistert.
Das ganze soll am Ende dafuer gut sein, um abzusichern, dass ein Client nur dann laufen kann, wenn er vorher vom Server dazu bis zu einem bestimmten Datum berechtigt worden ist. Damit der Client jetzt nicht bei jedem Start den Server kontaktieren muss, soll er sich lokal jeweils abspeichern wie lange er lauffaehig ist und erst wenn dieser Zeitraum abgelaufen ist, beim Server "um Verlaengerung" bitten. Bekommt er diese, wird das wieder gespeichert, bekommt er sie nicht, kann er nicht starten und versucht beim naechsten Neustart wieder zuerst den Server zu kontaktieren.

Wie soll das ganze jetzt ablaufen:

1. Client startet, hat keine aktuelle Berechtigung und kontaktiert also den Server.
2. Server checkt intern, ob der Client noch ne Berechtigung hat und erstellt dann einen Code, der das verschluesselte Datum beinhaltet.
3. Client liest das Ergebnis vom Server und faehrt entweder fort oder bricht ab.

Die Verschluesselung sollte so sein, dass sie lediglich verglichen, aber nicht decodiert werden kann. Das heisst so in der Art von UNIX-Passwoertern. Das Problem hierbei ist aber, dass ich nicht genau pruefen kann (sonst muesste ich ja jedes Datum in der Zukunft pruefen), sondern eine gewisse Systematik in die verschluesselten codes bringen muss, damit ich die auch mit <= bzw. >= Operatoren vergleichen kann. Darin liegt wohl die gesamte Schwierigkeit des Problems.

Jetzt noch jemand ne Idee? :rock:

macMeck\n\n

<!--EDIT|macMeck|1064798573-->
It all works, as long as it's documented!
popcorn5
 2003-09-29 05:50
#57149 #57149
User since
2003-09-24
60 Artikel
BenutzerIn
[default_avatar]
wie bitte ???

naja gut... dann wollen wir dir mal helfen !

warum soll der client nicht den server kontaktieren ?
funktioniert doch auf fast jeder webseite heute so.
ein vergleich, wie ich das immer mache:

eine webseite, jeder link beinhaltet eine SID (Session ID).
aufm server sind zu dieser sid laufzeit und diverse andere sachen wie angemeldeter user usw. gespeichert.
Diese SID verfällt nach eineriger zeit wo der client sich net beim server meldet. jedesmal wenn also ein link angeklickt wird, schaut der server erst mal nach der laufzeit und dann nach den rechten usw.

da es sich bei deiner aktion wohl nicht um ne page handelt, musst du ne abfrage in zeitabständen oder bei aktionen machen. ist die sid noch gültig gehts weiter, wenn nicht...
ganz easy ;)

wie wäre es denn mit sowas ? ist doch viel sicherer als die laufzeit mit in den code zu packen. und unknackbar ist gar nix ! auch kein crypt !
und wenn du so einen vergleich bauen willst, dann muss in dem script was auf dem client läuft ja auch der code sein, wie es verschlüsselt wird. das wäre dann ein leichtes für leute wie mich :)))

ich zeige jetzt hier nicht meinen code, aber wenn interesse besteht, kann ich dir das mailen (sind schon ein paar zeilen, passt hier net rein).\n\n

<!--EDIT|popcorn5|1064801001-->
format_c
 2003-09-29 11:20
#57150 #57150
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
[quote=macMeck,29.09.2003, 03:21]Die Verschluesselung sollte so sein, dass sie lediglich verglichen, aber nicht decodiert werden kann. Das heisst so in der Art von UNIX-Passwoertern. Das Problem hierbei ist aber, dass ich nicht genau pruefen kann (sonst muesste ich ja jedes Datum in der Zukunft pruefen), sondern eine gewisse Systematik in die verschluesselten codes bringen muss, damit ich die auch mit <= bzw. >= Operatoren vergleichen kann. Darin liegt wohl die gesamte Schwierigkeit des Problems.

Jetzt noch jemand ne Idee? :rock:

macMeck[/quote]
Wenn da eine Systematik drin wäre, wäre die Funktion crypt sinnlos. Klar steckt da ein gewisser Algorithmus dahinter, gibt aber nur wenig Leute die den verstehen.

Ich glaube da willst du eine seht hohe Wand bezwingen.
Sorry dazu hab ich keinen Ansatz.

Gruß Alex
jan10001
 2003-09-29 12:34
#57151 #57151
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Eigentlich kommt es nur darauf an wie sicher es sein soll, da hast du zwei Möglichkeiten:

1. Symmetrische Verschlüsselung, Client und Server benutzen einen gemeinsamen Schlüssel zum Ent- und Verschlüsseln.

2. Asymmetrische Verschlüsselung, Client und Server benutzen unterschiedliche Schlüssel zum Ent- und Verschlüsseln.

Für beide Möglichkeiten mußt du von Cpan das/die passende/n Crypt Modul/e laden und installieren.\n\n

<!--EDIT|jan10001|1064824515-->
Geewiz
 2003-09-29 13:20
#57152 #57152
User since
2003-09-29
69 Artikel
BenutzerIn
[Homepage] [default_avatar]
Auch ich würde das über eine Session-ID machen. popcorn5 macht da einen sehr praxisnahen Vorschlag. Eine SID enthält selbst keinerlei Informationen über den Session-Kontext (Laufzeit, Username o.ä.), sondern ist nur ein Schlüssel einer Datenbank auf dem Server. Der Server nutzt also die SID, um an die Kontext-Infos in seiner DB zu kommen. Damit ändert sich an der SID auch nichts, wenn sich an den Kontext-Infos was ändert. Und um geknackte Verschlüsselung musst du dir dann keine Sorgen machen. Du musst ggf. lediglich sicherstellen, dass keiner eine gültige SID kapert, zum Beispiel durch Verknüpfung mit der Client-Adresse und SSL-Verschlüsselung.
jan10001
 2003-09-29 15:06
#57153 #57153
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Quote
Auch ich würde das über eine Session-ID machen. popcorn5 macht da einen sehr praxisnahen Vorschlag....
Damit erreicht er aber nicht das, was er möchte. :) So wie ich ihn verstehe, ist der "Client" ein eigenständiges Programm das nur für einen bestimmten Zeitraum funktionieren darf. ( Das heißt es braucht keinen Server! ) Ist dieser Zeitraum überschritten soll das Programm den Server kontakten und sich ne neue Berechtigung holen.\n\n

<!--EDIT|jan10001|1064833613-->
macMeck
 2003-09-29 18:17
#57154 #57154
User since
2003-08-04
162 Artikel
BenutzerIn
[default_avatar]
[quote=jan10001,29.09.2003, 13:06]Damit erreicht er aber nicht das, was er möchte. :) So wie ich ihn verstehe, ist der "Client" ein eigenständiges Programm das nur für einen bestimmten Zeitraum funktionieren darf. ( Das heißt es braucht keinen Server! ) Ist dieser Zeitraum überschritten soll das Programm den Server kontakten und sich ne neue Berechtigung holen.[/quote]
Ganz genau so schauts aus. Ich werde mir die entsprechenden Module mal anschauen...

Danke für eure Hilfe...

macMeck
It all works, as long as it's documented!
Geewiz
 2003-09-29 19:09
#57155 #57155
User since
2003-09-29
69 Artikel
BenutzerIn
[Homepage] [default_avatar]
Das mit dem eigenständigen Client hatte ich nicht verstanden. In diesem Fall muss natürlich die Frist übertragen werden. Die Verschlüsselung würde ich abhängig von einer Client-Kennung mit einem der Crypt::* Module machen.
<< |< 1 2 >| >> 16 Einträge, 2 Seiten



View all threads created 2003-09-26 07:06.