Kanibal
Lt. Commander
- Registriert
- Dez. 2011
- Beiträge
- 1.032
Jo, und bei jedem Durchgang erhöhst du die Kollisions-Wahrscheinlichkeit deines Hashing-Algorithmus.terminator60000 schrieb:
Lösung: einen geeigneten Passwort-Hashing-Algorithmus verwenden.
Wieso braucht ein Passwort Sonderzeichen?
- Ersteller PW-toXic
- Erstellt am
Lösung: einen geeigneten Passwort-Hashing-Algorithmus verwenden.
ice-breaker
Commodore
- Registriert
- Nov. 2008
- Beiträge
- 4.132
Das Argument ist ziemlich schwach, schau dir mal PBKDF2 an. Und das haben ne Menge klügere Leute als wir entwickelt und analysiert.
Oder auch einfach, dass für SHA1 bis heute noch immer keine einzige Kollision bekannt ist.
Oder auch einfach, dass für SHA1 bis heute noch immer keine einzige Kollision bekannt ist.
Kanibal
Lt. Commander
- Registriert
- Dez. 2011
- Beiträge
- 1.032
Nein, mein Argument ist nicht schwach.
Den mathematischen Hintergrund kannst Du dir hier aneignen.
Nur soviel vornweg: Bei PBKDF2 funktioniert das, weil sie eine symmetrische Kryptografie mit variabler Schlüssellänge einsetzen. Hashes sind jedoch asymmetrisch und haben eine fixe Länge.
Mehrfaches Hashing funktioniert zwar bisher noch recht gut, ist aber technisch betrachtet nicht die schlauste Lösung. Dann doch lieber einen Algorithmus, der speziell deswegen langsam ist.
Den mathematischen Hintergrund kannst Du dir hier aneignen.
Nur soviel vornweg: Bei PBKDF2 funktioniert das, weil sie eine symmetrische Kryptografie mit variabler Schlüssellänge einsetzen. Hashes sind jedoch asymmetrisch und haben eine fixe Länge.
Mehrfaches Hashing funktioniert zwar bisher noch recht gut, ist aber technisch betrachtet nicht die schlauste Lösung. Dann doch lieber einen Algorithmus, der speziell deswegen langsam ist.
C
carom
Gast
Mal ganz kurz, etwas in Eile.
Dass man SQL-Injections vermeiden sollte, ist klar. Ich sehe nur überhaupt nicht den Zusammenhang zu Sonderzeichen in Passwörtern. Wie unterscheidet sich ein Passswort in dieser Hinsicht denn von einem Kommentarfeld oder Forenpost? Entweder, du unterbindest Injections, oder du hast ein Problem. Das Passwort kann nix dafür.
Dann kannst du dich auf Spaßvögel freuen, die automatisiert Accounts deiner User mit falschen Passwörtern füttern, um deren Zugang zu sperren.
Was das mehrfache Hashen angeht, da liegt die Wahrheit irgendwo in der Mitte, und Kanibal hat nicht unrecht. Mit einer kryptographisch starken Hashfunktion und einem guten Salt bringt das mehrfache hashen mit der _selben_ Funktion in der Hinsicht einen Vorteil, dass die Berechnungszeit eben ansteigt. Was eine gute Hashfunktion ist will ich jedoch nicht bewerten, und wenn man nicht aufpasst, dann ist Kanibals Aussage nicht mehr nur theoretisch. Dann kann man dann aber gleich auf bcrypt, PBKDF2 und co. setzen, wenn es um die Berechnungszeit geht.
Das Anwenden verschiedener Hashfunktionen hintereinander ist jedoch quatsch und senkt die Entropie, statt sie zu erhöhen.
Rainbow-Tables aus dem Netz sind nicht mehr das große Problem, sondern eher, dass man mit heutiger Hardware mit vertretbarem Aufwand schnell seine eigenen Tabellen aufstellen kann, sofern man weiß, wie beim Opfer hashes berechnet werden. Und dafür verwendet man nicht mehr nur normale Wörterbücher - im Netz gibt es Gigabytes an Textdateien, welche von Menschen erstellte Passwörter beinhalten, was natürlich viel wertvoller ist als ein normales Wörterbuch. Es gibt Gruppen, die die nichts anderes machen, als aus geklauten Datenbanken Passwörter zu extrahieren - nicht, um jemandem direkt zu schaden, sondern um solche Sammlungen aufzubauen. Da gab es mal einen Artikel in der ct oder ix, ist aber schon länger her.
terminator60000 schrieb:
Dass man SQL-Injections vermeiden sollte, ist klar. Ich sehe nur überhaupt nicht den Zusammenhang zu Sonderzeichen in Passwörtern. Wie unterscheidet sich ein Passswort in dieser Hinsicht denn von einem Kommentarfeld oder Forenpost? Entweder, du unterbindest Injections, oder du hast ein Problem. Das Passwort kann nix dafür.
terminator60000 schrieb:
Dann kannst du dich auf Spaßvögel freuen, die automatisiert Accounts deiner User mit falschen Passwörtern füttern, um deren Zugang zu sperren.
Was das mehrfache Hashen angeht, da liegt die Wahrheit irgendwo in der Mitte, und Kanibal hat nicht unrecht. Mit einer kryptographisch starken Hashfunktion und einem guten Salt bringt das mehrfache hashen mit der _selben_ Funktion in der Hinsicht einen Vorteil, dass die Berechnungszeit eben ansteigt. Was eine gute Hashfunktion ist will ich jedoch nicht bewerten, und wenn man nicht aufpasst, dann ist Kanibals Aussage nicht mehr nur theoretisch. Dann kann man dann aber gleich auf bcrypt, PBKDF2 und co. setzen, wenn es um die Berechnungszeit geht.
Das Anwenden verschiedener Hashfunktionen hintereinander ist jedoch quatsch und senkt die Entropie, statt sie zu erhöhen.
Rainbow-Tables aus dem Netz sind nicht mehr das große Problem, sondern eher, dass man mit heutiger Hardware mit vertretbarem Aufwand schnell seine eigenen Tabellen aufstellen kann, sofern man weiß, wie beim Opfer hashes berechnet werden. Und dafür verwendet man nicht mehr nur normale Wörterbücher - im Netz gibt es Gigabytes an Textdateien, welche von Menschen erstellte Passwörter beinhalten, was natürlich viel wertvoller ist als ein normales Wörterbuch. Es gibt Gruppen, die die nichts anderes machen, als aus geklauten Datenbanken Passwörter zu extrahieren - nicht, um jemandem direkt zu schaden, sondern um solche Sammlungen aufzubauen. Da gab es mal einen Artikel in der ct oder ix, ist aber schon länger her.
Zuletzt bearbeitet:
M
mambokurt
Gast
Die These im Originalpost war: wenn Sonderzeichen hinzukommen wird das passwort unsicherer weil aufgeschrieben. Und: ein längeres Passwort ohne Sonderzeichen ist genauso sicher wie ein kürzeres mit. Leider wurde da komplett mit Kombinatorik hantiert und Null mit Praxis: wenn eine Seite keine Sonderzeichen beim Passwort verlangt, und ich bekomme die Datenbank in die Finger, dann lasse ich meinen Cracker ersteinmal über Passwörter bis 10 zeichen mit Kleinbuchstaben laufen, dann erst über Großbuchstaben und dann erst über Sonderzeichen.
Weiss ich aber, dass Sonderzeichen und Großbuchstaben Pflicht sind, erspare ich mir gleich Passwörter dei nur aus Kleinbuchstaben bestehen und Passwörter ohne Sonderzeichen.
Rein von der Logik eines Crackers her ist daher ein Passwort mit Sonderzeichen immer sicherer, weil es im Regelfall zuletzt probiert wird. Ob jemand sich seine Passwörter irgendwo notiert sei mal dahingestellt(ich denke der Prozentsatz an Passwörtern die so rauskommen wird wohl verschwindend gering sein).
Zu deiner These: klar ist ein gezalzener Hash sicherer als ein ungesalzener, und zweifache Verschlüsselung sicherer als einfache. Trotzdem ändert das nichts an der Problematik der Sonderzeichen. Letztendlich kommt es doch nur darauf an, wieviel Rechenzeit die Hashfunktion fressen darf, bei einem typischen Server darf das sicherlich ruhig eine 10tel Sekunde sein.
Und zum Schluss: in meinen Standardpasswörtern habe ich auch keine Sonderzeichen, ich nutze recht lange Aneinanderreihungen von Worten (> 20 Zeichen), bei einem Standardwortschatz von 75000 Wörtern macht das bei 5 Wörtern 75000^5 = 2,3x10^24(würde man alle Wörter im Dictionary aneinanderhängen) Kombinationen (Bruteforce sparen wir uns bei der Länge), das ist etwas besser als ein 12 stelliges Passwort mit Großbuchstaben und Sonderzeichen und auch auf eine handytastatur bequem einzugeben.
Weiss ich aber, dass Sonderzeichen und Großbuchstaben Pflicht sind, erspare ich mir gleich Passwörter dei nur aus Kleinbuchstaben bestehen und Passwörter ohne Sonderzeichen.
Rein von der Logik eines Crackers her ist daher ein Passwort mit Sonderzeichen immer sicherer, weil es im Regelfall zuletzt probiert wird. Ob jemand sich seine Passwörter irgendwo notiert sei mal dahingestellt(ich denke der Prozentsatz an Passwörtern die so rauskommen wird wohl verschwindend gering sein).
Zu deiner These: klar ist ein gezalzener Hash sicherer als ein ungesalzener, und zweifache Verschlüsselung sicherer als einfache. Trotzdem ändert das nichts an der Problematik der Sonderzeichen. Letztendlich kommt es doch nur darauf an, wieviel Rechenzeit die Hashfunktion fressen darf, bei einem typischen Server darf das sicherlich ruhig eine 10tel Sekunde sein.
Und zum Schluss: in meinen Standardpasswörtern habe ich auch keine Sonderzeichen, ich nutze recht lange Aneinanderreihungen von Worten (> 20 Zeichen), bei einem Standardwortschatz von 75000 Wörtern macht das bei 5 Wörtern 75000^5 = 2,3x10^24(würde man alle Wörter im Dictionary aneinanderhängen) Kombinationen (Bruteforce sparen wir uns bei der Länge), das ist etwas besser als ein 12 stelliges Passwort mit Großbuchstaben und Sonderzeichen und auch auf eine handytastatur bequem einzugeben.
F_GXdx
Captain
- Registriert
- März 2006
- Beiträge
- 4.028
Trainmaster schrieb:
Der Zeichenraum kann beliebig groß gewählt werden, daher kann dieses Passwort beliebig sicher sein.
Das Grundproblem des Autors war natürlich, dass er nicht gesehen hat, dass seine Grenzwertbetrachtung zwar korrekt ist (mit Landau-Notation hätte er das allerdings besser ausdrücken können), aber, dass im endlichen Fall Algorithmen in derselben Komplexitätsklasse immernoch ein deutlich unterschiedliches Komplexitätsmaß haben können.
Im Extremfall kann man natürlich Algorithmen angeben, die im endlichen Fall beliebig unterschiedliche Laufzeiten haben und dennoch in derselben Komplexitätsklasse liegen.
Selbst Algorithmen, die eine beliebig höhere Komplexität haben können im endlichen Fall erst bei beliebig langen Eingaben ihre Komplexität auch zeigen, als einfachere Algorithmen.
Das heißt, es gibt durchaus Fälle, wo ein extrem komplexer Algorithmus für kurze Eingaben trotzdem schneller ist, als ein asymptotisch gesehen einfacher Algorithmus.
Praxisbeispiel: AKS Primzahltest.
Zuletzt bearbeitet:
O
omaliesschen
Gast
Finds bemerkenswert über was man sich alles streiten kann und es ist egal in welchem Forum man unterwegs. Selbst das Thema ist an sich ist unwichtig. Das soziale Konzept ist überall anzutreffen.
Was interessieren sich PWCracker für ein paar Nerds mit unknackbaren Passwörtern?
Das mit gängigen Hashalgorithmen verarbeitete durchschnittliche Nutzerpasswort überlebt in einem GPU Cluster nicht lange.
Was interessieren sich PWCracker für ein paar Nerds mit unknackbaren Passwörtern?
Das mit gängigen Hashalgorithmen verarbeitete durchschnittliche Nutzerpasswort überlebt in einem GPU Cluster nicht lange.
Zuletzt bearbeitet:
- Registriert
- Jan. 2005
- Beiträge
- 966
*sigh*
Passwort mit Sonderzeichen: "Passwort!"
Mein Passwort ohne Sonderzeichen und nur Kleinbuchstaben: "pifamulama"
Das "!" am Anfang oder Ende des Passworts ist das häufigste, was ich bei einer Sonderzeichenpflicht sehe. Ein schlaues Hackerprogramm ist durchaus in der Lage diese beiden Varianten eines jeden Passworts ohne anzuhängen. Ich behaupte mal es gibt in etwa 10 Standards, die etwa 95% der User abfangen, die ihr normales Passwort mit so einer Strategie um ein Sonderzeichen erweitern.
Nehmen wir mal 500.000 Wörter an, dann hat "MeinSicheresPasswort!" eine Sicherheit von 500.000 * 10 = 5 * 10^6
Mein Passwort dagegen hat eine Sicherheit von 26^10 = 10^14
Die Grenzwertbetrachtung hier ist doch vollkommen egal. Die Fragestellung lautet: wieviel mehr Zeichen muss ich verwenden, wenn ich nur auf Kleinbuchstaben setze im Vergleich dazu, wenn ich eine größere Range (zb 256 Zeichenvarianten) verwende
Meine Passwörter von >= 10 Zeichen sind sicher. Wenn ich etwas habe, was lokal per Bruteforce gehackt werden kann, dann gehe ich absolut sicher mit >= 20 Kleinbuchstaben. Es ist mir einfach zu blöd Sonderzeichen oder Großbuchstaben bei Passwörtern zu verwenden, weil das das eintippen enorm verlängert. Desweiteren lassen sich Passwörter, die man aussprechen kann, sehr einfach merken. Da stört es auch nicht, wenn ein Passwort 20 Zeichen lang ist. Wenn ich mir aber ein Passwort merken muss, das irgendwo auch Großbuchstaben enthält, dann tut man sich schon deutlich schwerer...
edit: Natürlich erhöht die Sonderzeichenpflicht die allgemeine Sicherheit eines Systems, da die ganz einfachen Wörterbuch Bruteforce Attacken dann nicht mehr funktionieren.
Ich lass es mir aber nicht nehmen, in einem Forum ein wenig rum zu trollen, wenn mich nervt, dass mein sicheres Passwort dauernd von irgendwelchen Systemen als unsicher beschimpft wird!
Natürlich ist das Thema nicht so einfach, wie ich es hier rein mathematisch "rechne", aber nerven tuts mich trotzdem!!
trollolol ... 3 Jahre alter Thread Revival!
Passwort mit Sonderzeichen: "Passwort!"
Mein Passwort ohne Sonderzeichen und nur Kleinbuchstaben: "pifamulama"
Das "!" am Anfang oder Ende des Passworts ist das häufigste, was ich bei einer Sonderzeichenpflicht sehe. Ein schlaues Hackerprogramm ist durchaus in der Lage diese beiden Varianten eines jeden Passworts ohne anzuhängen. Ich behaupte mal es gibt in etwa 10 Standards, die etwa 95% der User abfangen, die ihr normales Passwort mit so einer Strategie um ein Sonderzeichen erweitern.
Nehmen wir mal 500.000 Wörter an, dann hat "MeinSicheresPasswort!" eine Sicherheit von 500.000 * 10 = 5 * 10^6
Mein Passwort dagegen hat eine Sicherheit von 26^10 = 10^14
Die Grenzwertbetrachtung hier ist doch vollkommen egal. Die Fragestellung lautet: wieviel mehr Zeichen muss ich verwenden, wenn ich nur auf Kleinbuchstaben setze im Vergleich dazu, wenn ich eine größere Range (zb 256 Zeichenvarianten) verwende
Meine Passwörter von >= 10 Zeichen sind sicher. Wenn ich etwas habe, was lokal per Bruteforce gehackt werden kann, dann gehe ich absolut sicher mit >= 20 Kleinbuchstaben. Es ist mir einfach zu blöd Sonderzeichen oder Großbuchstaben bei Passwörtern zu verwenden, weil das das eintippen enorm verlängert. Desweiteren lassen sich Passwörter, die man aussprechen kann, sehr einfach merken. Da stört es auch nicht, wenn ein Passwort 20 Zeichen lang ist. Wenn ich mir aber ein Passwort merken muss, das irgendwo auch Großbuchstaben enthält, dann tut man sich schon deutlich schwerer...
edit: Natürlich erhöht die Sonderzeichenpflicht die allgemeine Sicherheit eines Systems, da die ganz einfachen Wörterbuch Bruteforce Attacken dann nicht mehr funktionieren.
Ich lass es mir aber nicht nehmen, in einem Forum ein wenig rum zu trollen, wenn mich nervt, dass mein sicheres Passwort dauernd von irgendwelchen Systemen als unsicher beschimpft wird!
Natürlich ist das Thema nicht so einfach, wie ich es hier rein mathematisch "rechne", aber nerven tuts mich trotzdem!!
trollolol ... 3 Jahre alter Thread Revival!
Zuletzt bearbeitet:
F_GXdx
Captain
- Registriert
- März 2006
- Beiträge
- 4.028
Naja, um mal bei den 256er Raum zu bleiben:
Dort ist schon ein 6-Zeichen Passwort doppelt so sicher wie dein Kleinbuchstabenpasswort mit 10 Zeichen.
256^6 = 2,8 * 10^14
26^10 = 1,4 * 10^14
Und mit 10 Zeichen ist dieser Raum so sicher wie ein Kleinbuchstabenpasswort mit 17 Zeichen.
Das alles natürlich nur in der Theorie.
Dort ist schon ein 6-Zeichen Passwort doppelt so sicher wie dein Kleinbuchstabenpasswort mit 10 Zeichen.
256^6 = 2,8 * 10^14
26^10 = 1,4 * 10^14
Und mit 10 Zeichen ist dieser Raum so sicher wie ein Kleinbuchstabenpasswort mit 17 Zeichen.
Das alles natürlich nur in der Theorie.
...und genau deshalb sollen sich gerade die Entwickler der Problematik komplett bewusst sein. Wenn du weißt, dass das Cluster-Problem existiert, dann kannst du es gezielt angehen. Du kannst (und solltest) statt der bewusst schnellen Hashfunktionen eben auf die bewusst langsamen Crypt-Funktionen zurückgreifen.
O
omaliesschen
Gast
Daaron schrieb:
Was wiederum selbst Angriffsfläche schaffen kann. Aber ein in die Knie gehender Server ist natürlich besser als eine gecrackte DB.
C
carom
Gast
omaliesschen schrieb:
Funktionen wie bcrypt und vor allem scrypt sind ganz schlecht für GPUs und FPGAs, ohne große Auswirkungen auf die allgemein arbeitende CPU zu haben, welche eine Menge Ram adressieren kann - zumal sich die Kosten ja einstellen lassen.
Er bezog sich eher auf BF-Angriffe auf einen Webserver, bei denen du eben nicht mal eben eine GPU-Methode verwenden kannst, sondern so viele Versuche startest wie der Server eben beantworten kann.
Und ja, ein krepierender Server ist viel harmloser als einer, der ratzfatz auf Fehlversuche reagiert und am Ende positiv auf Brute-Force anspricht. So verlierst du im Zweifel nur etwas Einkommen (weil dein Shop down ist), aber hast keinen Presseskandal an der Backe wie z.B. Mr. Spex. Zumal man einen Server auch anderweitig abschießen kann, als über einen BF-Angriff auf den Login. Gegen DDoS per Botnet ist eh kaum ein Kraut gewachsen.
Und ja, ein krepierender Server ist viel harmloser als einer, der ratzfatz auf Fehlversuche reagiert und am Ende positiv auf Brute-Force anspricht. So verlierst du im Zweifel nur etwas Einkommen (weil dein Shop down ist), aber hast keinen Presseskandal an der Backe wie z.B. Mr. Spex. Zumal man einen Server auch anderweitig abschießen kann, als über einen BF-Angriff auf den Login. Gegen DDoS per Botnet ist eh kaum ein Kraut gewachsen.
C
carom
Gast
Daaron schrieb:
Jup, das ist klar. Ich wollte nur zum Ausdruck bringen, dass bcrypt und Co. mit ordentlich Ram und gewöhnlicher CPU (also beispielsweise auf einem Server) viel ökonomischer zu berechnen ist als auf GPUs (weil du derartige Funktionen gegen GPU-Cluster vorgeschlagen hast) und die vermeintliche Angriffsfläche somit kleiner ist, als man vielleicht vermuten würde.
Und selbst wenn, dann gäbe es mit etwas Überlegen im Gegensatz zu DDoS genug Strategien, wie man einen solchen Angriff abwehren kann, ohne dass der Server auch nur irgendwie beeinträchtigt wird. Zur Not schaltet man temporär Registration und Login ab, womit die "teure" Operation von außen gar nicht mehr erreichbar ist. Findet man das unschön, dann kann man bei der Registration beispielsweise das Passwort erst nach der üblichen Email an den neuen User setzen lassen, oder man steckt Registrierungsanfragen in eine Queue, die nur ein Bruchteil aller Ressourcen zur Verfügung hat, den Login wiederum könnte man während eines Angriffs auf 2 Faktor-Authentifizierung mittels Mail umstellen und so weiter und so fort... das ist ein Angriffspunkt, dem man dem Angreifer einfach wegnehmen kann. Als imho lohnt sich das überhaupt nicht.
Zuletzt bearbeitet:
Jo, rein theoretisch kann man den Login einfach temporär ausblenden um den login-losen Betrieb noch weiter gewährleisten zu können. Bei Shops mit anonymer Bestellung (z.B. in Magento) wäre das durchaus eine Option.
Ich finds eher schade, dass sehr wenige CMS/Shopsysteme auf anständige Verfahren setzen. Die setzen alle bestenfalls auf mehrfaches SHA1 mit Salt. Dabei ist bcrypt doch keine Magie....
Ich finds eher schade, dass sehr wenige CMS/Shopsysteme auf anständige Verfahren setzen. Die setzen alle bestenfalls auf mehrfaches SHA1 mit Salt. Dabei ist bcrypt doch keine Magie....
Zuletzt bearbeitet:
terminator60000
Newbie
- Registriert
- Mai 2013
- Beiträge
- 3
Hallo,
@ Kanibal,
die Kollisions Wahrscheinlichkeit gibt es nicht, wenn man den Hash Saltet, und hinten beispielsweise noch die ID des Users dran hängt, dann ist der Hash einmalig.
Beispiel: das Passwort beim registrieren erfassen, und die ID des users an den String des Passwortes hängen, dann das ganze in sha1 oder Md5 mehrfach hashen, einen Salt benutzen z.B. alle Zahlen 4 mit 3 austauschen und umgekehrt, und hinten noch die ID des Users dran, da wünsche ich dem Hacker mal viel spaß bei...
PS: bei einem reinem MD5 oder Sha1 hast du mit der Kollision natürlich recht, (auch wenn ich das mal überprüft habe, und einen hash hatte, welcher vorher ein text war, diesen habe ich versucht durch hashen von aufwertigen zeichen zu emulieren, was jedoch scheiterte.
@ carom,
Nunja, wenn man Sonderzeichen in Usernames oder Passwörtern erlaubt, kann man bei schlecht Programmierten Login Formularen einfach in jeden X beliebigen Account hinein kommen, was bei Kommentar Feldern nicht passieren kann, da man dort keine Session anhand der Daten die ein User eingibt aufbaut, jedoch kann man über schlecht gecodete Kommentar Felder o.ä. schadcode in die Seite einschleusen. (was aber Off Topic ist)
@ carom,
Da hast du mich Missverstanden, ich meinte nicht dass das Nutzerkonto gesperrt werden soll, sondern die IP Adresse mit der das Passwort 5 mal falsch eingegeben wurde. Der User wäre davon keineswegs betroffen.
@ PW-toXic
Sehe ich persönlich anders, wenn du von reinen Passwörtern ausgehst, ist das Natürlich sicherer, aber gehen wir mal von einem "gutem" Programmierer aus, welcher sehr viel wert auf sicherheit legt, dann dürfte eine Brute Force Attacke schonmal weg fallen, da er wie in meinem 1. Post geschrieben immer nach 5 versuchen gesperrt werden würde, selbst über ein Botnetz, wäre es ein erheblicher aufwand für einen Hacker, alle Bots 5 bestimmte Passwort Anweisungen zu geben, und das ganze zu koordinieren, denn jeder Bot müsste sich mit den 5 Eingaben abwechseln und es dürften keine angaben ausgelassen werden (da diese ja das potenzielle Passwort bedeuten könnten).
Alles in einem wollte ich nur zum Ausdruck bringen, dass es heutzutage genügend Methoden gibt, welche das Hacken von Passwörtern dermaßen erschweren können, sodass eine zwangsweise eingabe von Sonderzeichen, Großbuchstaben und Zahlen überflüssig ist, ich finde es sogar als Nötigung wenn ich dazu gezwungen werde, schliesslich geht es um Meine persönlichen Daten, und ich habe selber schuld wenn mein Passwort in 5 minuten herausgefunden wird, da es "Haus" oder "123" heisst. Heutige Registrierungs Programme, sollten nach meiner sicht in der lage sein, zu erkennen dass ein User ein schwaches Passwort hat, indem man es evtl mit einer Datenbank abgleicht welche die wörter aus dem Duden besitzt und Personen namen. Denn ich glaube nicht, dass ein Passwort welches 18 Zeichen lang ist, und aus Kauderweltsch besteht, jedoch ohne sonderzeichen mindestens genauso zeitintensiv im Cracken ist, wie eines welches Sonderzeichen, zahlen + große und kleine buchstaben besitzt und 5 zeichen lang ist.
Wie bereits geschrieben: Alles eine Frage der Technik ?!
Mit freundlichen Grüßen
Yasar Güven
PS: Nervt euch das auch, wenn man sich irgendwo registrieren möchte, und nur eine Maximale länge für ein Passwort eingeben darf? (Teilweise sogar nur 8 Zeichen)
@ Kanibal,
die Kollisions Wahrscheinlichkeit gibt es nicht, wenn man den Hash Saltet, und hinten beispielsweise noch die ID des Users dran hängt, dann ist der Hash einmalig.
Beispiel: das Passwort beim registrieren erfassen, und die ID des users an den String des Passwortes hängen, dann das ganze in sha1 oder Md5 mehrfach hashen, einen Salt benutzen z.B. alle Zahlen 4 mit 3 austauschen und umgekehrt, und hinten noch die ID des Users dran, da wünsche ich dem Hacker mal viel spaß bei...
PS: bei einem reinem MD5 oder Sha1 hast du mit der Kollision natürlich recht, (auch wenn ich das mal überprüft habe, und einen hash hatte, welcher vorher ein text war, diesen habe ich versucht durch hashen von aufwertigen zeichen zu emulieren, was jedoch scheiterte.
@ carom,
Nunja, wenn man Sonderzeichen in Usernames oder Passwörtern erlaubt, kann man bei schlecht Programmierten Login Formularen einfach in jeden X beliebigen Account hinein kommen, was bei Kommentar Feldern nicht passieren kann, da man dort keine Session anhand der Daten die ein User eingibt aufbaut, jedoch kann man über schlecht gecodete Kommentar Felder o.ä. schadcode in die Seite einschleusen. (was aber Off Topic ist)
@ carom,
Da hast du mich Missverstanden, ich meinte nicht dass das Nutzerkonto gesperrt werden soll, sondern die IP Adresse mit der das Passwort 5 mal falsch eingegeben wurde. Der User wäre davon keineswegs betroffen.
@ PW-toXic
Sehe ich persönlich anders, wenn du von reinen Passwörtern ausgehst, ist das Natürlich sicherer, aber gehen wir mal von einem "gutem" Programmierer aus, welcher sehr viel wert auf sicherheit legt, dann dürfte eine Brute Force Attacke schonmal weg fallen, da er wie in meinem 1. Post geschrieben immer nach 5 versuchen gesperrt werden würde, selbst über ein Botnetz, wäre es ein erheblicher aufwand für einen Hacker, alle Bots 5 bestimmte Passwort Anweisungen zu geben, und das ganze zu koordinieren, denn jeder Bot müsste sich mit den 5 Eingaben abwechseln und es dürften keine angaben ausgelassen werden (da diese ja das potenzielle Passwort bedeuten könnten).
Alles in einem wollte ich nur zum Ausdruck bringen, dass es heutzutage genügend Methoden gibt, welche das Hacken von Passwörtern dermaßen erschweren können, sodass eine zwangsweise eingabe von Sonderzeichen, Großbuchstaben und Zahlen überflüssig ist, ich finde es sogar als Nötigung wenn ich dazu gezwungen werde, schliesslich geht es um Meine persönlichen Daten, und ich habe selber schuld wenn mein Passwort in 5 minuten herausgefunden wird, da es "Haus" oder "123" heisst. Heutige Registrierungs Programme, sollten nach meiner sicht in der lage sein, zu erkennen dass ein User ein schwaches Passwort hat, indem man es evtl mit einer Datenbank abgleicht welche die wörter aus dem Duden besitzt und Personen namen. Denn ich glaube nicht, dass ein Passwort welches 18 Zeichen lang ist, und aus Kauderweltsch besteht, jedoch ohne sonderzeichen mindestens genauso zeitintensiv im Cracken ist, wie eines welches Sonderzeichen, zahlen + große und kleine buchstaben besitzt und 5 zeichen lang ist.
Wie bereits geschrieben: Alles eine Frage der Technik ?!
Mit freundlichen Grüßen
Yasar Güven
PS: Nervt euch das auch, wenn man sich irgendwo registrieren möchte, und nur eine Maximale länge für ein Passwort eingeben darf? (Teilweise sogar nur 8 Zeichen)
Ich versteh nicht, wo ein Sonderzeichen ein Problem darstellen sollen. @ ist z.B. ein Sonderzeichen, und trotzdem in Unmengen Logins vorhanden... für Amis und sogar Schweizer ist ß ein Sonderzeichen, für uns wäre die Ligatur "œ" ein Sonderzeichen. Und was wäre erst mit Logins in Katakana?terminator60000 schrieb:
Spätestens mit Prepared Statements kannst du sogar ein Semikolon ohne Risiken in Datenbanken übergeben.
Nix, was ein Botnetz aufhält. Primäre Angreifer sind heute doch keine einzelnen Rechner mehr, sondern Command & Control - Server.
Wo ist das Problem? Du hast einen zu prüfenden Bereich, meinetwegen 30 Stellen ohne Umlaute/Ligaturen oder Sonderzeichen, aber mit Versalien und Ziffern. Du hast n Bots. jetzt splittest du deine zu prüfende Liste in n Fragmente und gibst jedem Bot seinen Aufgabenzettel...
Nein, das Risiko trägt der Anbieter. Denn im Zweifel klagt der blöde Kunde, zieht damit vors Landgericht Hamburg und kriegt bei selbigem natürlich Recht, ist ja normal bei dem Ding... Internet-Problem? Wissen wir nix von, verstehen wir nix von, SCHULDIG!
Und was wäre mit folgendem Fall: Ein Hacker dringt in deinen Mailaccount ein und knackt zusätzlich dein Passwort für Amazon (bei denen du auch noch Lastschrift nutzt). Er bestellt auf deine Kosten einige Keys für aktuelle Spiele, sagen wir mal im Umfang von 400€... er fängt selbige Keys natürlich ab, das Geld geht von deinem Konto ab. Evtl. kriegt der gelinkte Kunde sein Geld von der Versicherung zurück, der Anbieter kriegt seine Keys aber nicht.
Nein, keine Frage der Technik. Selbst mit einer Millionen Bots könntest du nicht schneller gegen einen Webdienst Brute-Forcen als mit einigen Hundert.
Und was den Rechenaufwand angeht: In deinem Beispiel gewinnen die 18 Stellen, aber aufgrund der Tatsache, dass sich die Menge der Möglichkeiten exponentiell über die Wortlänge erhöht, und selbiger Exponent bei höhere Zeichenauswahl natürlich deutlich größer ist, sind mittelgroße Passwörter mit Sonderzeichen deutlich sicherer als lange PWs ohne.
Eggcake
Commodore
- Registriert
- Juni 2007
- Beiträge
- 4.837
Ich will mich nicht unbedingt in die Diskussion einmischen, sondern lediglich auf eine Reihe interessanter Artikel auf Arstechnica aufmerksam machen:
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
Das ist der neueste, der veröffentlich wurde (wenn's interessiert, einfach denim Artikel verlinkten, früheren Beiträgen folgen).
Zu Sonderzeichen:
Was praktisch nichts bringt ist, wenn die User die Sonderzeichen und Zahlen einfach z.b. so einsetzen:
eggcake
vs.
3ggc@k3
So schlau sind die Crack-Programme dann mittlerweile schon. Geht sicherlich etwas länger, keine Frage, aber das Passwort ansich ist nicht wirklich sicherer.
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
Das ist der neueste, der veröffentlich wurde (wenn's interessiert, einfach denim Artikel verlinkten, früheren Beiträgen folgen).
Zu Sonderzeichen:
Was praktisch nichts bringt ist, wenn die User die Sonderzeichen und Zahlen einfach z.b. so einsetzen:
eggcake
vs.
3ggc@k3
So schlau sind die Crack-Programme dann mittlerweile schon. Geht sicherlich etwas länger, keine Frage, aber das Passwort ansich ist nicht wirklich sicherer.