[RELEASE] SHA1 Passwort Hash

[thecoreman]

Da MD5 mit überschaubaren aufwand brechbar ist (zwei verschiedene nachrichten bilden den selben hash) habe ich die Neuz um die SHA1 Hash funktion erweitert.


grüße

ps.: ist noch ungetestet wäre schön wenn ihr mich informiert obs klappt
pps: ich werde evtl noch die version für die sha2-Familie machen

edit: buffer overflow gefixxt
edit²: Tutorial verbessert

[Icetea]

Wenn man etwas releast sollte es meiner Meinung nach auch funktionieren
Für alle anderen hier ist der richtige link zum Tutorial:

Da der obere von thecoreman ja nicht funktioniert.

Liebe Grüße,
Icetea'

[thecoreman]

Originally Posted by Icetea'

Wenn man etwas releast sollte es meiner Meinung nach auch funktionieren
Für alle anderen hier ist der richtige link zum Tutorial:

Da der obere von thecoreman ja nicht funktioniert.

Liebe Grüße,
Icetea'

danke ist editiert
So wie es ist SOLLTE es funktionieren ich hatte aber bis jetzt noch keine möglichkeit gehabt es zu testen
grüße

[©ross]

Geile scheisse
Wer weis wie er es einsetzen muss hat noch einen Pluspunkt an Accountsicherheit

Das bisher niemand auf die Idee mit dem xp_crypt gekommen ist.. naja vllt haben es ja auch ein häufchen Server aber eben nicht Public^^

[xTwiLightx]

Originally Posted by ©ross

Geile scheisse
Wer weis wie er es einsetzen muss hat noch einen Pluspunkt an Accountsicherheit

Das bisher niemand auf die Idee mit dem xp_crypt gekommen ist.. naja vllt haben es ja auch ein häufchen Server aber eben nicht Public^^

Die xp_crypt dll kann auch nicht mehr als hashes erstellen... im übrigen hat sql server 12 auch einige Verschlüsselungen mit an Bord.

[Yume-no-beddo]

...

Traurig das hier anzusehen. Bevor nochmehr meinen mit ihrem Halbwissen zu flamen.

Zusammenfassung was der Threadersteller machen will:

1) Umstieg von MD5 auf einen anderen unsicheren Hash. Trololol
2) Kein Konzept und Verständnis dafür wo dadurch mehr Sicherheit entsteht.

Wie es richtig geht:

1) Umstieg von MD5 auf einen modernen Hash, von mir aus Sha-512 (eignet sich derzeit am besten aufgrund der in 2+4 entstehenden Kollisionen)
2) Hash (einmal Hashen auf der Client Seite, HP per JavaScript und Client ist keinerlei weitere Erläuterung Wert)
3) Generate Random/Concat Random (Serverseitig, min. 16 stelliger Salt und diesen mit dem Hash Concaten. Beim Account erstellen oder Passwort ändern natürlich generieren, ansonsten auslesen)
4) Hash (einmal Hashen auf der Server Seite, SQL Server verschlüsselung bringen einen nicht wirklich etwas außer das man die Last auf den SQL Server schiebt. Ob das sinnvoll ist, ist eine Frage des Gesamtkonzeptes eurer Projekte)

