Passwort verschlüsseln

[Oliver Hirschi]

Hi,

Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.

Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Thanxs.

[Andreas Schröter]

Post by Oliver Hirschi
Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Wie sicher sollen die Passwörter sein? Wenn es einfach nur um die reine
Anmeldung geht, sollte eine simple XOR-Verknüpfung langen. Hängen davon
schützenswerte Daten dahinter, die eine spezielle Berechtigung benötigen
(z.B. im Medizinsektor), so ist eine [a]symmetrische Verschlüsselung schon
sinnvoll, auch hierzu gibt es von Sun Bibliotheken, erst heute um 8:25
wollte Andreas H. etwas über die Verschlüsselung in Verbindung mit
Zertifikaten wissen.

Andreas

[Oliver Hirschi]

Post by Andreas Schröter

Post by Oliver Hirschi
Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Wie sicher sollen die Passwörter sein? Wenn es einfach nur um die reine
Anmeldung geht, sollte eine simple XOR-Verknüpfung langen. Hängen davon
schützenswerte Daten dahinter, die eine spezielle Berechtigung benötigen
(z.B. im Medizinsektor), so ist eine [a]symmetrische Verschlüsselung schon
sinnvoll, auch hierzu gibt es von Sun Bibliotheken, erst heute um 8:25
wollte Andreas H. etwas über die Verschlüsselung in Verbindung mit
Zertifikaten wissen.

Dahinter stecken nicht speziell schützenswerte Daten, die Passwörter
sollten sicherlich nicht plain in der Datenbank vorliegen. Im moment
werden die HEX-Werte der einzelnen Zeichen in die DB geschrieben, aber
das ist ja auch nicht wirklich das gelbe vom Ei.
Am liebsten würde ich nicht ain all zu Grosses TamTam darum machen. zwei
statische Methoden (encode, decode) wäre genial!

XOR-Verknüpfung?

danke & gruss, Oli

[Michael Borgwardt]

Post by Oliver Hirschi
Dahinter stecken nicht speziell schützenswerte Daten, die Passwörter
sollten sicherlich nicht plain in der Datenbank vorliegen. Im moment
werden die HEX-Werte der einzelnen Zeichen in die DB geschrieben, aber
das ist ja auch nicht wirklich das gelbe vom Ei.
Am liebsten würde ich nicht ain all zu Grosses TamTam darum machen. zwei
statische Methoden (encode, decode) wäre genial!

Du willst keine Verschlüsselung sondern einen kryptographischen Hash,
da brauchst Du auch kein decode, du legst einfach das Ergebnis der
Operation in der DB ab und wenn der Benutzer sein Paßwort eingibt,
berechnest Du ebenfalls den Hash und schaust, ob das Gleiche herauskommt.

Ist übrigens genau das, was Bodo vorgeschlagen hat. Statt MD5 könnte
man auch SHA1 nehmen.

[Andree Große]

Post by Michael Borgwardt
Du willst keine Verschlüsselung sondern einen kryptographischen Hash,
da brauchst Du auch kein decode, du legst einfach das Ergebnis der
Operation in der DB ab und wenn der Benutzer sein Paßwort eingibt,
berechnest Du ebenfalls den Hash und schaust, ob das Gleiche herauskommt.
Ist übrigens genau das, was Bodo vorgeschlagen hat. Statt MD5 könnte
man auch SHA1 nehmen.

Und crypt gibbet auch für Java. Google kennt den Weg dorthin.
A.G.

[Bodo Wippermann]

Post by Oliver Hirschi
Hi,
Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?
Thanxs.

Wenn Du keine besonderen Anforderungen hast, sieh dir mal das
java.security-Package an. Mini-Version:

String create(String algorithm, String decoded)
throws NoSuchAlgorithmException
{
java.security.MessageDigest md = java.security.MessageDigest
.getInstance(algorithm);
md.update(decoded.getBytes());
return new String(md.digest());
}

als Algorithmus z.B. "MD5" nutzen

HTH
Bodo

[Nico Seessle]

Post by Bodo Wippermann

Post by Oliver Hirschi
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?
Thanxs.

Wenn Du keine besonderen Anforderungen hast, sieh dir mal das
als Algorithmus z.B. "MD5" nutzen

MD5 ist *keine* Verschlüsselung, sondern ein Hashalgorithmus. Das
Password lässt sich also nicht wieder von der abgespeicherten Form in
den Klartext zurückübersetzen.

Das nur zur Klarstellung - ds vom OP zu lösende Problem sollte sich
damit trotzdem lösen lassen.

Nico

[Harald Vogt]

Post by Bodo Wippermann

Post by Oliver Hirschi
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Wenn Du keine besonderen Anforderungen hast, sieh dir mal das

Mit diesem Algorithmus wird das Passwort nicht wirklich verschlüsselt,
sondern es wird ein Hash gebildet, der aber ebenso gut ist, weil man das
ursprüngliche Passwort nicht daraus errechnen kann.

Ein Problem ist, dass zwei gleiche Passwörter auch den gleichen Hashwert
bekommen. Man sollte also z.B. noch den Benutzernamen mit in die
Hash-Berechnung aufnehmen, also noch einen Aufruf einfügen:

md.update(username.getBytes());

Wenn man Wert auf höhere Sicherheit legt, sollte man aber nicht MD5
benutzen, sondern z.B. SHA-256 (braucht aber ein entsprechendes Java
security policy configuration file).

[Michael Borgwardt]

Post by Harald Vogt
Wenn man Wert auf höhere Sicherheit legt, sollte man aber nicht MD5
benutzen, sondern z.B. SHA-256

Das dürfte ziemlich überflüssig sein, weil das Hauptproblem sowieso
dictionary-Attacken sind und selbst die besten realistisch verwendbaren
Paßwörter nicht annähernd 128 bits an Entropie enthalten.

[Harald Vogt]

Post by Michael Borgwardt
Das dürfte ziemlich überflüssig sein, weil das Hauptproblem sowieso
dictionary-Attacken sind und selbst die besten realistisch verwendbaren
Paßwörter nicht annähernd 128 bits an Entropie enthalten

Auch wieder wahr. - Und die dictionary-Attacke sollte ja durch die
Aufnahme des Benutzernamens in die Hashberechnung auch schon ausreichend
erschwert sein.

[Michael Borgwardt]

Post by Harald Vogt

Post by Michael Borgwardt
Das dürfte ziemlich überflüssig sein, weil das Hauptproblem sowieso
dictionary-Attacken sind und selbst die besten realistisch verwendbaren
Paßwörter nicht annähernd 128 bits an Entropie enthalten

Auch wieder wahr. - Und die dictionary-Attacke sollte ja durch die
Aufnahme des Benutzernamens in die Hashberechnung auch schon ausreichend
erschwert sein.

Wenn der Angreifer die Anmeldedaten aus der Datenbank hat, dann kennt er den
Benuternamen sowieso. Und beim "normalen" weg über das echte Anmeldeformular
sollte eine Dictionary- oder brute-force-Attacke sowieso zusätzlich unmöglich
gemacht werden durch eine Sperrung des Kontos nach zu vielen Fehleingaben
oder zumindest eine künstliche Verzögerung.

[Harald Vogt]

Post by Michael Borgwardt
Wenn der Angreifer die Anmeldedaten aus der Datenbank hat, dann kennt er den
Benuternamen sowieso. Und beim "normalen" weg über das echte
Anmeldeformular
sollte eine Dictionary- oder brute-force-Attacke sowieso zusätzlich unmöglich
gemacht werden durch eine Sperrung des Kontos nach zu vielen Fehleingaben
oder zumindest eine künstliche Verzögerung
.

Für eine Dictionary-Attacke braucht es ja keinen Zugriff auf das System
für jeden Versuch, sondern man muss nur den Hash des Passworts kennen.
Dann kann man alle Hashwerte offline berechnen und vergleichen.

Der Benutzername im Hashwert erschwert die Sache dahingehend, dass diese
Vorgang für jeden Benutzer separat durchgeführt werden muss. Einmal alle
Hashwerte für alle Benutzer berechnen reicht dann also nicht.

