Passwordverschlüsselung

[Tinewww]

Hallo,
ich muß für ein Programm ein gesondertes Password abfragen und möchte dieses in einer Tabelle auf dem SQL-Server verschlüsselt speichern. Wenn die Tabelle direkt über den Enterprise Manager aufgerufen wird, sollen nur * oder so erscheinen!

Geht das? Oder wie programmiere ich es geschickter? :wiejetzt:

[Meflin]

Herzlich wilkommen in der DP :dp: :party:

Am geschicktesten machst du das indem du das Passwort nicht als solches abspeicherst sondern nur den Hash des Passworts (MD, SHA was immer). Bei der eingabe des Passworts erstellst du dann den Hash davon und überprüfst ob er mit dem Hashwert in der DB übereinstimmt.

Aus dem Hashwert kann das Passwort nicht rückberechnet werden. Somit kannst du das Passwort einigermaßen sicher in der DB ablegen!

[Tinewww]

Vielen Dank für den Hinweis! Hat prima funktioniert! :-D :-D :-D

Habe nur so lange gebraucht, ehe ich rausgefunden habe, wie das geht... :gruebel:

[freak4fun]

Diese Methode ist für Userverwaltungen eher ungeeignet, da man die Funktion "Passwort vergessen, bitte zuschicken!" nicht nutzen kann, da das PW, wie schon von Meflin gesagt, nicht wieder hergestellt werden kann. Das nur als kleinen Tip. ;)

MfG
freak

[mkinzler]

In diesem Fall kann man ja eine der gebräuchlichen Verschlüsselungsalgorithem verwenden: 3DES, AES...

[Tinewww]

Ist in diesem Fall nicht wichtig, weil es sich nur um einen sehr begrenzten Userkreis handelt. Es ging eher darum, dass eben niemand das PW ändern darf! (Auch keine ADMIN!)

[benst]

Ich würde MD5 nicht nehmen, weil MD5 nicht mehr sicher ist. Whirlpool oder RIPEMD-160 sind meiner Ansicht nach die bessere Wahl.
[edit]SHA-1 gestrichen.[/edit]

Zitat:

Diese Methode ist für Userverwaltungen eher ungeeignet, da man die Funktion "Passwort vergessen, bitte zuschicken!" nicht nutzen kann, da das PW, wie schon von Meflin gesagt, nicht wieder hergestellt werden kann.

Ich würde einfach eine andere Funktion nutzen: "Passwort vergessen, bitte neues zuschicken!"
Ben

[gsh]

Oder man bleibt beim Hash:

Wenn der User sein Passwort vergessen sollte dann wird ein neues ZufälligesPW erzeugt und von mir aus in einer anderen Tabelle abgespeichert. Dann wird des an seine email adresse geschickt und er hat 24h sich anzumelden bevor das neue PW seine gültigkeit verliert. Sobald er sich dann einloggt muss er ein neues PW angeben. Dies wird verhasht in der DB überschrieben und das zufällig erzeugt gelöscht.

Ja ich weiss des ist ein bisschen aufwändiger dafür aber viel sicherer (oder hab ich einen Denkfehler?)


//edit: @benst: Wieso ist MD5 nicht mehr sicher???

[mkinzler]

Zitat:

//edit: @benst: Wieso ist MD5 nicht mehr sicher???

Es ist möglich zu einem Hash ein Passwort zu generieren. BTW Sha-1 ist auch schon teilweise geknackt.

[benst]

Zitat:

Zitat von mkinzler

Zitat:

//edit: @benst: Wieso ist MD5 nicht mehr sicher???

Es ist möglich zu einem Hash ein Passwort zu generieren. BTW Sha-1 ist auch schon teilweise geknackt.

SHA-1: Stimmt, habe ich auch gerade gesehen.
(Was meinst du mit BTW?)
[edit]Ich Dummkopf: BTW: by the way[/edit]

[gsh]

Zitat:

Zitat von benst

(Was meinst du mit BTW?)

BTW = By The Way = Übrigens

[benst]

BTW: Ja, ist mir dann auch eingefallen (siehe mein edit).
@gsh: Ja, dein Lösungsvorschlag gefällt mir.

