» Neues Login-Cookie im Test / mehr Sicherheit für Passwörter

mgutt · 21.08.2009, 20:04

Neues Autologin-Cookie:
Bisher setzen wir ein ziemlich umfangreiches System beim Autologin-Cookie ein. Hierbei wurde aus Sicherheitsgründen das Cookie ständig bei jedem neuen Seitenaufruf mit einer zufälligen ID überschrieben. Dummerweise macht das nicht jeder Browser mit und das führt zu den nervigsten Fehlern wie z.B.:

Cookies werden doppelt abgespeichert, statt überschrieben und das alte wird uns zurückgesendet, so dass der Login fehlschlägt (häufig in Firefox 3)
das Cookie kann von unserem System nicht mehr entfernt werden, wenn es keine gültige Autologin-ID besitzt (fast immer in Opera 9, selten in Firefox 3)
Cookies müssen manuell entfernt werden, damit man sich überhaupt noch anmelden kann (diverse Browser)

Nun schmeißen wir alles hin und machen was ganz neues bzw. Altbewährtes. Wir speichern einen Schlüssel im Cookie, der sich direkt aus dem Passwort und diversen geheimen Parametern ergibt. Diese Technik wird schon seit ewigen Zeiten eingesetzt und sie ist nahezu fehlerfrei. Die bekannte Forensoftware vBulletin setzt eine ähnliche Technik ein.

Aktuell wird das neue Cookie von mir getestet und ich feile noch an einer höheren Sicherheit. Das alte war sehr sicher, weil es sich bei jedem Seitenaufruf änderte. Das neue dagegen wäre theoretisch unendlich lange gültig. Es ist also zu klären, wie lange ein Autologin-Cookie nun gültig sein sollte. z.B. 1 Jahr, 30 Tage oder in Abhängigkeit zur Browser-Version, dem Provider, etc.

Ein klarer Vorteil vom neuen Cookie wäre allerdings eine bessere Performance, weil wir nicht bei jedem Seitenaufruf den Schlüssel in unserer Datenbank aktualisieren müssten.

Mehr Sicherheit bei Passwörtern:
Grundsätzlich speichern wir keine Passwörter. Wir speichern nur einen so genannten MD5-Hash, eine Art Quersumme, die sich aus dem Passwort ergibt. Der Vorteil dieses Hashs ist, dass man ihn nicht zurück in ein Passwort wandeln kann. Zumindest war das der Stand bis vor ein paar Jahren.

Heute gibt es verschiedene Techniken, wie man doch auf das Passwort Rückschlüsse ziehen kann. Entweder in dem der Hacker jede mögliche Variante durchprobiert (1, 2, 3, ... 12aa, 12ab, usw.) oder in dem er sich beliebten Passwörter aus Datenbanken bedient wie z.B. Wörterbüchern und jeweils selber große Datenbank mit Hashes anlegt und diese dann simpel mit der gestohlenen Hashes vergleicht. Mittlerweile gibt es drei bekannte Wege, über die man MD5 Hashes "knacken" kann:
http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5#Sicherheits.C3.BCberlegungen

Daher haben wir uns entschieden so genannte Salts einzusetzen. Ein Salt ist ein zusätzlicher Text, der zusammen mit dem Passwort den neuen Hash bildet. Also z.B. ist das Passwort "123456" und wir fügen intern noch "nweoifn329fnweflifhn" hinzu, so dass sich ein Gesamtpasswort ergibt:
123456nweoifn329fnweflifhn

Dieses neue Passwort wird dann wie gehabt per MD5 zu einem Hash.

Da jeder User einen eigenen zufälligen Salt zugewiesen bekommt, ergeben sich daraus zwei Vorteile:

1.) Der Hacker weiß nicht auf welche Art das neue Passwort aufgebaut wird. z.B.:
123456nweoifn329fnweflifhn (erst Passwort dann Salt)
nweoifn329fnweflifhn123456 (erst Salt dann Passwort)
123456nweoifn329 (nur Teile vom Salt werden verwendet)
usw.