Dass ein Anmeldeformular nach zu vielen Fehleingaben das Benutzerkonto
sperrt, sollte eh klar sein. Aber wenn das der einzige Zugang zum System
wäre, bräuchte man ja auch gar keine "verschlüsselte" Ablage der
Passwörter. Also muss man davon ausgehen, dass man sich auch gegen
Angreifer schützen will, die das verschlüsselte Passwort kennen.

[Michael Borgwardt]

Post by Harald Vogt
Für eine Dictionary-Attacke braucht es ja keinen Zugriff auf das System
für jeden Versuch, sondern man muss nur den Hash des Passworts kennen.
Dann kann man alle Hashwerte offline berechnen und vergleichen.
Der Benutzername im Hashwert erschwert die Sache dahingehend, dass diese
Vorgang für jeden Benutzer separat durchgeführt werden muss. Einmal alle
Hashwerte für alle Benutzer berechnen reicht dann also nicht.

Ah, OK, das stimmt natürlich.

[Daniel Urban]

Post by Harald Vogt
Für eine Dictionary-Attacke braucht es ja keinen Zugriff auf das System
für jeden Versuch, sondern man muss nur den Hash des Passworts kennen.

Und natürlich den Algorithmus.

Post by Harald Vogt
Dann kann man alle Hashwerte offline berechnen und vergleichen.

ja.

Post by Harald Vogt
Der Benutzername im Hashwert erschwert die Sache dahingehend, dass diese
Vorgang für jeden Benutzer separat durchgeführt werden muss. Einmal alle
Hashwerte für alle Benutzer berechnen reicht dann also nicht.

Das mag in der Praxis bei schlechter Paßwortwahl richtig sein. Aber
theoretisch ist es egal, da die Wahrscheinlichkeit nicht steigt, daß man ein
Paßwort errät.

Gruß,

Daniel

[Paul Ebermann]

Post by Daniel Urban

Post by Harald Vogt
Für eine Dictionary-Attacke braucht es ja keinen Zugriff auf das System
für jeden Versuch, sondern man muss nur den Hash des Passworts kennen.

Und natürlich den Algorithmus.

Den kennt man per definitionem immer.

Post by Daniel Urban

Post by Harald Vogt
Dann kann man alle Hashwerte offline berechnen und vergleichen.

ja.

Post by Harald Vogt
Der Benutzername im Hashwert erschwert die Sache dahingehend, dass diese
Vorgang für jeden Benutzer separat durchgeführt werden muss. Einmal alle
Hashwerte für alle Benutzer berechnen reicht dann also nicht.

Das mag in der Praxis bei schlechter Paßwortwahl richtig sein. Aber
theoretisch ist es egal, da die Wahrscheinlichkeit nicht steigt, daß man ein
Paßwort errät.

Die Wahrscheinlichkeit, ein Passwort zu erraten,
hängt ja von der Länge ab. Wenn einfach alle möglichen
Passwörter durchprobiert werden, muss man (wenn kein
Nutzername dabei ist) nur schauen, ob bei den x
gespeicherten Hashs das Ergebnis dabei ist. (Falls
es einem reicht, irgendeinen Account zu knacken -
aber auch, wenn man alle knacken will.)

Falls der Nutzername dabei ist, vervielfacht sich
die Anzahl der zu probierenden Passwörter um x,
da das Ergebnis sowieso nur an einer Stelle etwas
taugt.


Paul

[Daniel Urban]

Post by Paul Ebermann

Post by Daniel Urban
Das mag in der Praxis bei schlechter Paßwortwahl richtig sein. Aber
theoretisch ist es egal, da die Wahrscheinlichkeit nicht steigt, daß man ein
Paßwort errät.

Die Wahrscheinlichkeit, ein Passwort zu erraten,
hängt ja von der Länge ab.

Genau. Aber dann reicht es auch, einfach ein längeres Paßwort zu wählen. Der
Nutzername als solches schafft keinen Vorteil.

Post by Paul Ebermann
Wenn einfach alle möglichen
Passwörter durchprobiert werden, muss man (wenn kein
Nutzername dabei ist) nur schauen, ob bei den x
gespeicherten Hashs das Ergebnis dabei ist.

Da ist kein Unterschied. Gleiches muß man auch tun, wenn der Nutzername drin
ist. Bei Brute-Force ist der Nutzername irrelevant. Bei Dictionary-Attack
schon, aber wenn die klappt, war das Paßwort schlecht gewählt (zu kurz
und/oder ohne Sonderzeichen usw.)

Post by Paul Ebermann
Falls der Nutzername dabei ist, vervielfacht sich
die Anzahl der zu probierenden Passwörter um x,
da das Ergebnis sowieso nur an einer Stelle etwas
taugt.

Bei Brute-Force nicht, denn Du probierst weiterhin nur Paßwörter aus und
wartest, bis eines den richtigen Hashwert erzeugt. Die Wahrscheinlichkeit
ist absolut gleich unabhängig vom Aufbau des Paßwortes.

Dictionary-Attacke klappt nur, wenn das Paßtwort schlecht gewählt ist.

Wenn der Algorithmus den Nutzernamen automatisch einbindet, dann ist der
Effekt bei der Dictionary-Attake auch weg, da der Algorithmus als bekannt
vorausgesetzt wird, wie Du oben erwähntest.

Gruß,

Daniel

[Paul Ebermann]

Post by Daniel Urban

Post by Paul Ebermann

Post by Daniel Urban
Das mag in der Praxis bei schlechter Paßwortwahl richtig sein. Aber
theoretisch ist es egal, da die Wahrscheinlichkeit nicht steigt,
daß man ein Paßwort errät.

Die Wahrscheinlichkeit, ein Passwort zu erraten,
hängt ja von der Länge ab.

Genau. Aber dann reicht es auch, einfach ein längeres Paßwort zu wählen. Der
Nutzername als solches schafft keinen Vorteil.

Das machen die Leute aber nicht.
Ob ich mir nun "ABCDEF" und "ePaul" (wird zu
hash("ePaul:ABCDEF")) oder "ABCDEFGHIJKL" und
"ePaul" (wird zu hash("ABCDEFGHIJKL")) merken
muss, macht schon einen Unterschied.

Post by Daniel Urban

Post by Paul Ebermann
Wenn einfach alle möglichen Passwörter durchprobiert
werden, muss man (wenn kein Nutzername dabei ist) nur
schauen, ob bei den x gespeicherten Hashs das Ergebnis
dabei ist.

Da ist kein Unterschied. Gleiches muß man auch tun, wenn der
Nutzername drin ist.

Da sind es aber mehr.

Post by Daniel Urban
Bei Brute-Force ist der Nutzername irrelevant. Bei Dictionary-Attack
schon, aber wenn die klappt, war das Paßwort schlecht gewählt (zu kurz
und/oder ohne Sonderzeichen usw.)

Post by Paul Ebermann
Falls der Nutzername dabei ist, vervielfacht sich
die Anzahl der zu probierenden Passwörter um x,
da das Ergebnis sowieso nur an einer Stelle etwas
taugt.

Bei Brute-Force nicht, denn Du probierst weiterhin nur Paßwörter aus und
wartest, bis eines den richtigen Hashwert erzeugt. Die Wahrscheinlichkeit
ist absolut gleich unabhängig vom Aufbau des Paßwortes.

Wenn man weiß, dass alle Hash-Originale der Form "***@..."
sind, probiert man natürlich nur solche durch (und nur mit
den vorhandenen Nutzern).

Bei x Nutzern entspricht das also vom Aufwand einer Verlängerung
der Passworte um log(x) Zeichen (die Basis des log ist hier
die Größe des Alphabetes, aber das ist ja nur ein konstanter
Faktor).

Bei sehr langen zufällig gewählten Passwörtern
ist natürlich eine Brute-Force-Attacke so oder
so sinnlos - da macht dieser Faktor auch nichts
mehr aus.

Aber in der Praxis ist dies nicht der Fall (sehr
lange Passwörter kann sich niemand merken) - und
bei kürzeren Passworten und sehr vielen Nutzern
wird das schon eine Rolle spielen.

Post by Daniel Urban
Dictionary-Attacke klappt nur, wenn das Paßtwort schlecht gewählt ist.
Wenn der Algorithmus den Nutzernamen automatisch einbindet, dann ist der
Effekt bei der Dictionary-Attake auch weg, da der Algorithmus als bekannt
vorausgesetzt wird, wie Du oben erwähntest.