Effekt:
1) Der Account kann immernoch leergeräumt werden, aber sofern kein Keylogger bei dem jeweiligen Victim läuft ist das tatsächliche Passwort sicher.
2) Gerät die Datenbank in falsche Hände, unterstützen eigentlich nur die kostenpflichtigen GPU-Bruter lange und mit Sonderzeichen versehene Salts.
3) Gerät die Datenbank in falsche Hände, ist das bruten nur sehr schwer Zielführend. (Keine Rainbow-Tables, Sha-512 cracking ist extrem langsam zurzeit (moore's law) und ein langer Input erhöht ebenfalls den Aufwand.)

Absolute Sicherheit gibt es keine, aber man kann es den Leuten schwer machen.

P.S.: Ich würde kein Vertrauen in bcrypt setzen, das Konzept ist zwar gut. Aber das dürfte nicht so unberührt von Kollisionen bleiben. Ich bevorzuge so oder so SSH-Keys für jeglichen Auth.

P.P.S.: Wer sich infiziert hat, ist selber Schuld und hat eh bereits alles verloren. Da ist niemand außer einem selbst Schuld. Aber wenn jemand im Netzwerk mitsniffed (bsp. Studentenwohnheime, offene Wlans), kann sowas natürlich missbraucht werden.

P.P.P.S: Die "Verschlüsselung" die Flyff verwendet, handelt nichtmal dynamisch Keys aus und ist somit auch statisch.

Sprich char szDefaultKey[32]; dürfte nicht im Client definiert sein (einfach auslesen und gut ist) und müsste mit einem sicherem Schlüsselaustausch gesetzt werden. Und selbst dann, kann jemand der eh den Traffic mitliest alles entschlüsseln. Diese "Verschlüsselung" ist ohne Schlüsselaustausch so nutzlos, das man diese auch einfach in dieser Form rausnehmen kann und den selben Effekt erziehlt.

Post Post Post Post Scriptum:
Bedenket, wenn ihr in einem laufendem Projekt das Hashing ändert wollt. So müsstet ihr den User zwingen sein Passwort neu zu setzen. Daher wenn ihr mehr Sicherheit schaffen wollt, führt serverseitiges Salting+Hashing ein. Dafür braucht ihr nur die Hashes die euch schon zur Verfügung stehen.

[Tamatzu]

Originally Posted by Yume-no-beddo

...

Traurig das hier anzusehen. Bevor nochmehr meinen mit ihrem Halbwissen zu flamen.

Zusammenfassung was der Threadersteller machen will:

1) Umstieg von MD5 auf einen anderen unsicheren Hash. Trololol
2) Kein Konzept und Verständnis dafür wo dadurch mehr Sicherheit entsteht.

Wie es richtig geht:

1) Umstieg von MD5 auf einen modernen Hash, von mir aus Sha-512 (eignet sich derzeit am besten aufgrund der in 2+4 entstehenden Kollisionen)
2) Hash (einmal Hashen auf der Client Seite, HP per JavaScript und Client ist keinerlei weitere Erläuterung Wert)
3) Generate Random/Concat Random (Serverseitig, min. 16 stelliger Salt und diesen mit dem Hash Concaten. Beim Account erstellen oder Passwort ändern natürlich generieren, ansonsten auslesen)
4) Hash (einmal Hashen auf der Server Seite, SQL Server verschlüsselung bringen einen nicht wirklich etwas außer das man die Last auf den SQL Server schiebt. Ob das sinnvoll ist, ist eine Frage des Gesamtkonzeptes eurer Projekte)

Effekt:
1) Der Account kann immernoch leergeräumt werden, aber sofern kein Keylogger bei dem jeweiligen Victim läuft ist das tatsächliche Passwort sicher.
2) Gerät die Datenbank in falsche Hände, unterstützen eigentlich nur die kostenpflichtigen GPU-Bruter lange und mit Sonderzeichen versehene Salts.
3) Gerät die Datenbank in falsche Hände, ist das bruten nur sehr schwer Zielführend. (Keine Rainbow-Tables, Sha-512 cracking ist extrem langsam zurzeit (moore's law) und ein langer Input erhöht ebenfalls den Aufwand.)

Absolute Sicherheit gibt es keine, aber man kann es den Leuten schwer machen.

P.S.: Ich würde kein Vertrauen in bcrypt setzen, das Konzept ist zwar gut. Aber das dürfte nicht so unberührt von Kollisionen bleiben. Ich bevorzuge so oder so SSH-Keys für jeglichen Auth.

P.P.S.: Wer sich infiziert hat, ist selber Schuld und hat eh bereits alles verloren. Da ist niemand außer einem selbst Schuld. Aber wenn jemand im Netzwerk mitsniffed (bsp. Studentenwohnheime, offene Wlans), kann sowas natürlich missbraucht werden.

P.P.P.S: Die "Verschlüsselung" die Flyff verwendet, handelt nichtmal dynamisch Keys aus und ist somit auch statisch.

Sprich char szDefaultKey[32]; dürfte nicht im Client definiert sein (einfach auslesen und gut ist) und müsste mit einem sicherem Schlüsselaustausch gesetzt werden. Und selbst dann, kann jemand der eh den Traffic mitliest alles entschlüsseln. Diese "Verschlüsselung" ist ohne Schlüsselaustausch so nutzlos, das man diese auch einfach in dieser Form rausnehmen kann und den selben Effekt erziehlt.

Post Post Post Post Scriptum:
Bedenket, wenn ihr in einem laufendem Projekt das Hashing ändert wollt. So müsstet ihr den User zwingen sein Passwort neu zu setzen. Daher wenn ihr mehr Sicherheit schaffen wollt, führt serverseitiges Salting+Hashing ein. Dafür braucht ihr nur die Hashes die euch schon zur Verfügung stehen.

Du hast hier recht, aber es wäre am sichersten wäre es so wie ich es mache immoment einen Clienthash auf der einen seite diesen sollte man hier aber nicht posten, und einen 2 serverhash auf der anderen seite. Hierbei sollte man aber beachten wie im oberen erwähnt das man nicht alles auf die sql server schiebt.
Also was lernen wir daraus eigenen Hash bauen der noch nicht exestiert.
Wie funktioniert dieses und was brauche ich dafür?
Ihr braucht:
-brain.exe (neuste version 4.1)
-Bischen fantasie
-Zeit
-Augenmaße
Was muss ich machen ?
Du musst jetzt erstmal jeden Buchstaben einen Code zuweisen.
Zum beispiel so:
A=12aqbjyasdXasd8
a=125954194Xasd8
.....
.....
Dieses den in den Client einbauen und umwandeln achtung ihr solltet aber verifizieren das ihr keinen Virus habt oder den irgend einen kiddi vorzeigt oder so.Aber noch wichtiger ist das man auf den Server enthasht damit das Passwort in Mysql noch lesbar ist (zwinker zwinker) und der Passwort string nicht zu lang wird.

Mit dem obrigen beispiel würde den zumbeispiel wen ihr in der Neuz die minimale Passwort länge auf 2 sein und ihr als Passwort Aa hättet das hier sein:12aqbjyasdXasd8125954194Xasd8
Es entsteht zwar ein ellenlanges Passwort was wir aber ja wieder enthasen.

[FlyCraft.TobiLap]

Wie ihr immer auf leistung der SQl Server eingeht, solange keine 10k User gleichzeitig einloggen interessiert das den Server nen dreck ob ihr Jetz nochmal hashed oder nicht.
Mann müsste sich ausserdem überlegen ob man das hashen dem dbserver oder dem SQL server überlässt, ka welcher von beiden effektiver ist.

Einfach Aufm server nen 2tes mal hashen und gut ist, dann kann sich keiner mit den hashes aus der db einloggen.

[Yume-no-beddo]

Was hat der SQL Server damit zutun? Man kann die Last dem SQL Server zuschreiben, wenn man ein Loadbalancingkonzept hat in welchem dies so vergesehen ist. Das macht nur dann Sinn, wenn der SQL Server auch auf einem eigenem dediziertem Server läuft.

Kann es sein, das ihr genauso ungründlich lest wie ihr kryptisches deutsch produziert?

Jedenfalls danke das du es wiederholst, ich rezitiere:
"Daher wenn ihr mehr Sicherheit schaffen wollt, führt serverseitiges Salting+Hashing ein. Dafür braucht ihr nur die Hashes die euch schon zur Verfügung stehen."

Aber im endeffekt ist das ziemlich egal. Denn wenn eure DB geklaut wird, könnt ihr wahrscheinlich eh den Server schließen.

P.S.:

Wenn ihr auf dem Server Re-Hashed nur mit Salts und Re-Hashed nicht den Hexstring sondern die Bytefolge an sich, da ihr sonst die Komplexität reduziert.

[xTwiLightx]

MD5 ist meiner Meinung nach sowieso völlig ausreichend. Man sollte einfach einen anderen Hash als kikugalanet nehmen, diesen dann im Client möglichst unkenntlich machen (wobei dieser Aufwand nur für md5 schon wieder Resourcenverschwendung ist) und das wars. Die Passwörter können noch so gut verschlüsselt sein, wenn die Datenbanken ungeschützt auf dem Ganeserver herumgammeln.
Ich persönlich bevorzuge die dedizierte Variante, damit der SQL Server in Ruhe vor sich hinlaufen kann.

Ich finde es im übrigen sehr interessant wie manche hier behaupten, sie wüssten irgend etwas über SQL Server und dessen Auslastung. Das hashen ist, besonders ab SQL12 dank der encrypt Funktion keine Erwähnung mehr wert.

[Yume-no-beddo]

Die Passwörter werden nicht verschlüsselt, diese werden gehashed.

Twilight ich dreh das ganze mal um, SQL12 ist dank besserer Datenbanksysteme schon 3 Versionen davor keine Erwähnung mehr Wert. Hashing selbst ist vom Aufwand der Implementation her noch nie einer großen Erwähnung Wert gewesen. Was beachtet werden muss ist bekannt und die libraries stehen dafür bereits zur Verfügung. Was allerdings jeder Erwähnung Wert ist, ist die Wissenschaft hinter Hashes und Kryptologie im allgemeinen.

MD5 ist hingegen vollkommen unzureichend, und ohne serverseitigen Salt erst recht. Dazu benötigt der SQL Server (nicht bei Flyff!) die meiste Performance und man belastet ihn genau deshalb nicht mit Dingen die dort nicht hingehören (hashing und andere Spielchen). Genauso wäre es für historische Daten sinnvoll statt nur einem DB Server, einen Olap Cube zu nutzen. Nur um mal ein vernünftiges Beispiel zu nennen, wenn man mit richtigen Datenbanken arbeitet (btw. wer außer mir hält das DB Design von Flyff für absolut katastrophal?).

Folgendes Szenario als Beispiel:

Nehmen wir an du betreibst eine größere Internetplattform, du arbeitest bereits mit DB Clustern und die Applikation bedient sich außerdem des Master, Slave konzeptes.

Wo hashed du?

a) Am DB Server der schon genug zu tun hat?
b) Am Applikation Server?