Wir setzen eine geheime Variante ein, die der Hacker nur erfahren würde, wenn er neben der Datenbank auch unseren FTP-Zugriff hackt. Das nennt man auch "Security through Obscurity":
http://de.wikipedia.org/wiki/Security_through_obscurity

2.) Ist jeder Hash in der Datenbank anders. Bisher konnte es sein, dass zwei oder mehr User das gleiche Passwort hatten und dementsprechend der gleiche Hash in der Datenbank stand.

Hier weiterführende Erklärungen zu einem Salt und seine Vorteile:
http://de.wikipedia.org/wiki/Salted_Hash#Resultierende_Vorteile
http://de.wikipedia.org/wiki/Salt_(Kryptologie)

Umsetzung:
Aktuell läuft wie gesagt ein erster Test und ich verfeinere noch das Autologin-Cookie. Danach werde ich beides gleichzeitig umsetzen, weil sich mit dem neuen Cookie jeder neu einloggen muss und wir dann erst auch den Hash in der Datenbank aktualisieren können.

Ich kündige das dann noch mal an, damit jeder bescheid weiß, wenn er plötzlich ausgeloggt ist

Woll-E · 22.08.2009, 18:28

Hatte keine Probleme mit dem LogIn

Find ich eine gute Idee, dass nun mit Saltwerten gearbeitet wird. Erinnert mich an ein Linuxdilemma, als plötzlich der Saltwert nicht mehr stimmte und alles für'n ***** war...

Schonmal ein Backup getestet? nicht das es hier das gleiche ist und bei einem Backup ist alles hinfällig (wobei man dann ja nur auf Passwort vergessen gehen müsste).

PS:
D1D2D3D4D5D6D7D8D9D10 ? Was heißt das?

steht unterm Template bei mir

Grüße

mgutt · 23.08.2009, 09:24

WolFreeSchonmal ein Backup getestet? nicht das es hier das gleiche ist und bei einem Backup ist alles hinfällig (wobei man dann ja nur auf Passwort vergessen gehen müsste).

Grundsätzlich sind die Werte alle ungültig, ab dem Tag, wo das neue Login-System online geht. Backups können dann nicht mehr funktionieren bzw. das Login-System müsste noch mal von vorne gestartet werden. Aber das gilt ja "nur" für die Passwörter.

Damit aber der Übergang und Backups funktionieren, werde ich alle ausloggen lassen und dann beim erfolgreichen Login die Datensätze in der Datenbank mit den neuen Werten überschreiben. D.h. zum Zeitpunkt des Logins kann ich noch das Passwort auf die alte Art vergleichen. Danach dann nur noch mit der neuen. Daher werde ich übergangsweise beide Varianten erlauben müssen. Das macht es sogar noch sicherer, weil man gar nicht mehr weiß ob der Hash nun mit oder ohne Salt erstellt wurde. :hrhr:

ZitatD1D2D3D4D5D6D7D8D9D10 ? Was heißt das? steht unterm Template bei mir

Ja da werden bei mir Testparameter ausgegeben. Muss das mal von meinem Login abhängig machen :hrhr:

Ich habe übrigens noch eine Idee für ein sicherers Login-Formular. Das werde ich aber nur optional anbieten. Und zwar damit ein Keylogger z.B. von einem Trojaner das Passwort nicht mitschreiben kann, werde ich es so machen, dass bei der Eingabe die letzten x Stellen über ein Dropdown ausgewählt werden müssen. Dann helfen nur noch Screenreader, aber da hoffe ich einfach, dass der nicht genug Bilder pro Sekunde überträgt, da nach Auswahl des Buchstabens sofort ein "*" erscheinen wird.

Woll-E · 23.08.2009, 09:56

Die letzte Idee finde ich nett

Obwohl ich nicht finde, dass es unbedingt an dir liegt, in Sachen Screenreader und Keylogger mehr Sicherheit auf die Seite zu bringen

Wer sein System nicht sauber hat, ist selber schuld.

mgutt · 23.08.2009, 10:30

Ich denke nicht, dass Du dem 08/15 Nutzer so viel abverlangen kannst. Der macht so lange weiter, bis er merkt, dass seine Internetverbindung nicht mehr schnell genug ist. Und dann besteht immer noch das Risiko, dass er einfach von DSL3000 auf DSL16000 wechselt

Woll-E · 23.08.2009, 19:26

Versuch einen Hash in Verbindung mit dem Ort der Verbindung (ist meist der letzte Knoten) und dem Betriebssystem.

mgutt · 23.08.2009, 21:34

Das Betriebssystem steht im HTTP_USER_AGENT. Dieser ist fälschbar. D.h. ein Cookie-Dieb könnte zusätzlich auch den Agent klauen und bei einem Test mitsenden, schon wäre das System ausgehebelt. Daher ist die Prüfung auf den Browser oder dessen Version auch wenig sinnvoll, da die auch im Agent übertragen werden.

Die Sache mit dem Ort finde ich gut. Aber woher den Ort nehmen? Ich hab mal vor längerer Zeit nach einer Datenbank dazu gesucht, aber nur kostenpflichtige Seiten gefunden und deren Angaben waren teilweise sogar falsch.

Woll-E · 23.08.2009, 21:51

Ja, die Angaben sind in sofern falsch, dass sie sich auf einen knoten festlegen könnten - beispielsweise kenn ich einen Fall, der mit ner arcorIP in schweden (laut geotracking) sitzt - wohnt aber mehr oder weniger nebenan.

Den Ort kannst du dir über, wie erwähnt, geotracking ziehen. Ist soweit ich weiß auch gratis und für solche sachen verwendbar.

Du vergisst außerdem, dass das Betriebssystem nicht klartextmäßig drinsteht. Multiplizier doch bspw. den HEX Wert des Betriebssystems mit dem Saltwert, schon haste etwas individuelles ohne das jemand es nachvollziehen kann, selbst WENN er weiß, dass da das Betriebssystem drinsteckt

mgutt · 23.08.2009, 22:47

ZitatJa, die Angaben sind in sofern falsch, dass sie sich auf einen knoten festlegen könnten - beispielsweise kenn ich einen Fall, der mit ner arcorIP in schweden (laut geotracking) sitzt - wohnt aber mehr oder weniger nebenan.

Den Ort kannst du dir über, wie erwähnt, geotracking ziehen. Ist soweit ich weiß auch gratis und für solche sachen verwendbar.

Ich denke, dass das mit dem Standort nichts wird. Da reicht es ja schon, dass ein Anbieter wie Arcor z.B. 10 IPs in Knotenpunkten besitzt und die Kunden je nach Auslastung "springen". Es bleibt ja immer noch dem Anbieter überlassen, welchen Knoten er nutzt. Gerade bei Lastspitzen gilt dann nicht mehr die Regel, dass der Knoten in der Nähe sein muss. Mir ist da nämlich ein Beispiel eingefallen, da war ein User zwischen zwei Knoten und wechselte ständig den Knoten. Ich vermute da auch ein Loadbalancer oder sowas.

Auch glaube ich nicht, dass man diese Geodaten überhaupt kostenlos bekommt. Ich weiß nicht mal, wie diese überhaupt ermittelt werden.

ZitatDu vergisst außerdem, dass das Betriebssystem nicht klartextmäßig drinsteht. Multiplizier doch bspw. den HEX Wert des Betriebssystems mit dem Saltwert, schon haste etwas individuelles ohne das jemand es nachvollziehen kann, selbst WENN er weiß, dass da das Betriebssystem drinsteckt

Das ist egal, weil ich bei der Verifizierung des Hashs diesen ja erneut nachbilden muss. Und das mache ich wieder mit Passwort, Salt und dem Betriebssystem, dass ich aus dem angelieferten User-Agent extrahiert habe.

Wenn ein Cookie-Dieb also zusätzlich den User-Agent stiehlt und mir zusendet (lässt sich z.B. in Firefox simpel mit einem Plugin ändern), kann ich ihn nicht vom Bestohlenen unterscheiden.

maxrev.de · Gast

Mach mit!

Wenn Dir die Beiträge zum Thread "Neues Login-Cookie im Test / mehr Sicherheit für Passwörter" gefallen haben oder Du noch Fragen hast oder Ergänzungen machen möchtest, solltest Du Dich gleich bei uns anmelden:

Registrierte Mitglieder genießen die folgenden Vorteile:
✔ kostenlose Mitgliedschaft
✔ keine Werbung
✔ direkter Austausch mit Gleichgesinnten
✔ neue Fragen stellen oder Diskussionen starten
✔ schnelle Hilfe bei Problemen
✔ Bilder und Videos hochladen
✔ und vieles mehr...

Autor	Nachricht
mgutt Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 52420 Wohnort: Lohmar Meine eBay-Auktionen:	21.08.2009, 20:04 zitieren Neues Autologin-Cookie: Bisher setzen wir ein ziemlich umfangreiches System beim Autologin-Cookie ein. Hierbei wurde aus Sicherheitsgründen das Cookie ständig bei jedem neuen Seitenaufruf mit einer zufälligen ID überschrieben. Dummerweise macht das nicht jeder Browser mit und das führt zu den nervigsten Fehlern wie z.B.: Cookies werden doppelt abgespeichert, statt überschrieben und das alte wird uns zurückgesendet, so dass der Login fehlschlägt (häufig in Firefox 3) das Cookie kann von unserem System nicht mehr entfernt werden, wenn es keine gültige Autologin-ID besitzt (fast immer in Opera 9, selten in Firefox 3) Cookies müssen manuell entfernt werden, damit man sich überhaupt noch anmelden kann (diverse Browser) Nun schmeißen wir alles hin und machen was ganz neues bzw. Altbewährtes. Wir speichern einen Schlüssel im Cookie, der sich direkt aus dem Passwort und diversen geheimen Parametern ergibt. Diese Technik wird schon seit ewigen Zeiten eingesetzt und sie ist nahezu fehlerfrei. Die bekannte Forensoftware vBulletin setzt eine ähnliche Technik ein. Aktuell wird das neue Cookie von mir getestet und ich feile noch an einer höheren Sicherheit. Das alte war sehr sicher, weil es sich bei jedem Seitenaufruf änderte. Das neue dagegen wäre theoretisch unendlich lange gültig. Es ist also zu klären, wie lange ein Autologin-Cookie nun gültig sein sollte. z.B. 1 Jahr, 30 Tage oder in Abhängigkeit zur Browser-Version, dem Provider, etc. Ein klarer Vorteil vom neuen Cookie wäre allerdings eine bessere Performance, weil wir nicht bei jedem Seitenaufruf den Schlüssel in unserer Datenbank aktualisieren müssten. Mehr Sicherheit bei Passwörtern: Grundsätzlich speichern wir keine Passwörter. Wir speichern nur einen so genannten MD5-Hash, eine Art Quersumme, die sich aus dem Passwort ergibt. Der Vorteil dieses Hashs ist, dass man ihn nicht zurück in ein Passwort wandeln kann. Zumindest war das der Stand bis vor ein paar Jahren. Heute gibt es verschiedene Techniken, wie man doch auf das Passwort Rückschlüsse ziehen kann. Entweder in dem der Hacker jede mögliche Variante durchprobiert (1, 2, 3, ... 12aa, 12ab, usw.) oder in dem er sich beliebten Passwörter aus Datenbanken bedient wie z.B. Wörterbüchern und jeweils selber große Datenbank mit Hashes anlegt und diese dann simpel mit der gestohlenen Hashes vergleicht. Mittlerweile gibt es drei bekannte Wege, über die man MD5 Hashes "knacken" kann: http://de.wikipedia.org/wiki/Message-Digest_Algorithm_5#Sicherheits.C3.BCberlegungen Daher haben wir uns entschieden so genannte Salts einzusetzen. Ein Salt ist ein zusätzlicher Text, der zusammen mit dem Passwort den neuen Hash bildet. Also z.B. ist das Passwort "123456" und wir fügen intern noch "nweoifn329fnweflifhn" hinzu, so dass sich ein Gesamtpasswort ergibt: 123456nweoifn329fnweflifhn Dieses neue Passwort wird dann wie gehabt per MD5 zu einem Hash. Da jeder User einen eigenen zufälligen Salt zugewiesen bekommt, ergeben sich daraus zwei Vorteile: 1.) Der Hacker weiß nicht auf welche Art das neue Passwort aufgebaut wird. z.B.: 123456nweoifn329fnweflifhn (erst Passwort dann Salt) nweoifn329fnweflifhn123456 (erst Salt dann Passwort) 123456nweoifn329 (nur Teile vom Salt werden verwendet) usw. Wir setzen eine geheime Variante ein, die der Hacker nur erfahren würde, wenn er neben der Datenbank auch unseren FTP-Zugriff hackt. Das nennt man auch "Security through Obscurity": http://de.wikipedia.org/wiki/Security_through_obscurity 2.) Ist jeder Hash in der Datenbank anders. Bisher konnte es sein, dass zwei oder mehr User das gleiche Passwort hatten und dementsprechend der gleiche Hash in der Datenbank stand. Hier weiterführende Erklärungen zu einem Salt und seine Vorteile: http://de.wikipedia.org/wiki/Salted_Hash#Resultierende_Vorteile http://de.wikipedia.org/wiki/Salt_(Kryptologie) Umsetzung: Aktuell läuft wie gesagt ein erster Test und ich verfeinere noch das Autologin-Cookie. Danach werde ich beides gleichzeitig umsetzen, weil sich mit dem neuen Cookie jeder neu einloggen muss und wir dann erst auch den Hash in der Datenbank aktualisieren können. Ich kündige das dann noch mal an, damit jeder bescheid weiß, wenn er plötzlich ausgeloggt ist Gefällt mir Teilen twittern
▲	pn email

Woll-E Premium-Member Name: Woll-E Geschlecht: Fahrzeug: EH6 Anmeldedatum: 03.05.2009 Beiträge: 21228 Wohnort: Köln	22.08.2009, 18:28 zitieren Hatte keine Probleme mit dem LogIn Find ich eine gute Idee, dass nun mit Saltwerten gearbeitet wird. Erinnert mich an ein Linuxdilemma, als plötzlich der Saltwert nicht mehr stimmte und alles für'n ***** war... Schonmal ein Backup getestet? nicht das es hier das gleiche ist und bei einem Backup ist alles hinfällig (wobei man dann ja nur auf Passwort vergessen gehen müsste). PS: D1D2D3D4D5D6D7D8D9D10 ? Was heißt das? steht unterm Template bei mir Grüße
▲	pn

mgutt Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 52420 Wohnort: Lohmar Meine eBay-Auktionen:	23.08.2009, 09:24 zitieren WolFreeSchonmal ein Backup getestet? nicht das es hier das gleiche ist und bei einem Backup ist alles hinfällig (wobei man dann ja nur auf Passwort vergessen gehen müsste). Grundsätzlich sind die Werte alle ungültig, ab dem Tag, wo das neue Login-System online geht. Backups können dann nicht mehr funktionieren bzw. das Login-System müsste noch mal von vorne gestartet werden. Aber das gilt ja "nur" für die Passwörter. Damit aber der Übergang und Backups funktionieren, werde ich alle ausloggen lassen und dann beim erfolgreichen Login die Datensätze in der Datenbank mit den neuen Werten überschreiben. D.h. zum Zeitpunkt des Logins kann ich noch das Passwort auf die alte Art vergleichen. Danach dann nur noch mit der neuen. Daher werde ich übergangsweise beide Varianten erlauben müssen. Das macht es sogar noch sicherer, weil man gar nicht mehr weiß ob der Hash nun mit oder ohne Salt erstellt wurde. ZitatD1D2D3D4D5D6D7D8D9D10 ? Was heißt das? steht unterm Template bei mir Ja da werden bei mir Testparameter ausgegeben. Muss das mal von meinem Login abhängig machen Ich habe übrigens noch eine Idee für ein sicherers Login-Formular. Das werde ich aber nur optional anbieten. Und zwar damit ein Keylogger z.B. von einem Trojaner das Passwort nicht mitschreiben kann, werde ich es so machen, dass bei der Eingabe die letzten x Stellen über ein Dropdown ausgewählt werden müssen. Dann helfen nur noch Screenreader, aber da hoffe ich einfach, dass der nicht genug Bilder pro Sekunde überträgt, da nach Auswahl des Buchstabens sofort ein "*" erscheinen wird.
▲	pn email

Woll-E Premium-Member Name: Woll-E Geschlecht: Fahrzeug: EH6 Anmeldedatum: 03.05.2009 Beiträge: 21228 Wohnort: Köln	23.08.2009, 09:56 zitieren Die letzte Idee finde ich nett Obwohl ich nicht finde, dass es unbedingt an dir liegt, in Sachen Screenreader und Keylogger mehr Sicherheit auf die Seite zu bringen Wer sein System nicht sauber hat, ist selber schuld.
▲	pn

mgutt Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 52420 Wohnort: Lohmar Meine eBay-Auktionen:	23.08.2009, 10:30 zitieren Ich denke nicht, dass Du dem 08/15 Nutzer so viel abverlangen kannst. Der macht so lange weiter, bis er merkt, dass seine Internetverbindung nicht mehr schnell genug ist. Und dann besteht immer noch das Risiko, dass er einfach von DSL3000 auf DSL16000 wechselt Verfasst am: 23.08.2009, 10:41 zitieren Also der neue Auto-Login scheint zu funktionieren. Seit ein paar Tagen kann ich regelmäßig rein, ohne mich neu einloggen zu müssen. Nun muss ich mir ein Sicherheitsplus einfallen lassen, falls jemand Cookies stiehlt. Aktuell verfolge ich zwei Konzepte: Diverse Angaben des Besuchers mit in den Hash einarbeiten, wie z.B. Browsername, Browserversion, Provider, etc. Das Cookie wird in einem bestimmten Intervall erneuert. Damit das Problem von früher nicht entsteht (Cookie kann nicht gelöscht werden) und die Performance trotzdem gut bleibt, dachte ich daran, dass ich für jede Kalenderwoche ein eigenes Cookie hinterlege. Also: Zitatautologinhash_kw1 => '29832498234234' autologinhash_kw2 => '23423423423423' Natürlich gilt das Cookie dann auch nur in dem Jahr, wo es erstellt wurde, so dass ein kw1 Cookie aus 2009 nicht mehr in 2010 funktioniert. Damit wäre das Cookie .... ... ne funktioniert gar nicht. Schade. Das Problem ist ja, dass jemand in kw1 eingeloggt gewesen sein könnte und in kw20 (wenn er zwischenzeitlich nicht mehr auf der seite war) wäre er ja ausgeloggt, wenn das kw1 nicht mehr akzeptiert wird. Erlaube ich auch das kw1 Cookie habe ich aber kein Sicherheitsplus. mal weiter nachdenken
▲	pn email

Woll-E Premium-Member Name: Woll-E Geschlecht: Fahrzeug: EH6 Anmeldedatum: 03.05.2009 Beiträge: 21228 Wohnort: Köln	23.08.2009, 19:26 zitieren Versuch einen Hash in Verbindung mit dem Ort der Verbindung (ist meist der letzte Knoten) und dem Betriebssystem.
▲	pn

mgutt Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 52420 Wohnort: Lohmar Meine eBay-Auktionen:	23.08.2009, 21:34 zitieren Das Betriebssystem steht im HTTP_USER_AGENT. Dieser ist fälschbar. D.h. ein Cookie-Dieb könnte zusätzlich auch den Agent klauen und bei einem Test mitsenden, schon wäre das System ausgehebelt. Daher ist die Prüfung auf den Browser oder dessen Version auch wenig sinnvoll, da die auch im Agent übertragen werden. Die Sache mit dem Ort finde ich gut. Aber woher den Ort nehmen? Ich hab mal vor längerer Zeit nach einer Datenbank dazu gesucht, aber nur kostenpflichtige Seiten gefunden und deren Angaben waren teilweise sogar falsch.
▲	pn email

Woll-E Premium-Member Name: Woll-E Geschlecht: Fahrzeug: EH6 Anmeldedatum: 03.05.2009 Beiträge: 21228 Wohnort: Köln	23.08.2009, 21:51 zitieren Ja, die Angaben sind in sofern falsch, dass sie sich auf einen knoten festlegen könnten - beispielsweise kenn ich einen Fall, der mit ner arcorIP in schweden (laut geotracking) sitzt - wohnt aber mehr oder weniger nebenan. Den Ort kannst du dir über, wie erwähnt, geotracking ziehen. Ist soweit ich weiß auch gratis und für solche sachen verwendbar. Du vergisst außerdem, dass das Betriebssystem nicht klartextmäßig drinsteht. Multiplizier doch bspw. den HEX Wert des Betriebssystems mit dem Saltwert, schon haste etwas individuelles ohne das jemand es nachvollziehen kann, selbst WENN er weiß, dass da das Betriebssystem drinsteckt
▲	pn

mgutt Administrator Name: Marc Geschlecht: Anmeldedatum: 28.08.2004 Beiträge: 52420 Wohnort: Lohmar Meine eBay-Auktionen:	23.08.2009, 22:47 zitieren ZitatJa, die Angaben sind in sofern falsch, dass sie sich auf einen knoten festlegen könnten - beispielsweise kenn ich einen Fall, der mit ner arcorIP in schweden (laut geotracking) sitzt - wohnt aber mehr oder weniger nebenan. Den Ort kannst du dir über, wie erwähnt, geotracking ziehen. Ist soweit ich weiß auch gratis und für solche sachen verwendbar. Ich denke, dass das mit dem Standort nichts wird. Da reicht es ja schon, dass ein Anbieter wie Arcor z.B. 10 IPs in Knotenpunkten besitzt und die Kunden je nach Auslastung "springen". Es bleibt ja immer noch dem Anbieter überlassen, welchen Knoten er nutzt. Gerade bei Lastspitzen gilt dann nicht mehr die Regel, dass der Knoten in der Nähe sein muss. Mir ist da nämlich ein Beispiel eingefallen, da war ein User zwischen zwei Knoten und wechselte ständig den Knoten. Ich vermute da auch ein Loadbalancer oder sowas. Auch glaube ich nicht, dass man diese Geodaten überhaupt kostenlos bekommt. Ich weiß nicht mal, wie diese überhaupt ermittelt werden. ZitatDu vergisst außerdem, dass das Betriebssystem nicht klartextmäßig drinsteht. Multiplizier doch bspw. den HEX Wert des Betriebssystems mit dem Saltwert, schon haste etwas individuelles ohne das jemand es nachvollziehen kann, selbst WENN er weiß, dass da das Betriebssystem drinsteckt Das ist egal, weil ich bei der Verifizierung des Hashs diesen ja erneut nachbilden muss. Und das mache ich wieder mit Passwort, Salt und dem Betriebssystem, dass ich aus dem angelieferten User-Agent extrahiert habe. Wenn ein Cookie-Dieb also zusätzlich den User-Agent stiehlt und mir zusendet (lässt sich z.B. in Firefox simpel mit einem Plugin ändern), kann ich ihn nicht vom Bestohlenen unterscheiden.
▲	pn email

maxrev.de Gast	25.09.2009, 15:34 zitieren Mach mit! Wenn Dir die Beiträge zum Thread "Neues Login-Cookie im Test / mehr Sicherheit für Passwörter" gefallen haben oder Du noch Fragen hast oder Ergänzungen machen möchtest, solltest Du Dich gleich bei uns anmelden: Registrierte Mitglieder genießen die folgenden Vorteile: ✔ kostenlose Mitgliedschaft ✔ keine Werbung ✔ direkter Austausch mit Gleichgesinnten ✔ neue Fragen stellen oder Diskussionen starten ✔ schnelle Hilfe bei Problemen ✔ Bilder und Videos hochladen ✔ und vieles mehr...
▲

	Re: √	Letzter Beitrag
Yubikey bestellt: Mehr Login-Komfort und erhöhte Sicherheit Hi, wir haben von der Firma Yubico den Yubikey bestellt und werden den mal testen. Der ist im Grunde wie ein TAN-Generator, allerdings nicht so unbequem. D.h. man muss nichts von Hand abschreiben. Das Funktionsprinzip: - Yubikey muss an einen... [Ankündigungen]von mgutt	5 1.609	17.10.2011, 10:42 mgutt
Neue Technik: Mehr Leistung und Sicherheit Doch die Modifikationen beschränken sich nicht nur auf optische Maßnahmen: Auch unter dem Blech finden sich zahlreiche Verbesserungen: Ein neu entwickelter 1,4-Liter-Benziner löst das 1,3-Liter-Aggregat ab, und als Selbstzünder steht nun ein... von mgutt	0 535	21.10.2007, 18:58 mgutt
Honda Integra DC2 Sartet nicht mehr nach Kompressions Test Hilfe Hallo Leute haben heute Nacht Kompressions Test bei unserem DC2 gemacht. Jetzt ist das Problem wollte ihn vorhin mal bewegen jetzt Startet er aber nicht mehr. Ich hab kein Zündfunken woran liegt das bitte um... [Elektronik]von PMS-RACING-DESIGN-EG4	4 336	30.03.2014, 22:04 PMS-RACING-DESIGN-EG4
Cookie-Free Domain ist Unsinn Hallo, zahlreiche Dokus empfehlen s.g. cookie-free Domains. Hier ein Auszug aus der YSlow Empfehlung: Use Cookie-free Domains for Components tag: cookie When the browser makes a request for a static image and sends cookies together with the... von mgutt	0 2.027	23.10.2010, 12:22 mgutt
Cookie wird bei FF3 und IE doppelt gesetzt Ich kann mir das aktuell nicht erklären, aber manchmal können sich die Nutzer nicht einloggen, weil bereits ein Cookie vorhanden ist. Ein Mitglied habe ich dann um einen Screenshot gebeten und der zeigte das: Es ist also so, dass ein Cookie zwei... von mgutt	1 588	05.01.2009, 23:56 mgutt
neues lenkrad verbaut 4WS funkz net mehr hallooo ich habe heute nachmittag ein sportlenkrad verbaut, und siehe jetzt, mein 4WS funktioniert nichg mehr,meine frage ist, kann man das irgendwie wieder anschliessen?? oder kann man das 4WS ausbauen... [Prelude]von Laba	0 117	14.01.2013, 16:43 Laba
Neues radio, kein ton mehr,Hilfe! Hallo, hab einen corsa bekommen (bj1996) oder so aufjeden fall hatte ich vorher auch einen corsa b (bj1998) wo mein pioner radio drinne ist, hat alles einbahn frei geklappt, nun habe ich es in meinem neuen corsa eingebaut, geht auch an aund alles nur es... von Mavaem	3 5.348	18.05.2009, 10:33 mgutt
Das Web wird kompliziert (in der EU), dank Cookie Gesetz/Richtlinie Die EU möchte die Internetnutzer schützen: Im November 2009 haben das Europäische Parlament und der Rat die Richtlinie 2009/136/EG angenommen. Mit dieser Richtlinie wurde die Datenschutzrichtlinie für elektronische Kommunikation (2002/58/EG) aus... [Computer & Spiele]von mgutt	1 268	10.06.2012, 18:29 mgutt
hab n neues auto leider keinen honda mehr aber seht selbst da ich ja vorher n eg3 hatte und ich mich entschloss ihn zu verkaufen habe ich mir jetzt einen Mitsubishi Eclipse D30 zugelegt ;) könnt mir ja mal n paar tipps geben was ihr als erstes machen würdet tiefer oder doch erst n paar... [Auto]von EG3 RACER	7 614	03.03.2008, 17:51 EG3 RACER
Sicherheit im Sol Hi, hab hier eben ein Vid bei Youtube gesehn in dem es umd die Sicherheit des Del Sol geht. Da wird in der SiR Version gezeigt das er ein [URL=http://www.hondaoldies.de/Korbmacher-Archiv/Technik/tcs.htm]TCS - Traction Control System[/URL] hat . Gab... [Del Sol]von Caliban13	5 340	23.12.2009, 09:56 Wick3d