Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: loginlog

  1. #1

    loginlog

    achja, mal wieder eine neue Website am Start.
    http://www.loginlog.com (bzw. http://www.loginlog.de) ist eine neue sicherheits Idee von mir, die account misbrauch aktiv verhindern soll.

    Ist erst halb öffentlich,da noch nicht auf deutsch und da ich noch weitere partner webseiten suche, die meine api implementieren. (Da helfe ich auch gerne). Es sind deswegen leider noch keine anmeldungen von usern möglich. Wer als entwickler interessiert ist, mal auf die rechte untere ecke klicken... oder hier rein posten

  2. #2
    Angelback
    Guest
    Verstehe ich das richtig? Das Tool informiert den Account-Inhaber über sämtliche Logins. Und meldet darüberhinaus per einstellbarem Medium (Handy , Mail und co ), falls es Hackversuche feststellt?

    Läuft das Tool unabhängig von deinem Server?
    Was versprichst du dir davon, oder anders gefragt - welche Gegenleistung erwartest du dafür?
    Könntest du das auch als Modul für gängige CMS fertigen (Typo3, Joomla, Drupal?)

    Ich finde die Idee klasse, (also gibt's natürlich schon, ob als Opensource, weiß ich jetzt nicht). Würde es evtl. einbauen wollen, wenn ich es benötige. Arbeite gerade an einem Projekt (weiß noch nicht, ob es auch online geht) mit Login usw.
    Ist aber auf Typolight aufgesetzt.

  3. #3
    Weitesgehend richtig . Leider kann man nicht alle Hackversuche automatisch feststellen. Eine der Kernideen war, dass alle Logins aufgezeichnet werden, sodass man im Zweifelsfall auch manuell nachsehen kann wenn etwas nicht stimmt.

    Läuft das Tool unabhängig von deinem Server?
    Hier muss ich ein wenig weiter ausholen. Natürlich könnte man ein Skript lokal auf seinem Server installieren welches alle logins loggt. Hier würde jedoch jede Seite ihr eigenes ding bauen, welches im Endeffekt unüberschaubar wird. Der Vorteil von loginlog ist, dass alles zentral gespeichert und ausgewertet wird. Alle Websiten die loginlog verwenden übertragen die logindaten an den Account des Users bei uns. Vorteilhaft ist hierbei die zentrale Übersicht über alle Accounts, die ständige Weiterentwicklung der Filter sowie müssen Filter nur an einer stelle konfiguriert werden. Auch der Urlaubsmodus (temporäre Sperrung aller Accounts) muss nur einmal aktiviert werden. Die Software läuft also auf meinem Server, jedoch wird selbst bei einem Ausfalls meines Servers der Websitebetrieb nicht behindert.


    Was versprichst du dir davon, oder anders gefragt - welche Gegenleistung erwartest du dafür?
    Meine Server haben Kapazitäten die genutzt werden wollen

    Könntest du das auch als Modul für gängige CMS fertigen (Typo3, Joomla, Drupal?)
    Wird kommen. Joomla,typo3 sind schon in Arbeit, in Drupal muss ich mich noch einarbeiten.



    Beim Einbauen kann ich gerne helfen. Am beispiel für phpBB kann man sehen, dass es selbst mit Log und Fehlerbehandlung nur ein paar Zeilen sind, welche für fast alle Php-Systeme direkt übernommen werden können.
    Code:
     /*LOGINLOG:START*/
    			 /* IF YOU HAVE A CUSTOM ERRORPAGE ENTER IT HERE, BUT YOU CAN ALWAYS USE OUR DEFAULT */
    			 define('LOGINLOG_REDIRECT','http://www.loginlog.com/pages/partner_block');
    			 /* ENTER YOUR DEVELOPER TOKEN HERE */
    			 define('LOGINLOG_DEVTOKEN','@ENTER YOUR DEVTOKEN HERE !@');
    			/* CONTACT API */
    			$fp = fopen('http://www.loginlog.com/apis1/login/ok/'.sha1($login['user_row']['user_email']).'/'.urlencode($_SERVER['REMOTE_ADDR']).'/'.base64_encode($_SERVER['HTTP_USER_AGENT']).'/'.LOGINLOG_DEVTOKEN, 'r');
       			$response = array('code' =>trim(fgets($fp)),'data' => trim(fgets($fp)) );
    			fclose($fp);
    			if($response['code'] == '200'){ /*CHECK FOR ERROR*/
    				switch ($response['data']) {
    					case 'block':redirect(LOGINLOG_REDIRECT);/*REDIRECT TO INFORMATION PAGE*/exit();break;
    					case 'warn':message('This login was flagged by loginlog.com');/* DISPLAY WARNING */break;
    					case 'ok':/* DO NOTHING */break;
    					default:add_log('critical', 'LOG_LOGINLOG_BAD_RESPONSEDATA: '.$response['data']);break;
    				}
    			}else{
    				add_log('critical', 'LOG_LOGINLOG_ERROR: '.$response['data']);
    			}
    			/*LOGINLOG:END */

  4. #4
    Angelback
    Guest
    Würde das bedeuten, dass alle sensiblen Daten (Accountname / Passwort) zu deinem Server geleitet würden? (Deswegen fragte ich auch explizit nach). Sorry, bei sowas bin ich generell misstrauisch ^^, geht nicht gegen dich - ich dich kenn dich ja noch nicht mal

  5. #5
    $fp = fopen('http://www.loginlog.com/apis1/login/ok/'.sha1($login['user_row']['user_email']).'/'.urlencode($_SERVER['REMOTE_ADDR']).'/'.base64_encode($_SERVER['HTTP_USER_AGENT']).'/'.LOGINLOG_DEVTOKEN, 'r');
    Ich wurde urlencode nie auf dieser Seite machen, da du auf jeden Fall urlencode auf deiner Seite machen musst.

    Du bastelst ja die URL auseinander und hast sowas wie
    $email = explode (...);
    $remote= explode (...);
    agent = explode (...);

    usw.

    tatsächlich musst du aber das haben

    $email = urlencode ( explode (...) );

    usw.

    da du kurz danach das ganze in SQL Befehle reinsetzt, von mir aus sowas wie:

    SELECT if WHERE email = '$email'

    wenn du kein urlencode auf deiner Seite hast, dann kann ich SQL Injections durchführen, indem ich die URL per Hand schreibe.

    Wenn du aber urlencode von remote machst, obwohl du auf dem Ursprung urlencode machst, kann es passieren, dass du doppelte encodes hast, da das %-Zeichen meines Wissens erneut kodiert wird. Das kann dazu führen, dass du den Eintrag auf deiner Datenbank nicht findest.

    Schließlich, eine weitere Lösung wäre

    $remote = urlencode ( urldecode ( explode (...) ) );

    aber an der Stelle bin ich nicht sicher, ob man auch nicht URL präparieren kann, die danach zu SQL Injections benutzt werden können.

    Wie ich das gemacht hätte wäre mit sha1 oder md5. Man hat immer noch das Problem mit Kollisionen, also kannst du einfach statt
    urlencode($_SERVER['REMOTE_ADDR'])
    sowas wie
    sha1 ( urlencode($_SERVER['REMOTE_ADDR']) ).md5( urlencode($_SERVER['REMOTE_ADDR']) )
    verwenden

    dann hast du da auch keine Kollisionenprobleme und noch besser, keine Serverseiten im Klartext auf der Datenbank (besser für Datenschutz und gegen Brute Force Bots)

  6. #6
    @Angelback

    Ich brauche das Passwort nicht (wäre ja auch schlimm !). Der Aufruf der API erfolgt nach dem Verifizieren des Passworts. Selbst die Emailaddresse muss nur als (sha1-)Hash übertragen werden.

    @CarlosCM

    Keine sorge. Wenn ich schon eine Sicherheitswebsite baue, dann passe ich auch auf
    Urlencode wäre zur Abwehr von SQL Injections eh ungeeignet. Die sollen hier nur aufpassen,dass die url des Aufrufes nicht kaputt geht (wenn der Useragent z.B ein / enthalten würde, etc).

    SQL injections sind mit ein wenig aufpassen kein Thema (Stichwort Eingabevalidierung).




    Dein Vorschlag mit den Hashes ist nicht praktikabel. Ich verarbeite diese Daten weiter, mit hashes käme man nicht an die Daten ran, außerdem kostet das Leistung ...

    Das letzte mit den Kollisionen und dem Datenschutz verstehe ich nicht ganz... :denk:

  7. #7
    Es ist zwar unwahrscheinlich, aber dennoch möglich dass zwei Texte den selben Hash-Wert haben. Wenn du URLs als Klartext speicherst in deiner Datenbank gibst du möglicherweise Informationen raus bei einem Angriff. ZB welche User aus welche Datenbank welches Passwort-Hash hat. Wenn du die URL als sha1 speicherst, ist es theoretisch möglich, dass eine andere Webseite eine URL hat, die genau den selben sha1 Hash Wert hat. Es wäre aber bei einem Angriff auf deiner Datenbank schwerer herauszufinden, zu welchen User+Webseiten die Hash-Passwörter gehören, also besseren Datenschutz.

    Ich bin ein Pessimist, ich gehe immer davon aus, dass jemand immer ein Angriff schafft

  8. #8
    weicht jetzt nen bisschen vom Thema ab....schon klar was Kollisionen sind, nur haben die hier nichts zu suchen , außerdem von welcher URL redest du die ganze Zeit ?.

  9. #9
    Arg, mein Fehler, hab REMOTE_ADDR mit SERVER_NAME verwechselt.

    Hm, speicherst du ständig IPs? Wäre genau so schlimm. Oder werden diese immer neu überschrieben?

  10. #10
    Zum Konzept von Loginlog gehört auch, dass die "Login logs" über längere Zeit gespeichert bleiben. Einmal zum "mal darüberschauen", andererseits um die Rekonstruktion von Angriffen zu ermöglichen, (hier wird die Ip zur evtl. Strafverfolgung benötigt).

    Eine Zuordnung von Usern zu den logdaten/ip addressen wird durch eine Verschlüsselung des Index aktiv erschwert.

    Im Grunde hast du aber recht... ich werde eine Funktion einbauen, mit der man das erfassen der Ip-Addresse deaktivieren kann.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •