»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

WolFree · 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

WolFree schrieb:

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).

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:

Zitat:

D1D2D3D4D5D6D7D8D9D10 ? 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.

WolFree · 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

WolFree · 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.

WolFree · 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

Zitat:

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.

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.

Zitat:

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

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 Thema "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:

» 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:	Hits	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	271	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	357	21.10.2007, 18:58 mgutt
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	427	23.10.2010, 12:22 mgutt
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	1088	18.05.2009, 10:33 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	294	05.01.2009, 23:56 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	434	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	242	23.12.2009, 09:56 Wick3d
icq login hmm leud ich komm in mein icq net mehr rein?!?!?! kann mir mal jemand sagen woran das... Seite 2, 3, 4 [Allgemein]von dbmaster	30	918	02.02.2006, 21:04 dbmaster
Zweifaches Login? Hallo zusammen! Ich habe jetzt mein Wiki auf etwas umständlichen aber doch notwenigen Weg upgedatet. Und zwar bin ich von einem Fedora 8 auf Centos 5.5 umgestiegen. Natürlich wollte ich all meine Daten und Skins usw. mitnehmen. Deshalb bin ich wie... von blacknanok	1	59	22.10.2010, 11:35 rakekniven
Sicherheit & Rendte Hallo zusammen, wir zeigen Ihnen Fakten ( Sicherheit & Rendite ) Sicherheit & Rendite für alle! Fakten: - Deutsche Wertpapierhandelsbank - BaFin registriert, kontrolliert und überwacht (Somit höchstmögliche Sicherheit) - EdW reguliert... von Brayn	5	236	04.10.2010, 15:12 Brayn

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

Mach mit!

Verwandte Suchbegriffe