Wie gesagt, Faktor x.


Paul

[Andree Große]

Post by Paul Ebermann
Das machen die Leute aber nicht.
Ob ich mir nun "ABCDEF" und "ePaul" (wird zu
hash("ePaul:ABCDEF")) oder "ABCDEFGHIJKL" und
"ePaul" (wird zu hash("ABCDEFGHIJKL")) merken
muss, macht schon einen Unterschied.

Und das nennst du Verschlüsselung? Was hat das alles
mit Paßwörtern zu tun? Entknack doch mal: AAZk9HRa8wS3A

A.G.

[Paul Ebermann]

Post by Andree Große

Post by Paul Ebermann
Das machen die Leute aber nicht.
Ob ich mir nun "ABCDEF" und "ePaul" (wird zu
hash("ePaul:ABCDEF")) oder "ABCDEFGHIJKL" und
"ePaul" (wird zu hash("ABCDEFGHIJKL")) merken
muss, macht schon einen Unterschied.

Und das nennst du Verschlüsselung?

Nein. ABC... war ein Prototyp eines Passwortes,
nicht dessen Verschlüsselung.
Und es geht hier nicht um Verschlüsselung, sondern
um einen Hash.


Paul

[Andree Große]

Post by Paul Ebermann
Nein. ABC... war ein Prototyp eines Passwortes,
nicht dessen Verschlüsselung.
Und es geht hier nicht um Verschlüsselung, sondern
um einen Hash.

Und ich dachte im Betreff steht: Passwort verschlüsseln.
Wird hier java-Hash mit Hash-Algorithmus verwechselt?

A.G.

[Daniel Urban]

Post by Andree Große

Post by Paul Ebermann
Nein. ABC... war ein Prototyp eines Passwortes,
nicht dessen Verschlüsselung.
Und es geht hier nicht um Verschlüsselung, sondern
um einen Hash.

Und ich dachte im Betreff steht: Passwort verschlüsseln.
Wird hier java-Hash mit Hash-Algorithmus verwechselt?

Wenn Du den Thread verfolgt hast, weißt Du, daß empfohlen wurde, das Paßwort
gar nicht abzuspeichern, sondern nur einen Hashwert und so die
Authentifizierung zu ermöglichen. Ist meines Wissen der normale Weg.

Natürlich kann man zur Authentfifizierung auch Public-Key Verfahren
verwenden, aber das ist zumindest für eine Webanwendung doch etwas
umständlich. Für SSH usw. ist das aber der bessere Weg. Aber auch bei diesem
Verfahren wir das Paßwort nicht wirklich verschlüsselt und auch nicht
gespeichert.

Gruß,

Daniel

[Andree Große]

Post by Daniel Urban
Wenn Du den Thread verfolgt hast,

Eben drum...

Post by Daniel Urban
weißt Du, daß empfohlen wurde, das
Paßwort gar nicht abzuspeichern, sondern nur einen Hashwert und so die
Authentifizierung zu ermöglichen. Ist meines Wissen der normale Weg.

Echt - wer sagt das denn? Paßwort eingeben, verschlüsseln,
verschlüsseltes Paßwort in die DB ablegen und nur noch verschlüsselte
Werte vergleichen.
A.G.

[Paul Ebermann]

Post by Andree Große

Post by Daniel Urban
Wenn Du den Thread verfolgt hast,

Eben drum...

Post by Daniel Urban
weißt Du, daß empfohlen wurde, das
Paßwort gar nicht abzuspeichern, sondern nur einen Hashwert und so die
Authentifizierung zu ermöglichen. Ist meines Wissen der normale Weg.

Echt - wer sagt das denn? Paßwort eingeben, verschlüsseln,
verschlüsseltes Paßwort in die DB ablegen und nur noch verschlüsselte
Werte vergleichen.

Und üblicherweise nimmt man hierfür nicht eine
"umkehrbare Verschlüsselung" (wo man also wieder
entschlüsseln kann), sondern eine "Einweg-
Verschlüsselung" - auch "Hashfunktion" genannt.

Und jetzt vergleiche bitte noch einmal deine
Aussage mit der von Daniel, und nenne die
signifikanten Unterschiede.


Paul

[Daniel Urban]

Post by Andree Große

Post by Daniel Urban
Wenn Du den Thread verfolgt hast,

Eben drum...

Post by Daniel Urban
weißt Du, daß empfohlen wurde, das
Paßwort gar nicht abzuspeichern, sondern nur einen Hashwert und so die
Authentifizierung zu ermöglichen. Ist meines Wissen der normale Weg.

Echt - wer sagt das denn? Paßwort eingeben, verschlüsseln,
verschlüsseltes Paßwort in die DB ablegen und nur noch verschlüsselte
Werte vergleichen.

Und wo kommt der Key für das ver- und entschlüsseln her? Und insbesondere
wie soll das bei einer Webanwendung funktionieren?

Gruß,

Daniel

[Paul Ebermann]

Post by Andree Große

Post by Paul Ebermann
Nein. ABC... war ein Prototyp eines Passwortes,
nicht dessen Verschlüsselung.
Und es geht hier nicht um Verschlüsselung, sondern
um einen Hash.

Und ich dachte im Betreff steht: Passwort verschlüsseln.

Ja, man sollte nicht nur den Betreff, sondern auch
den Text lesen.

Post by Andree Große
Wird hier java-Hash mit Hash-Algorithmus verwechselt?

Von mir nicht.


Paul

[Michael Borgwardt]

Post by Paul Ebermann

Post by Daniel Urban

Post by Paul Ebermann
Wenn einfach alle möglichen Passwörter durchprobiert
werden, muss man (wenn kein Nutzername dabei ist) nur
schauen, ob bei den x gespeicherten Hashs das Ergebnis
dabei ist.

Da ist kein Unterschied. Gleiches muß man auch tun, wenn der
Nutzername drin ist.

Da sind es aber mehr.

Nein, weil das Ziel nicht ist, wirklich das Paßwort zu finden,
das der Nutzer tatsächlich hat, sondern irgendeines mit dem
gleichen Hashwert. Und wenn man das brute force macht, dann
ist völlig egal wie lang oder kompliziert das eche Paßwort ist,
das hat auf den zu erwartenden Rechenaufwand keinerlei Einfluß.

[Daniel Urban]

Post by Paul Ebermann

Post by Daniel Urban

Post by Paul Ebermann
Wenn einfach alle möglichen Passwörter durchprobiert
werden, muss man (wenn kein Nutzername dabei ist) nur
schauen, ob bei den x gespeicherten Hashs das Ergebnis
dabei ist.

Da ist kein Unterschied. Gleiches muß man auch tun, wenn der
Nutzername drin ist.

Da sind es aber mehr.

Mmm, Du bist doch Mathematiker, oder? Ich will Dir deswegen nicht
widersprechen. ;-)

Aber ich habe auch noch einmal nachgedacht und bin zu einer Erkenntnis
gekommen, die hoffentlich nicht falsch ist. ;-)

a) Wenn ich einen konkreten Account knacken will:

password = username + phrase --> wenn username bekannt ist und a die Länge
des Alphabets, dann ist der Aufwand a ^ length(phrase)

Wobei je nach Hashwertfunktion, es natürlich auch sein kann, daß kürzere
Paßworte ebenfalls den gesuchten Hashwert erzeugen können. Den Fall würde
ich aber aus meiner Betrachtung erst mal ausschließen.

Daraus folgt für mich, daß sowohl bei BF als auch bei DA kein Unterschied
besteht zwischen mit und ohne Benutzername.

b) Wenn ich alle Accounts knacken will:

- mit Nutzernamen:

Der Gesamtaufwand ist die Summe der einzelnen Aufwände wie oben, also
a^length(phrase1) + a^length(phrase2)+...+a^length(phraseN), wenn man die
zusätzlich Information nutzt.

Oder wenn man die Information nicht nutzt: a^(passwordMax), wobei
passwordMax das Password mit der größten Länge unter den Nutzern ist.

- ohne Nutzernamen (password = phrase):

Der Gesamtaufwand beträgt a^(phraseMax), wobei phraseMax die größte Länger
hat unter den Nutzern.

Daraus folgt (für Nutzeranzahl > 1), daß durch die Verlängerung des
Paßwortes - wie Du sagtest - der Aufwand höher wird.

Außer Acht lasse ich dabei, daß es auch möglich wäre, daß zwei verschiedene
Paßwörter auf den gleichen Hashwert abgebildet werden. Also das ich beim
erraten des ersten Paßwortes zufällig das zweite errate. Was aber unabhängig
von der Verwendung des Nutzernamens ist.

c) Wenn ich einen beliebigen Account knacken will:

- ohne Nutzername (password = phrase):

Der Aufwand ist a^length(passwordMin), wobei passwordMin das kürzeste
Paßwort von allen Nutzern ist.

- mit Nutzername:

Im Besten Fall ist es a^length(phraseMin) und im schlechtesten Fall
a^length(phraseMax). Leider weiß man nicht, welche Nutzer das kürzeste
Paßwort hat. Der Hashwert sollte darüber keinen Aufschluß geben.

Wenn man die Information nicht nutzt, dann ist der Aufwand
a^length(passwordMin).

In der Regel wird der Aufwand also größer sein.

Außer Acht lasse ich auch hier, daß es auch möglich wäre, daß zwei
verschiedene Paßwörter auf den gleichen Hashwert abgebildet werden.

Also 2:1 für Dich. ;-)

Gruß,

Daniel

[Andree Große]

Post by Daniel Urban
...
password = username + phrase --> wenn username bekannt ist und a die
Länge des Alphabets, dann ist der Aufwand a ^ length(phrase)

Und die ganzen Sonderzeichen?...
Irgendwie hilft das alles nicht dabei, ein Passwort zu verschlüsseln,
was eigentlich ganz einfach ist.

A.G.

[Daniel Urban]

Post by Andree Große

Post by Daniel Urban
...
password = username + phrase --> wenn username bekannt ist und a die
Länge des Alphabets, dann ist der Aufwand a ^ length(phrase)

Und die ganzen Sonderzeichen?...
Irgendwie hilft das alles nicht dabei, ein Passwort zu verschlüsseln,
was eigentlich ganz einfach ist.

Wir reden hier über Hashwerte und nicht über Verschlüsseln. Und das tun wir
mit gutem Grund, denn es gibt keinen Grund, das Paßwort zu verschlüsseln,
wie einige hier schon geschrieben haben.

Gruß,

Daniel

[Andree Große]

Post by Daniel Urban
Wir reden hier über Hashwerte und nicht über Verschlüsseln.

Ist mir nicht entgangen.

Post by Daniel Urban
Und das tun
wir mit gutem Grund, denn es gibt keinen Grund, das Paßwort zu
verschlüsseln,

Für diejenigen mag das zutreffen. Für andere gibt es
1000 Gründe, ein Paßwort zu verschlüsseln - und das ist gut so.

A.G.

[Paul Ebermann]

Post by Andree Große

Post by Daniel Urban
password = username + phrase --> wenn username bekannt ist und a die
Länge des Alphabets, dann ist der Aufwand a ^ length(phrase)

Und die ganzen Sonderzeichen?...

In der Kryptologie (bzw. allgemein in der
theoretischen Informatik) steht "Alphabet" einfach
für "Menge aller erlaubten Zeichen".

Die "Sonderzeichen" sind da also mit drin.

Post by Andree Große
Irgendwie hilft das alles nicht dabei, ein Passwort zu verschlüsseln,
was eigentlich ganz einfach ist.

Lass dich nicht vom Subject verwirren.


Paul

[Paul Ebermann]

Post by Daniel Urban

Post by Paul Ebermann

Post by Daniel Urban

Post by Paul Ebermann
Wenn einfach alle möglichen Passwörter durchprobiert
werden, muss man (wenn kein Nutzername dabei ist) nur
schauen, ob bei den x gespeicherten Hashs das Ergebnis
dabei ist.

Da ist kein Unterschied. Gleiches muß man auch tun, wenn der
Nutzername drin ist.

Da sind es aber mehr.

Mmm, Du bist doch Mathematiker, oder? Ich will Dir deswegen nicht
widersprechen. ;-)

Nur keine Scheu :-)
Mathematiker können (entgegen der landläufigen Meinung)
nicht rechnen.

Post by Daniel Urban
Aber ich habe auch noch einmal nachgedacht und bin zu einer Erkenntnis
gekommen, die hoffentlich nicht falsch ist. ;-)

Ich glaube, diese Fallunterscheidung ist bei dieser
Diskussion wirklich hilfreich.

Post by Daniel Urban
password = username + phrase

Nur zur Klarstellung: Eingeben muss der Nutzer
trotzdem den username und phrase einzeln, username
muss existieren, und hash(password) = tabelle[username]
wird überprüft.

Post by Daniel Urban
--> wenn username bekannt ist und a die Länge
des Alphabets, dann ist der Aufwand a ^ length(phrase)

(Wenn wir annehmen, dass das Berechnen eines Hashs
konstante Zeit braucht - ansonsten ist es geringfügig
länger.)

Post by Daniel Urban
Wobei je nach Hashwertfunktion, es natürlich auch sein kann, daß kürzere
Paßworte ebenfalls den gesuchten Hashwert erzeugen können. Den Fall würde
ich aber aus meiner Betrachtung erst mal ausschließen.
Daraus folgt für mich, daß sowohl bei BF als auch bei DA kein Unterschied
besteht zwischen mit und ohne Benutzername.

Ja. (Bis auf die leicht aufwendigere Berechnung des
Hashs durch den längeren String ...)

Post by Daniel Urban
Der Gesamtaufwand ist die Summe der einzelnen Aufwände wie oben, also
a^length(phrase1) + a^length(phrase2)+...+a^length(phraseN), wenn man die
zusätzlich Information nutzt.

Also O(N*phraseMax).

Post by Daniel Urban
Oder wenn man die Information nicht nutzt: a^(passwordMax), wobei
passwordMax das Password mit der größten Länge unter den Nutzern ist.

Unter "zusätzliche Information" verstehe ich
"der Hash wird aus user + phrase gebildet".
Richtig?

Ohne diese Info kommt man nicht weit, denn eingegeben
wird ja am Ende doch phrase einzeln. Wenn ich
statt "ABCDE" das geknackte "ePaul:ABCDE" eingebe, bekomme
ich ja keinen Zugang. (Oder ich muss doch einen Menschen
ransetzen, der auf die Idee kommt.)

Post by Daniel Urban
Der Gesamtaufwand beträgt a^(phraseMax), wobei phraseMax die größte Länger
hat unter den Nutzern.
Daraus folgt (für Nutzeranzahl > 1), daß durch die Verlängerung des
Paßwortes - wie Du sagtest - der Aufwand höher wird.
Außer Acht lasse ich dabei, daß es auch möglich wäre, daß zwei verschiedene
Paßwörter auf den gleichen Hashwert abgebildet werden. Also das ich beim
erraten des ersten Paßwortes zufällig das zweite errate. Was aber unabhängig
von der Verwendung des Nutzernamens ist.

Wenn man alle knacken will, hilft das ja nicht - man muss ja
doch durchprobieren, bis man das letzte hat.

Post by Daniel Urban
Der Aufwand ist a^length(passwordMin), wobei passwordMin das kürzeste
Paßwort von allen Nutzern ist.

Wenn viele Leute ähnlich lange Passwörter haben (und wir
einen "Randomized Brute Force"-Ansatz machen), könntest
du es noch durch die Anzahl dieser Nutzer teilen.

Post by Daniel Urban
Im Besten Fall ist es a^length(phraseMin) und im schlechtesten Fall
a^length(phraseMax). Leider weiß man nicht, welche Nutzer das kürzeste
Paßwort hat. Der Hashwert sollte darüber keinen Aufschluß geben.

Man kann N*a^length(phraseMin) als Abschätzung nehmen, wenn
man jedes Passwort mit jedem Nutzernamen ausprobiert.

Ob das besser ist, hängt von N ab.


Paul

[Michael Borgwardt]

Post by Daniel Urban

Post by Harald Vogt
Der Benutzername im Hashwert erschwert die Sache dahingehend, dass diese
Vorgang für jeden Benutzer separat durchgeführt werden muss. Einmal alle
Hashwerte für alle Benutzer berechnen reicht dann also nicht.

Das mag in der Praxis bei schlechter Paßwortwahl richtig sein.

Nur dann hat eine Dictionary-Attacke Aussicht auf Erfolg.

[Stefan Matthias Aust]

Post by Harald Vogt
Auch wieder wahr. - Und die dictionary-Attacke sollte ja durch die
Aufnahme des Benutzernamens in die Hashberechnung auch schon ausreichend
erschwert sein.

Kein Stück. Den wird man ja wohl immer wissen, da er nicht geheim ist.
Ein typisches Kennwort von 6-8 Zeichen Länge hat AFAIK übrigens einen
Informationsgehalt von 30-40 bits, sowas lässt sich möglicherweise in
vertretbarer Zeit durchrechnen, wenn es darauf ankommt.

Besser wäre es, längere Passphrases zu verwenden, etwa: "Das Pferd, es
lebte, doch das Kind war tot!" oder so ähnlich. Aber welcher Benutzer
mag das schon eingeben.

Zu dem Problem des OP: Wenn er Daten, wie z.B. Kennworte, die in externe
Systeme gesteckt werden sollen, schützen will, müssen Sie verschlüsselt
werden. In diesem Fall würde man eher ein symetrisches Verfahren
wählen. XOR N wäre so ein Verfahren - aber ein ziemlich schlechtes.
ROT13 ein anderes (für Buchstaben), noch schlechter. Besser ist es,
eines des kryptographisch anspruchsvolleneren Verfahren zu benutzen,
etwa AES, was im JRE enthalten ist. Das Stichwort ist

java.crypto.Cipher.


Wenn es darum geht, die Gültigkeit eines Kenntworts zu prüfen, muss man
dieses nicht direkt ablegen, sondern nur etwas, zu dem das Kennwort
gemacht werden kann, aus dem das Kennwort aber nicht (oder nur sehr
schwer) ermittelt werden kann. Das sind dann sogenannte Key Derivation
Functions, die ein Kennwort und etwas Salz (eine Zufallszahl) zu einer
Bytefolge verarbeiten. PKCS#5 beschreibt zwei solche Funktionen. Unix
crypt funktioniert AFAIK nach dem selben Prinzip.

Java selbst hat glaube ich den Algorithmus nicht, aber da gibt es was
von BouncyCastle. Jedenfalls gibt es dort ein PKCS5S2 Schema als Algorithm.


bye

[Harald Vogt]

Post by Stefan Matthias Aust

Post by Harald Vogt
Auch wieder wahr. - Und die dictionary-Attacke sollte ja durch die
Aufnahme des Benutzernamens in die Hashberechnung auch schon
ausreichend erschwert sein.

Kein Stück. Den wird man ja wohl immer wissen, da er nicht geheim ist.
Ein typisches Kennwort von 6-8 Zeichen Länge hat AFAIK übrigens einen
Informationsgehalt von 30-40 bits, sowas lässt sich möglicherweise in
vertretbarer Zeit durchrechnen, wenn es darauf ankommt.

Zumindest wird so die _Vorausberechnung_ von Hashwerten möglicher
Passwörter erschwert. Der Benutzernamen hat dabei die gleiche Funktion
wie das "Salz", das ja auch öffentlich zugänglich abgelegt wird.

[Andree Große]

Post by Stefan Matthias Aust
Wenn es darum geht, die Gültigkeit eines Kenntworts zu prüfen, muss man
dieses nicht direkt ablegen, sondern nur etwas, zu dem das Kennwort
gemacht werden kann,...

Man vergleicht einfach die verschlüsselten Werte - wo ist das Problem?
A.G.

[Daniel Urban]

Post by Harald Vogt

Post by Bodo Wippermann
Wenn Du keine besonderen Anforderungen hast, sieh dir mal das

Mit diesem Algorithmus wird das Passwort nicht wirklich verschlüsselt,
sondern es wird ein Hash gebildet, der aber ebenso gut ist, weil man das
ursprüngliche Passwort nicht daraus errechnen kann.
Ein Problem ist, dass zwei gleiche Passwörter auch den gleichen Hashwert
bekommen.

Wo ist da das Problem? Die Wahrscheinlichkeit, daß Du ein Paßwort kennst,
welches den Hashcode erzeugt, sollte sich damit nicht erhöhen.

Post by Harald Vogt
Man sollte also z.B. noch den Benutzernamen mit in die
md.update(username.getBytes());

Encoding nicht vergessen, man weiß ja nie, ob man nicht auf einem
chinesischen Rechner ist. ;-)

Gruß,

Daniel

[Harald Vogt]

Post by Daniel Urban

Post by Harald Vogt
Ein Problem ist, dass zwei gleiche Passwörter auch den gleichen Hashwert
bekommen.

Wo ist da das Problem? Die Wahrscheinlichkeit, daß Du ein Paßwort kennst,
welches den Hashcode erzeugt, sollte sich damit nicht erhöhen.

Ist ja vielleicht nicht wirklich ein Problem, aber wenn es zwei Benutzer
gibt, die zufällig das gleiche Passwort auswählen (ist natürlich nur
wahrscheinlich, wenn sehr einfache Wörter gewählt werden), dann bekommen
beide eben auch den gleichen Hash zugeordnet.

[Daniel Urban]

Post by Harald Vogt

Post by Daniel Urban
Wo ist da das Problem? Die Wahrscheinlichkeit, daß Du ein Paßwort kennst,
welches den Hashcode erzeugt, sollte sich damit nicht erhöhen.

Ist ja vielleicht nicht wirklich ein Problem, aber wenn es zwei Benutzer
gibt, die zufällig das gleiche Passwort auswählen (ist natürlich nur
wahrscheinlich, wenn sehr einfache Wörter gewählt werden), dann bekommen
beide eben auch den gleichen Hash zugeordnet.

Das hilft Dir aber eigentlich gar nichts, es sei denn, Du bist einer der
beiden. Aber auch dann kannst Du nicht sicher sein, denn zwei Paßwörter
können natürlich den gleichen Hashwert erzeugen.

Gruß,

Daniel

[Paul Ebermann]

Post by Daniel Urban

Post by Harald Vogt

Post by Daniel Urban
Wo ist da das Problem? Die Wahrscheinlichkeit, daß Du ein
Paßwort kennst, welches den Hashcode erzeugt, sollte sich
damit nicht erhöhen.

Ist ja vielleicht nicht wirklich ein Problem, aber wenn es zwei Benutzer
gibt, die zufällig das gleiche Passwort auswählen (ist natürlich nur
wahrscheinlich, wenn sehr einfache Wörter gewählt werden), dann bekommen
beide eben auch den gleichen Hash zugeordnet.

Das hilft Dir aber eigentlich gar nichts, es sei denn, Du bist einer der
beiden.

Wenn man das als Außenstehender beobachtet, kann es ausreichend
sein, sein "social engineering" nur auf den anfälligeren von beiden
anzuwenden, um den Account des anderen zu knacken.

(Bei unserer letzten Fachschaftsfahrt hatten in dem
Haus, in dem wir übernachteten, immer zwei Zimmer
identische Schlüssel. Sobald man raushatte, wer das
war, konnte man in das Zimmer der anderen - oder
umgekehrt, man suchte jemanden aus dem anderen Zimmer,
um in sein eigenes reinzukommen, wenn der eigene
Schlüsselinhaber abhandengekommen ist ...)

Post by Daniel Urban
Aber auch dann kannst Du nicht sicher sein, denn zwei Paßwörter
können natürlich den gleichen Hashwert erzeugen.

Macht ja nichts. Wenn man ein falsches Passwort eingibt,
welches den selben Hash hat, hat man ja trotzdem Zugang.

(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)


Paul

[Daniel Urban]

Post by Paul Ebermann

Post by Daniel Urban
Aber auch dann kannst Du nicht sicher sein, denn zwei Paßwörter
können natürlich den gleichen Hashwert erzeugen.

Macht ja nichts. Wenn man ein falsches Passwort eingibt,
welches den selben Hash hat, hat man ja trotzdem Zugang.
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen. Um das
Paßwort nicht mitzuhören, muß man dann die Leitung komplett verschlüsseln,
also zum Beispiel HTTPS verwenden. Zumindest habe ich das so in Erinnerung.

Gruß,

Daniel

[Bernd Eckenfels]

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen.

Bei HTTP Basic Auth wird kein hash gesendet sondern das encodierte plain
passwort. Bei Challenge Response Verfahren werden hashes der challenge
geschickt, hier hat also das abhören keine Wirkung.

Gruss
Bernd

[Daniel Urban]

Post by Bernd Eckenfels

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen.

Bei HTTP Basic Auth wird kein hash gesendet sondern das encodierte plain
passwort.

So hatte ich es auch in Erinnerung.

Post by Bernd Eckenfels
Bei Challenge Response Verfahren werden hashes der challenge
geschickt, hier hat also das abhören keine Wirkung.

Was ist das und wie funktioniert es?

Gruß,

Daniel

[Paul Ebermann]

Post by Daniel Urban

Post by Bernd Eckenfels

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint
mir wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann
erst auf der Empfängerseite den Hashcode zu erzeugen und dann zu
vergleichen.

Bei HTTP Basic Auth wird kein hash gesendet sondern das encodierte plain
passwort.

So hatte ich es auch in Erinnerung.

Post by Bernd Eckenfels
Bei Challenge Response Verfahren werden hashes der challenge
geschickt, hier hat also das abhören keine Wirkung.

Was ist das und wie funktioniert es?

HTTP Digest Auth habe ich ja in einem anderen Artikel gerade
erläutert.

Generell läuft "Challenge Response" so ab (Client
will sich beim Server authentifizieren):

Beide haben ein gemeinsames Geheimnis X.

Server
|
wählt (nach irgend
einem Prinzip) C
|
+-----------------[ C ]----> Client
| |
V V
algo(X,C) algo(X,C)
| |
[rS] [rC]
| |
V |
[Vergleich] <---------------------/

Der Algorithmus sollte so beschaffen sein,
dass man aus C und dem Ergebnis nicht leicht
auf X schließen kann, und dass man aus C
(ohne X) nicht leicht auf das Ergebnis
schließen kann.

Ein kryptographisch guter Hash mit
vorgeschaltetem concat tut das.

(Eventuell wird das ganze mehrfach iteriert,
um "gut geraten" auszuschließen.)


Paul

[Axel Bock]

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen. Um das
Paßwort nicht mitzuhören, muß man dann die Leitung komplett verschlüsseln,
also zum Beispiel HTTPS verwenden. Zumindest habe ich das so in Erinnerung.

das verlagert das Problem nur. Was du brauchst ist eine vertrauenswürdige
Gegenstelle. Hast du die nicht, dann kann der Lauscher das PW im Klartext
mitschnüffeln - unerwünscht. Oder er kann bei einer Verschlüsselung sich
trotzdem in die Mitte schalten. Effekt: Leitung zwar verschlüsselt, aber nicht
mit dem guten Bob direkt, sondern über Alice :-)

gewünscht:
1. (du) -----> challenge (Bob)
2. (du) <----- response (Bob)
3. (du) <-----> Verbindung (Bob)

ohne Zertifikate einfach (!) möglich:

1. (du) -----> challenge [ Alice ]
2. (du) <----- response [ Alice ]
3. (du) <-----> Verbindung [ Alice ] challenge -------> (Bob)
4. (du) <-----> Verbindung [ Alice ] response <------- (Bob)
5. (du) <-----> Verbindung [ Alice ] Verbindung <------> (Bob)

wenn du jetzt Daten schickst, dann kann Alice die einfach durchleiten, aber
auch alles lesen - denn die Verbindung (obwohl verschlüsselt) geht von dir zu
Alice, und eine komplett andere Verbindung von Alice zu Bob. Du MUSST also der
Gegenstelle vertrauen können - ist das wirklich Bob? (Stichwort Zertifikat
bzw. Public Key Krypto)

böse: Datum [X], Schlüssel s1, s2

1. (du) : [Y]=crypt([X], s1) --> [Alice]
2. [Alice]: [X]=decrypt(Y, s1)
3. [Alice] liest [X] und ist happy
4. [Alice]: [Z]=crypt([X], s2) --> (Bob)
5. (Bob) : [X]=decrypt([Z], s2)
3. (Bob) liest [X] und merkt nicht, dass Alice ihn schon kennt

Und wenn du also eine verschlüsselte Verbindung zu Bob hast, dann ist es total
egal, ob du plain test oder Has sendest - wer den hash berechnet ist dann
wirklich schnuppe :-) . Wieder Voraussetzung: Vertrauen zur Gegenstelle.

So. Schön dass ich auch mal was *antworten* konnte in der Newsgroup - obwohl
es wohl off topic ist :)))


Grüße,

Axel.

[Bernd Eckenfels]

Post by Axel Bock
trotzdem in die Mitte schalten. Effekt: Leitung zwar verschlüsselt, aber nicht
mit dem guten Bob direkt, sondern über Alice :-)

Nur der Vollstaendigkeit halber heisst Alice Mallory bei einem MITM und Eve
bei einem Lauschangriff:

Alice (usually the protocol initiator)
Bob, Alice.s friend
Eve the eavesdropper
Mallory the malicious adversary
Trent the trusted serverAlice (usually the protocol initiator)

Gruss
Bernd

[Daniel Urban]

Post by Axel Bock

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen. Um das
Paßwort nicht mitzuhören, muß man dann die Leitung komplett verschlüsseln,
also zum Beispiel HTTPS verwenden. Zumindest habe ich das so in Erinnerung.

das verlagert das Problem nur. Was du brauchst ist eine vertrauenswürdige
Gegenstelle.

Nett, daß Du es noch einmal erklärt hast. Auch den Man-in-the-Middle
Angriff. ;-) Aber wenn ich sage, daß man HTTPS (SSL, TSL) braucht, dann
gehört natürlich dazu, daß man der Gegenseite traut. Ich hatte das nicht
extra erwähnt, weil es AFAIK zu HTTPS dazugehört, auch wenn man damit im
Regelfall sehr leichtfertig umgeht.

Post by Axel Bock
Und wenn du also eine verschlüsselte Verbindung zu Bob hast, dann ist es total
egal, ob du plain test oder Has sendest - wer den hash berechnet ist dann
wirklich schnuppe :-) . Wieder Voraussetzung: Vertrauen zur Gegenstelle.

Im Grunde richtig, aber die Sicht ist etwas isoliert. Wenn ich an die
gehshten Paßwörter rankommen, kann ich so ohne das Paßwort zu kennen, den
Account knacken. Im anderen Fall, wenn also plain gesendet wird, ist demn
nicht so. Soll heißen, daß theoretisch die gehashten Paßwörter für jeden
lesbar gespeichert sein dürften.

Gruß,

Daniel

[Axel Bock]

Post by Daniel Urban
Im Grunde richtig, aber die Sicht ist etwas isoliert. Wenn ich an die
gehshten Paßwörter rankommen, kann ich so ohne das Paßwort zu kennen, den
Account knacken. Im anderen Fall, wenn also plain gesendet wird, ist demn
nicht so. Soll heißen, daß theoretisch die gehashten Paßwörter für jeden
lesbar gespeichert sein dürften.

öh. ah, versteh ich grad nicht. wenn du an die hash-passwörter rankommst dann
kannst du den account knacken, brute force oder was auch immer. wenn du an die
klartextpasswörter rankommst, dann *hast* du ihn doch geknackt, oder??


Ciao,

Axel.

[Daniel Urban]

Post by Axel Bock

Post by Daniel Urban
Im Grunde richtig, aber die Sicht ist etwas isoliert. Wenn ich an die
gehshten Paßwörter rankommen, kann ich so ohne das Paßwort zu kennen, den
Account knacken. Im anderen Fall, wenn also plain gesendet wird, ist demn
nicht so. Soll heißen, daß theoretisch die gehashten Paßwörter für jeden
lesbar gespeichert sein dürften.

öh. ah, versteh ich grad nicht. wenn du an die hash-passwörter rankommst dann
kannst du den account knacken, brute force oder was auch immer. wenn du an die
klartextpasswörter rankommst, dann *hast* du ihn doch geknackt, oder??

An den Klartext darfst Du nie rankommen, weil Du dann natürlich den Account
geknackt hast. Ich habe nichts anderes gesagt. Aber wenn Du den Hashwert
kennst, hast Du den Account noch lange nicht geknackt. Und daher kannst Du
den HAshwert theoretisch auch offen speichern. Mal abgesehen von der
Problematik, daß viele Nutzer leider keine guten Paßwörter haben und die
Dictionary-Attacke greift.

Gruß,

Daniel

[Andree Große]

... Man muß das Paßwort schon plain senden, um dann erst auf
der Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen.

Wie bitte? Paßwort verschlüsseln (zum Bleistift mit JCrypt),
dann über SSL versenden und beim Server mit dem hinterlegten
verschlüsselten Wert vergleichen - fertich...

Paßwörter vergleicht man grundsätzlich verschlüsselt. Jede Form
der Rückübersetzung ist grob fahrlässig und dazu absoluter Unfug.
Sowas macht nur WinzichWeich.

A.G.

[Bernd Eckenfels]

Post by Andree Große
Paßwörter vergleicht man grundsätzlich verschlüsselt. Jede Form
der Rückübersetzung ist grob fahrlässig und dazu absoluter Unfug.
Sowas macht nur WinzichWeich.

Besser ist es natuerlich das Passwort garnicht zu versenden. Z.b. mit SRP.

Gruss
Bernd

[Andree Große]

Post by Bernd Eckenfels
Besser ist es natuerlich das Passwort garnicht zu versenden. Z.b. mit SRP.

Wie melde ich mich dann bei einer WebApp an? Mein Account wurde
genau dort in der DB abgelegt.

A.G.

[Bernd Eckenfels]

Post by Andree Große
Wie melde ich mich dann bei einer WebApp an? Mein Account wurde
genau dort in der DB abgelegt.

Bei ner webapp mit form oder basic authentication geht das natuerlich nicht.
aber da kann man auch kein passwort hash uebertragen (wenn man mal von
irgendwelchen javascript schweinereien absieht)

Gruss
Bernd

[Andree Große]

Post by Bernd Eckenfels
Bei ner webapp mit form oder basic authentication geht das natuerlich nicht.

Hallo - davon war keine Rede. Die WebApp meldet den User an der DB an,
wie ich erwähnte.

Post by Bernd Eckenfels
aber da kann man auch kein passwort hash uebertragen (wenn man mal
von irgendwelchen javascript schweinereien absieht)

Was soll Javascript hier? Und ich will gar kein Hash übertragen,
sondern ein verschlüsseltes Paßwort, das wiederum über SSL
versandt wird.

A.G.

[Daniel Urban]

Post by Andree Große

... Man muß das Paßwort schon plain senden, um dann erst auf
der Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen.

Wie bitte? Paßwort verschlüsseln (zum Bleistift mit JCrypt),
dann über SSL versenden und beim Server mit dem hinterlegten
verschlüsselten Wert vergleichen - fertich...

Quark, mit SSL verschlüsselst Du den Kanal. dann brauchst Du das Paßwort
nicht verschlüsseln.

Post by Andree Große
Paßwörter vergleicht man grundsätzlich verschlüsselt. Jede Form
der Rückübersetzung ist grob fahrlässig und dazu absoluter Unfug.
Sowas macht nur WinzichWeich.

Du verschlüsselst nicht, sondern bildest den Hashwert, welchen Du
vergleichst. So läuft es zum Beispiel bei HTTP-Basisc.

Gruß,

Daniel

[Bernd Eckenfels]

Post by Daniel Urban
Du verschlüsselst nicht, sondern bildest den Hashwert, welchen Du
vergleichst. So läuft es zum Beispiel bei HTTP-Basisc.

Nein. Basic-Auth sendet username und passwort im "klartext".

Gruss
Bernd

[Daniel Urban]

Post by Bernd Eckenfels

Post by Daniel Urban
Du verschlüsselst nicht, sondern bildest den Hashwert, welchen Du
vergleichst. So läuft es zum Beispiel bei HTTP-Basisc.

Nein. Basic-Auth sendet username und passwort im "klartext".

Ich habe nichts anderes gesagt. Aber der Hashwert wird trotzdem gebildet
(auf der Serverseite).

Gruß,

Daniel

[Paul Ebermann]

[...]

Post by Daniel Urban

Post by Paul Ebermann
(Deswegen schützt eine reine Übertragung des
Hashs (wie bei HTTP Digest Authentication) auch gar
nicht vor einer Atacke durch abhören - man kann ja
einfach den abgehörten Hash verwenden, ohne das
Original-Passwort zu kennen.)

(War ein bisschen vom Thema abschweifend - deswegen
Subject geändert.)

Post by Daniel Urban
Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen. Um das
Paßwort nicht mitzuhören, muß man dann die Leitung komplett verschlüsseln,
also zum Beispiel HTTPS verwenden. Zumindest habe ich das so in Erinnerung.

Ich habe das gerade noch mal nachgelesen ...

http://www.rfc.net/rfc2617.html#s3.1

Es steht explizit drin, dass das nicht sicher ist -
aber etwas besser als Plain Auth.

Es wird (auf Client-Seite) ein Hash aus Username, Passwort,
der HTTP-Methode (GET, POST, PUT, etc.), der URI und - wichtig -
einem sogenanten nonce-Wert, welcher vom Server geschickt
wurde. (Außer dem Passwort wird alles auch noch im Klartext
zum Server geschickt.)


Der Server kann selbst entscheiden, wie oft er den selben
nonce-Wert akzeptiert - zwischen "einmal", "nur für diese eine
URI beliebig oft", "bis zum Ablaufen einer Zeitspanne", ...
gibt es da viele Möglichkeiten.

Wenn er es häufiger akzeptiert (und eventuell auch für
verschiedene URIs), gibt es die von mir genannte Gefahr,
ansonsten nicht.


Paul

[Daniel Urban]

Post by Paul Ebermann

Post by Daniel Urban
Ist das wirklich so? Ich kenne das Verfahren nicht, aber das scheint mir
wenig sinnvoll. Man muß das Paßwort schon plain senden, um dann erst auf der
Empfängerseite den Hashcode zu erzeugen und dann zu vergleichen. Um das
Paßwort nicht mitzuhören, muß man dann die Leitung komplett verschlüsseln,
also zum Beispiel HTTPS verwenden. Zumindest habe ich das so in Erinnerung.

Ich habe das gerade noch mal nachgelesen ...
http://www.rfc.net/rfc2617.html#s3.1
Es steht explizit drin, dass das nicht sicher ist -
aber etwas besser als Plain Auth.

Naja, unsicher, bleibt unsicher. ;-)

Post by Paul Ebermann
Es wird (auf Client-Seite) ein Hash aus Username, Passwort,
der HTTP-Methode (GET, POST, PUT, etc.), der URI und - wichtig -
einem sogenanten nonce-Wert, welcher vom Server geschickt
wurde. (Außer dem Passwort wird alles auch noch im Klartext
zum Server geschickt.)

Das ist jetzt Digest Acess Authentification. Wobei ich mich frage, wie der
Server den Vergleichswert erzeugt. Der Wert enthält doch sehr viele
dynamische Teile. Und der Server kennt das Paßwort doch nicht. Ich habe die
Spezifikation nicht gelesen und hoffe mal, daß Du mir die Antwort gibst. ;-)

Gegen MITM-Angriff schützt das aber auch nicht. Also muß man auch hier SSL
oder TSL verwenden.

Gruß,

Daniel

[Paul Ebermann]

Post by Daniel Urban

Post by Paul Ebermann
Ich habe das gerade noch mal nachgelesen ...
http://www.rfc.net/rfc2617.html#s3.1
Es steht explizit drin, dass das nicht sicher ist -
aber etwas besser als Plain Auth.

Naja, unsicher, bleibt unsicher. ;-)

Offen für bestimmte Angriffe heißt
nicht "offen für alle Angriffe".

Post by Daniel Urban

Post by Paul Ebermann
Es wird (auf Client-Seite) ein Hash aus Username, Passwort,
der HTTP-Methode (GET, POST, PUT, etc.), der URI und - wichtig -
einem sogenanten nonce-Wert, welcher vom Server geschickt
wurde. (Außer dem Passwort wird alles auch noch im Klartext
zum Server geschickt.)

Das ist jetzt Digest Acess Authentification. Wobei ich mich frage, wie der
Server den Vergleichswert erzeugt. Der Wert enthält doch sehr viele
dynamische Teile. Und der Server kennt das Paßwort doch nicht.

Doch. In dem Fall muss er das Passwort kennen.
Ist also ein komplett anderes System.

(Man könnte das Protokoll variieren, indem man statt dem
Passwort einen Hash des Passwortes eingehen lässt (und nur
der auf dem Server gespeichert ist) - das hilft aber auch
nicht viel weiter.)


Paul

[Bernd Eckenfels]

Post by Daniel Urban
Das ist jetzt Digest Acess Authentification. Wobei ich mich frage, wie der
Server den Vergleichswert erzeugt. Der Wert enthält doch sehr viele
dynamische Teile. Und der Server kennt das Paßwort doch nicht. Ich habe die
Spezifikation nicht gelesen und hoffe mal, daß Du mir die Antwort gibst. ;-)

Fuer ein challenge response verfahren (z.b. auch CHAP bei PPP) muss der
server das klartext passwort kennen. Das ist eine der größten Schwächen
dieser Verfahren. SRP löst dieses Problem.

Gruss
Bernd

[Tobias Schulte]

Post by Oliver Hirschi
Hi,
Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?
Thanxs.

Unter Linux werden Passwörter mit crypt verschlüsselt und dann abgelegt.
Google mal nach crypt in Verbindung mit java. Da gibt es ein paar
Implementierungen.

Tobias

[Andree Große]

Post by Tobias Schulte
Unter Linux werden Passwörter mit crypt verschlüsselt und dann abgelegt.
Google mal nach crypt in Verbindung mit java. Da gibt es ein paar
Implementierungen.

Nicht nur unter Linux - so ziemlich bei allen UNIX-Systemen.
Aber die wenigsten haben wohl schonmal eine /etc/passwd gesehen.
Endlich der richtige Weg für den OP.
A.G.

[Christoph Happich]

Post by Oliver Hirschi
Ich habe eine Client-Server-Applikation in Java geschrieben. Die
Anmeldung passiert über eine Useridentifikation per Username und
Passwort. Beides ist auf dem Server in einer DB-Tabelle abgelegt.
Nun sollten die Passwörter nicht in 'plain' in der datenbank abgelegt
werden, sonder verschlüsselt.
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

java.security (Antwort von Bodo). Dazu: Passwoerter muss man eigendlich
nie verschluesselt ablegen. Es reicht zu wissen ob das eingegebene
Passwort stimmt (ha ha) -- Wenn du also den Digest (MD5) ablegst, kannst
du den Digest des eingegebenen Passwoertes einfach damit vergleichen.
Aus dem Digest kann man aber das Orginalpasswort nicht herausrechnen.

Gruss, Christoph

[Andree Große]

Post by Christoph Happich
java.security (Antwort von Bodo). Dazu: Passwoerter muss man eigendlich
nie verschluesselt ablegen...

Bist du bei Microsoft für die Sicherheitslücken zuständig?
Wenn man ein Paßwort irgendwo ablegt - dann verschlüsselt.
A.G.

[Christian Hauser]

Post by Oliver Hirschi
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Einfach Verschlüsseln kannst du selbst. Das ist nicht schwierig. Das
bereits genannte Vorgehen mit einem Hashwert (über Username/Passwort),
der in der DB gespeichert wird ist klar vorzuziehen.

Aber du könntest auch eine kleine XOR oder Substitutionsverschlüsselung
selber schreiben. Das ist alles im Kapitel 47 des JavaBuchs von Guido
Krüger erwähnt: http://www.javabuch.de/

Hier der Link, falls du das JavaBuch nicht extra runterladen und
installieren willst:
http://dufo.tugraz.at/mirror/hjp3/k100294.html

Diese Seite würde ich an deiner Stelle unbedingt mal lesen.

Gruss,
Christian

[Harald Vogt]

Post by Christian Hauser

Post by Oliver Hirschi
Gibt es in der 'Java Standard Library' eine funktionalität um Strings
einfach zu verschlüsseln, oder gibt es sonst eine einfach/konstenlos zu
verwendende Lib?

Einfach Verschlüsseln kannst du selbst. Das ist nicht schwierig. Das
bereits genannte Vorgehen mit einem Hashwert (über Username/Passwort),
der in der DB gespeichert wird ist klar vorzuziehen.
Aber du könntest auch eine kleine XOR oder Substitutionsverschlüsselung
selber schreiben. Das ist alles im Kapitel 47 des JavaBuchs von Guido
Krüger erwähnt: http://www.javabuch.de/

Und wie dort selbst steht, sind solche XOR-Verschlüsselungen alles
andere als sicher:

"Derart einfache Verschlüsselungen wie die hier vorgestellten sind zwar
weit verbreitet, denn sie sind einfach zu implementieren. Leider bieten
sie aber nicht die geringste Sicherheit gegen ernsthafte
Krypto-Attacken. Einige der in letzter Zeit bekannt gewordenen (und für
die betroffenen Unternehmen meist peinlichen, wenn nicht gar
kostspieligen) Fälle von Einbrüchen in Softwaressysteme waren darauf
zurückzuführen, daß zu einfache Sicherheitssysteme verwendet wurden."

[Christian Hauser]

Post by Harald Vogt
Und wie dort selbst steht, sind solche XOR-Verschlüsselungen alles
"Derart einfache Verschlüsselungen wie die hier vorgestellten sind zwar
weit verbreitet, denn sie sind einfach zu implementieren. Leider bieten
sie aber nicht die geringste Sicherheit gegen ernsthafte
Krypto-Attacken. Einige der in letzter Zeit bekannt gewordenen (und für
die betroffenen Unternehmen meist peinlichen, wenn nicht gar
kostspieligen) Fälle von Einbrüchen in Softwaressysteme waren darauf
zurückzuführen, daß zu einfache Sicherheitssysteme verwendet wurden."

Logisch. Da muss man nicht mehr als 2 Minuten aufpassen im
Kryptologie-Unterricht, um das zu wissen.

Aber erwähnenswert ist es trotzdem, vielleicht hat er ja Kinder und für
die ist ein MD5/SHA Hash ein zu hoher Challenge... ;-)
Im Moment hat der OP ja einfach den Hexwert der einzelnen Buchstaben
gespeichert, da ist er mit einer Cäsar-Verschlüsselung definitiv schon
besser dran. ;-)

Gruss,
Christian

[Andree Große]

Post by Christian Hauser
Aber erwähnenswert ist es trotzdem, vielleicht hat er ja Kinder und für
die ist ein MD5/SHA Hash ein zu hoher Challenge... ;-)

Du solltest Sicherheitsberater werden.

Post by Christian Hauser
Im Moment hat der OP ja einfach den Hexwert der einzelnen Buchstaben
gespeichert, da ist er mit einer Cäsar-Verschlüsselung definitiv schon
besser dran. ;-)

Der heißt Julius Cäsar.
A.G.

String password = JCrypt.crypt("Ich bin dein Passwort");

[Michael Post]

Hallo Andree,

Post by Andree Große
String password = JCrypt.crypt("Ich bin dein Passwort");

Darf man fragen, was Du für eine Library für JCrypt nutzt?
Wo bekomme ich die her?

Wie man sie verwendet sehe ich ja oben ;-)
MFG

Michael

[Andree Große]

Post by Michael Post
Darf man fragen, was Du für eine Library für JCrypt nutzt?
Wo bekomme ich die her?

Ich hab mir JCrypt mal aus dem Netz gezogen. Das ist eine
Java-Implementierung des crypt-Algorithmus eines UNIX-Systems.

Post by Michael Post
Wie man sie verwendet sehe ich ja oben ;-)

Das ist aber nur der Teil, in dem das Passwort erzeugt wird.
Beim Vergleich braucht man noch einen Initialwert dazu. Aber
wenn du willst, kann ich dir diese Klasse und deren Benutzung
gerne zusenden.

A.G.

[Michael Post]

Hallo Andree,

Post by Andree Große
Das ist aber nur der Teil, in dem das Passwort erzeugt wird.
Beim Vergleich braucht man noch einen Initialwert dazu. Aber
wenn du willst, kann ich dir diese Klasse und deren Benutzung
gerne zusenden.

Das wäre sehr nett.
Vielen Dank schon einmal.

MFG

Michael