Und wo wirst du bei hohen Peaks die schnellere Reaktionszeit gewährleisten können?


Datenbanken allgemein sollten grundsätzlich ab einer gewissen größe immer dediziert laufen. Für Flyff lohnt sich der Kostenaufwand allerdings zu 0,0%.

Genug abgeschweift zurück zum Punkt:
" Man sollte einfach einen anderen Hash als kikugalanet nehmen, diesen dann im Client möglichst unkenntlich machen (wobei dieser Aufwand nur für md5 schon wieder Resourcenverschwendung ist) und das wars."

- Komplett falsche denkweise, auf der Clientseite lohnt sich ein Salt nur wenn jemand im Netzwerk mitsniffed und den Salt nicht kennen würde und ist nutzlos. Diese Idee macht keinen Sinn und es ist unmöglich es unkenntlich zu machen.

Richtig ist es jedoch einen dynamischen Salt zu verwenden, diesen in der DB zu speichern und auf der Serverseite den empfangenen Hash mit dem Salt zu concaten und erneut zu hashen. Dadurch wird bei einem geknackten Hash nur ein User Passwort offen gelegt, auch wenn mehrere das selbe haben sollten, und erhöht damit erneut den Aufwand.

Der Unterschied zwischen Hash und Verschlüsselung ist im übrigen ein großer:
Eine Verschlüsselung kann rückgängig gemacht werden, ein Hash nicht.
Der zweite Unterschied ist: Eine Verschlüsselung wird mit einem Schlüssel bearbeitet, ohne Schlüssel wäre es eine Kodierung.

[Sedrika]

Ihr ober pros, auf keinem der Server sind mehr als 2k User online o.Ä. Von daher ist es doch egal wo was wie hashed wird.

[Yume-no-beddo]

Hat jemand ne DB mit nem Acc+Hash von Sedrika für mich?

[Sedrika]

Hat keiner, da ich mit meinen Daten nicht wie jeder andere rumhantiere Und selbst wenn, die Passwörter die ich auf X-Servern genutzt habe um mir den Inhalt anzusehen ist "test". Viel Spaß damit.

[Yume-no-beddo]

Ich meinte auch mehr andere Plattformen, wie Foren (vbulletin nutzt z.B. auch Standardmäßig md5(md5(password), salt) und in ganz alten Versionen noch ohne Salt. Aber du verstehst den Wink mit dem Bürgersteig anscheinend nicht.

Aber du hast natürlich recht, da es ja ein absolut unrelevantes Thema ist und die Passwörter von Usern sind sowieso Wertlos. Und diese wertlosen User die keiner mag dürfen auch ruhig sensible Daten verlieren, weil sie dummerweise nicht darüber nachdenken ein Trash Passwort zu nutzen, wo das Potenzial eines Leaks reell ist.

Außerdem ist es absolut unrelevant und totaler Schwachsinn über den Tellerrand hinweg zuschauen und nachzudenken. Mit Verlaub, das du keine Liebe für Technik und Algorithmen übrig hast, machst du deutlich klar. Danke für deinen sinnvollen Beitrag zu dieser Diskussion.