[Meflin]

Zitat:

Zitat von mkinzler

Es ist möglich zu einem Hash ein Passwort zu generieren. BTW Sha-1 ist auch schon teilweise geknackt.

geknackt? geknackt ist wohl wirklich nicht der richtige ausdruck... wenn man zufälligerweise per brute-force verfahren einen input findet der einen äquivalenten hash-output erzeugt, dann ist das verfahren nicht geknackt :wall: das geht natürlich bei JEDEM hashverfahren allerdings auch bei md5 wohl kaum in akzeptablem zeitaufwand :roll:

[mkinzler]

Hash-Funktion SHA-1 in Bedrängnis

[Meflin]

Zitat:

Zitat von mkinzler

Hash-Funktion SHA-1 in Bedrängnis

und wo ist das problem? nimmt man eben 256 oder mehr bit... ist ja nicht so als könnte man aus jedem sha-hash einen originalwert berechnen :roll:

[mkinzler]

Zitat:

ist ja nicht so als könnte man aus jedem sha-hash einen originalwert berechnen Rolling Eyes

Hab ich auch nicht behauptet.

[Meflin]

Zitat:

Zitat von mkinzler

Hab ich auch nicht behauptet.

Dann ist das Verfahren auch nicht geknackt. Übrigens ist es hier nicht verboten, Beiträge zu schreiben, die auch länger als eine Zeile sind :shock:

Desweiteren ist der Artikel Heise-typsich: man verstecke eine einigermaßen potentiell-tolle Nachricht unter einer reiserischen Überschrift und kläre dann im Artikel dass es eigentlich garnicht so schlimm sei... :roll:

[mkinzler]

Natürlich kenn amn auch längere Beiträge schreiben. Muß man aber nicht, wenn man in einem satz alles asgen kann, was man will.
Ich hatte ja geschrieben halb geknackt, da es noch nicht möglich ist einen kompletten Alternativtext mit identischen Hash zu erzeugen. Erfahrungsgemäß dauert es aber nicht mehr lange, bis die Angriffsmethoden verfeinert werden und dann effektivere Angriffe möglich werden. Längere Hashlängen bringen übrigens bei Passwörtern nicht so viel. (256Bit->32Zeichen)

[benst]

Zitat:

Zitat von Meflin

geknackt? geknackt ist wohl wirklich nicht der richtige ausdruck... wenn man zufälligerweise per brute-force verfahren einen input findet der einen äquivalenten hash-output erzeugt, dann ist das verfahren nicht geknackt :wall: das geht natürlich bei JEDEM hashverfahren allerdings auch bei md5 wohl kaum in akzeptablem zeitaufwand :roll:

Ich meine mich daran erinnern zu können, dass man irgendwo (ist schon etwas her) diverse (ich glaube, Hashwerte von Zeichenketten der Länge 6 oder so) MD5-Hashwerte herunterladen bzw. auf CDs kaufen konnte. Das waren ganz schön viele CDs, nach Hashwerten sortiert -> konnte man dann aus dem Hashwert, "ein Passwort" (ist ja redudant) bestimmen.

[Meflin]

Zitat:

Zitat von benst

Ich meine mich daran erinnern zu können, dass man irgendwo (ist schon etwas her) diverse (ich glaube, Hashwerte von Zeichenketten der Länge 6 oder so) MD5-Hashwerte herunterladen bzw. auf CDs kaufen konnte. Das waren ganz schön viele CDs, nach Hashwerten sortiert -> konnte man dann aus dem Hashwert, "ein Passwort" (ist ja redudant) bestimmen.

Hm, vielleicht waren das sg. Rainbow Tables. Diese lassen sich aber glaube ich für jedes Hashverfahren erstellen. Prinzip ist möglichst viele Hashwerte vorzuberechnen und im Speicher zu haben und so den Brute Force vorgang auf Sekundenbruchteile zu reduzieren. Somit wäre JEDES Hashverfahren nach der Logik jetzt schon geknackt ;)

Abgesehen davon: das war dann auf jden Fall nichts anderes als ein Brute Force Verfahren, und 6 Zeichen sind ja auch nicht wirklich lang...

[Der_Unwissende]

Hi,
sorry aber irgendwas versteh ich doch jetzt falsch, wenn jmd aus der DB den gespeicherten Hash auslesen kann (sonst kann man schlecht das PW aus den Rainbow Tables auslesen), dann hab ich doch eh schon ganz andere Probleme!
Ich meine ist ja schön und gut für die Theorie, aber es wird ja hier schließlich auf einem fremden, entfernten Rechner der Hash des PW auf Gleichheit mit dem gespeicherten geprüft.
Tauchen dabei Sicherheitslücken in der DB auf, so hat man natürlich den Vorteil, dass hier nur Hashes bekannt werden und mit Rechtzeitigem erkennen des Angriffs / auslesen der Hashes hat man dann reagieren.

Zitat:

Zitat von Meflin

Desweiteren ist der Artikel Heise-typsich: man verstecke eine einigermaßen potentiell-tolle Nachricht unter einer reiserischen Überschrift und kläre dann im Artikel dass es eigentlich garnicht so schlimm sei... :roll:

Na ja, so Heise-typisch ist das finde ich nicht. Das nennt man zurzeit wohl Journalismus. Da findet man doch häufig reisserische Überschriften mit wenig hinter, aber gerade wenn es um Sicherheit geht finde ich haben die alles richtig gemacht. Das sichert zu, dass Leute das Lesen und wenn man in Nachrichten schon Teile austauschen kann, sollte man ruhig schon mal über mögliche Probleme und Alternativen zu den Verfahren nachdenken. Ich glaube es gibt Leute, die werden nicht all zu publik machen, dass sie einen Weg haben um ein Sicherungsverfahren zu umgehen.

Gruß Der Unwissende

[negaH]

Zitat:

Hm, vielleicht waren das sg. Rainbow Tables. Diese lassen sich aber glaube ich für jedes Hashverfahren erstellen.

Diese Aussage muß ich korregieren. Rainbow Tables sind eine Form des Dictionary=Wörterbuch Angriffes. Bei diesen Verfahren berchnet man eine Tabelle aller möglichen Passwörter und deren Hash. Beim Angriff schlägt man einen Hashwert in dieser Tabelle nach und findet so das Passwort. Rainbow Tables sind eine spezielle Form dieser Wörterbücher die diesen Angriff beschleunigen weil weitaus weniger Speicher für diese Tabelle benötigt wird.

ABER! wenn man ein krytographisch korrektes Verfahren benutzt um das Passwort zu schützen dann funktionieren auch Rainbow Tables nicht mehr. Die Frage ist wie macht man es richtig ?

1.) ein Salt benutzen
2.) eine Hashfunktion benutzen

Man erzeugt einen Salt, das sind Zufallsdaten. Diese sollten mindestens so groß sein wie die Hashfunktion, dh. wenn wir SHA1 benutzen dann sollte dieser Salt 160 Bits groß sein, weil SHA1 eben 160 Bit groß ist.

Diesen Salt + das Passwort wird nun transformiert indem man damit die Hashfunktion füttert.
Der Hashdigest + der Salt werden auf dem Server zur Verifikation gespeichert.

Durch die Benutzung dieses Salts würde man also 2^160 Rainbow Tables benötigen statt nur EINER Tabelle ! Somit macht dieser simple Salt jedweige Form von Wörterbuch Angriffen unpraktikabel.

Rainbow Tables sind eine relativ neue Erfindung die überwertet wird. Ja, sie sind eine interessante Methode um schlecht bzw. kryptographisch unmodern konstuierte Verfahren zu knacken, zb. Windows/UNIX-Passwörter oder WLAN Verschlüsslung die nicht WPA2 konform ist.

Aber wenn man wie oben einen Salt + Password hasht dann funktinieren diese Angriffe nicht mehr.

Fazit: immer mit Salts arbeiten. Einmal um ein Password für eine Verschlüsselung in einen sicheren Sessionkey umzuwandlen, und zweites ein Salt vor die Daten die man verschlüsseln möchte um zb. Known Plaintext Angriffe auf unsere Daten zu verhindern !

Gruß Hagen