Sicherer Hash

K

klausschreiber

Well-known member
ID: 162475
L
6 Mai 2006
247
8
Hallo,
bei MD5 und SHA1 sind ja inzwischen viele Kollisionen bekannt. Bei PHP5 gibt es ja jetzt die hash()-Funktion, die ziemlich viele Hash-Algorithmen unterstützt. Auf einer Seite wurde Whirlpool empfohlen, der auch von NESSIE als sicher eingestuft wird. Er hat halt 128 Zeichen, aber da die Fesplatten ja immer größer werden (und somit auch der Platz der Webhoster), sollte das ja eigentlich kein Problem sein, oder? Was würdet ihr empfehlen? Whirlpool + Salt oder etwas anderes?

Gruß,
Klaus
 
SHA-512 mit gutem Salt
Wurde von der NSA entwickelt, das BSI sieht den Einsatz auch noch bis mindestens Ende 2015 für geeignet an.

Edit: Da die Angabe die ganze Sha-2 Familie betrifft kann man sich denken, dass SHA-512 eine ganze Ecke länger halten wird als SHA-224
 
Zuletzt bearbeitet:
ok, danke für die schnelle Antwort.
Als Salt hatte ich mir einen eigenen String mit Sonderzeichen usw., sowie den Benutzernamen des Users vorgestellt. Ich denke mal, das ist das beste, oder? Wie lang sollte der String sein? 20 Zeichen?
 
Ich habe mal noch eine Frage:
Speichert man die Antwort auf die "Passwort vergessen"-Frage eigentlich auch als Hash?
Ich habe vor, dass es einen Passwort vergessen Link gibt, wo man sein Usernamen und E-Mail-Adresse eingeben muss, dann kommt eine E-Mail mit einem zufällig generiertem Link und dort wird dann die Frage gestellt, die man vorher frei wählen konnte. Eigentlich ist es schon sinnvoll, die Antwort auch zu hashen, oder?

Die Angabe einer Frage und Antwort soll erstmal freiwillig sein, ich werde die Angabe aber empfehlen. Soll ich die Frage und Anwort dann trotzdem in der Tabelle "members" speichern, wo Username. Passwort usw. stehen, oder würdet ihr die Fragen und Antworten in diesem Fall in eine extra Tabelle auslagern?

Die letzte Frage ist mehr eine Spielerei bei sha512, aber wüde mich trotzdem interessieren.
Wäre es theoretisch sicherer, wenn man z.B. das Passwort zuerst temporär hashen würde, in dem Hash dann nach der ersten Zahl suchen würde (oder ähnliche Scherze, wie ersten Buchstaben nehmen und nach der Reihenfolge im Alphabet in eine Zahl umwandeln), dann den Salt anhand dieser Zahl in zwei Teile aufteilen würde und das Passwort (und eventuell den Usernamen) zwischen die beiden Teile schreiben würde und dann das ganze entgültig hashen würde?
Also z.B. statt "hash('sha512', $username . $password . $salt)" folgendes:
Passwort = Hose
Hash davon = ghf5ghtr3h9r
Salt = blablablub
Username = Klaus
=> Hash berechnen von "blabl Hose Klaus lablub"
Wäre soetwas komplett sinnlos, oder würde es (wenn sha512 schon geknackt wäre, oder z.B. bei md5) theoretisch die Sicherheit erhöhen?

Gruß,
Klaus
 
klausschreiber schrieb:
Ich habe vor, dass es einen Passwort vergessen Link gibt, wo man sein Usernamen und E-Mail-Adresse eingeben muss, dann kommt eine E-Mail mit einem zufällig generiertem Link und dort wird dann die Frage gestellt, die man vorher frei wählen konnte. Eigentlich ist es schon sinnvoll, die Antwort auch zu hashen, oder?
Zum Vergrößern anklicken....
Kommt drauf an. Problem bei solchen Fragen, wie z.B. Lieblingsfarbe, dass man "grün" als "grün" oder "Grün" schreiben kann.
Sobald du hasht, muss derjenige 1:1 denselben String wiedergeben können.

Es ist sowieso nicht empfehlenswert so ein System einzuführen, weil das anfälliger als das eigentliche Passwort is und somit mehr Unfug als ohne diese "Vergessen"-Funktion getrieben werden kann.
 
Danke für deine Antwort.

ja, das müsste ich dann halt dazuschreiben, dass Groß- und Kleinschreibung beachtet werden muss. Aber das war auch mit ein Grund meiner Frage, ob das zu Problemen führen kann (ich weiß nicht, ob die meisten User da ein Schema haben oder es sich merken können, ob sie groß oder klein geschrieben haben). Aber um bei dem Farbbeisspiel zu bleiben, da könnte der User ja notfalls auch einfach beides ausprobieren?

Die Passwort vergessen Funktion ansich ist natürlich wieder eiine zusätzliche Schwachstelle, wobei der Hacker dann zumindest auch schon den Mailaccount gehackt haben müsste.

Aber was ist dann die Alternative? Klar, ich kann sagen, dass man eine Mail an den Support schreiben muss. Aber im Prinzip ist das doch noch unsicherer, da sich jeder als User xy ausgeben kann? Ich habe auch erstmal nur Username, Vorname, Nachname und die Mailadresse vom User. Daher kann ich persönlich nicht wirklich festellen, ob es sich tatsächlich um den richtigen User handelt?

Gruß,
Klaus

edit:
Um die Sicherheit zu erhöhen, habe ich auch keine vorgefertigten Fragen, sondern der user muss bei Anmeldung selber eine Frage eingeben.
 
Zuletzt bearbeitet:
klausschreiber schrieb:
Die letzte Frage ist mehr eine Spielerei bei sha512, aber wüde mich trotzdem interessieren.
Wäre es theoretisch sicherer, wenn man z.B. das Passwort zuerst temporär hashen würde, in dem Hash dann nach der ersten Zahl suchen würde (oder ähnliche Scherze, wie ersten Buchstaben nehmen und nach der Reihenfolge im Alphabet in eine Zahl umwandeln), dann den Salt anhand dieser Zahl in zwei Teile aufteilen würde und das Passwort (und eventuell den Usernamen) zwischen die beiden Teile schreiben würde und dann das ganze entgültig hashen würde?
Also z.B. statt "hash('sha512', $username . $password . $salt)" folgendes:
Passwort = Hose
Hash davon = ghf5ghtr3h9r
Salt = blablablub
Username = Klaus
=> Hash berechnen von "blabl Hose Klaus lablub"
Wäre soetwas komplett sinnlos, oder würde es (wenn sha512 schon geknackt wäre, oder z.B. bei md5) theoretisch die Sicherheit erhöhen?
Zum Vergrößern anklicken....
es kommt da denke ich auf die Scherze an ;)
Aber je nach Kollisionsalgorithmus kann ich mir vorstellen, dass es einfacher, wenn man direkt annehmen kann, dass die ersten Buchstaben "blabl" sind ;)


theHacker schrieb:
Es ist sowieso nicht empfehlenswert so ein System einzuführen, weil das anfälliger als das eigentliche Passwort is und somit mehr Unfug als ohne diese "Vergessen"-Funktion getrieben werden kann.
Zum Vergrößern anklicken....
Richtig, den Großteil solcher Fragen kann mit Social Engineering in einem normalen Gespräch rausbekommen, und dem Betroffenen wird es nicht mal auffallen.

klausschreiber schrieb:
Aber was ist dann die Alternative? Klar, ich kann sagen, dass man eine Mail an den Support schreiben muss. Aber im Prinzip ist das doch noch unsicherer, da sich jeder als User xy ausgeben kann? Ich habe auch erstmal nur Username, Vorname, Nachname und die Mailadresse vom User. Daher kann ich persönlich nicht wirklich festellen, ob es sich tatsächlich um den richtigen User handelt?
Zum Vergrößern anklicken....
Sobald ein Email-Account gehackt wird, hast du als Entwickler sowieso keine Chance mehr.
 
theHacker schrieb:
Kommt drauf an. Problem bei solchen Fragen, wie z.B. Lieblingsfarbe, dass man "grün" als "grün" oder "Grün" schreiben kann.
Sobald du hasht, muss derjenige 1:1 denselben String wiedergeben können.
Zum Vergrößern anklicken....

Naja, man kann ja mit strtolower() das alles kleinschreiben lassen.
Damit hätte man dann das Problem gelöst :p
 
Danke für deine Antwort.

ice-breaker schrieb:
es kommt da denke ich auf die Scherze an ;)
Aber je nach Kollisionsalgorithmus kann ich mir vorstellen, dass es einfacher, wenn man direkt annehmen kann, dass die ersten Buchstaben "blabl" sind ;)
Zum Vergrößern anklicken....
Hmm, aber der Salt ist doch sowieso immer gleich? Oder willst du damit sagen, dass "$password . $salt" eventuell sicherer ist als "$salt . $password" und damit auch sicherer als "$saltteil1 . $password . $saltteil2"? Falls ja, der vordere Teil wäre ja nicht immer "blabl", sondern je nachdem "b" oder "bl" oder "bla" usw. und hängt vom unbekannten Passwort ab.
Wobei, falls du das für sicherer hälst, könnte man ja auch statt "blabl Hose Klaus lablub" "Hose blabl Klaus lablub". Meinst du, das wäre besser? (also "Hose" = Passwort, "Klaus" = Benutzername)

Dazu noch eine kleine Frage. Ich hashe ja auch den Benutzernamen mit, praktisch als variablen Salt, damit, falls man den festen Salt kennt, nicht eine Rainbowtabelle ausreicht speziell für diesen Salt ausreicht, um an alle Passwörter zu kommen.
Der Username ist aber ja bekannt, und wenn ein Hacker die Datenbank mit den Passwörtern hat, hat er auch den Usernamen (wobei er die PHP-Datei mit dem festen Salt ja noch nicht unbedingt haben muss). Macht der Username das Ganze dann unter Umständen unsicherer als sicherer, weil dadurch ein Teil dem Hacker bekannt ist?


ice-breaker schrieb:
Sobald ein Email-Account gehackt wird, hast du als Entwickler sowieso keine Chance mehr.
Zum Vergrößern anklicken....
Das stimmt. Aber da User nunmal vergesslich sind, muss ich ihm doch irgendeine Möglichkeit geben, wieder in den Account zu kommen ,oder? Und wenn ich dem User auf Anfrage per Hand ein neues Passwort zusenden würde, wäre das doch unsicherer, als wenn der User zusätzlich noch eine Frage beantworten muss, oder? Auch der Link für die Sicherheitsfrage würde ja per Mail verschickt.
Lediglich, wenn ein Hacker in die Datenbank kommt, ist das automatisierte System unsicherer, weil er dann ja den per Mail verschickten Link in der Datenbank sehen kann, oder habe ich da einen Denkfehler?

Aber meine eigentlich Frage dabei ist auch, wie würdet ihr das handhaben, wenn User xy sein Passwort vergessen hat?


Gruß,
Klaus

edit:
@Seth93: Das wäre auch eine gute Möglichkeit, daran habe ich gar nicht gedacht^^, thanks.
 
klausschreiber schrieb:
Der Username ist aber ja bekannt, und wenn ein Hacker die Datenbank mit den Passwörtern hat, hat er auch den Usernamen (wobei er die PHP-Datei mit dem festen Salt ja noch nicht unbedingt haben muss). Macht der Username das Ganze dann unter Umständen unsicherer als sicherer, weil dadurch ein Teil dem Hacker bekannt ist?
Zum Vergrößern anklicken....
Wenn ein Hacker in deine Datenbank kommt, ist es sowieso zu spät :LOL:
 
flaschenkind schrieb:
Öhm doch. Dann hat man die Passwörter eben nicht im Klartext und kann dann auch nicht versuchen, noch Zugriff auf E-Mail Accounts zu bekommen - viele User haben ja das gleiche Passwort.
Zum Vergrößern anklicken....
schon, aber ice-breaker hat das ja auf die Farge geantwortet, ob es eventuell falsch ist, den Usernamen für den Hash mitzuverwenden, weil den der Hacker in der Datenbank sehen kann und daher dann einen Teil des Ursprungsstrings kennt.
 
ich sagte nicht, dass es falsch ist :!:
Ich habe nur den Zweck in Frage gestellt ;)
Denn du willst den Usernamen als zusätzlichen Salt einführen, diesen kann der Hacker aber in der Db sehen, also Sicherheit bietet es aus diesem Gesichtspunkt keinen (der Hacker muss ja nur mit Bruteforce ein Pw + Username + Salt hashen, und der einzige Zufallsfaktor ist das Pw).

Sinn macht es jedoch um die Rechenzeit zu erhöhen, nehmen wir an du hashst nur Pw + Salt, dann kann man mit Bruteforce unmengen Passworte erzeugen und diese gegen die gesammte Db testen, nimmt man nun noch pro User eine extra Information zum Salt hinzu, kann ein Hacker nur noch gezielt per Bruteforce nach dem Pw eines Users suchen, nicht der ganzen Datenbank.

Ich erzeuge deshalb pro User nochmal einen Zufallssalt mit 8 Zeichen, der username würde auch gehen, das würde aber auch bedeuten, du kannst den User in der Db nicht umbennenen usw (vllt ist es ja mal nötig).

Also dieser Zusatzsalt bringt keine höhere Sicherheit, er fordert vom Hacker nur mehr Rechenzeit zum Finden der Passworte.

"Aber ice hat doch gesagt, dass man nur noch gezielt nach dem Pw eines Users suchen kann, statt nach der gesammten Db, das ist doch höhere Sicherheit"
Theoretisch ja, solange aber Passwörter wie passwort, geheim, S*x, 123456 noch mit zu den Beliebtesten gehören, kann der Programmierer in der Praxis mit tolleren Hash-Verfahren auch keinen Blumentopf gewinnen, er kann nur die Rechenzeit beim Hacker erhöhen, was bei solch Trivialpasswörtern aber nichts bringt.
 
ice-breaker schrieb:
Theoretisch ja, solange aber Passwörter wie passwort, geheim, S*x, 123456 noch mit zu den Beliebtesten gehören, kann der Programmierer in der Praxis mit tolleren Hash-Verfahren auch keinen Blumentopf gewinnen, er kann nur die Rechenzeit beim Hacker erhöhen, was bei solch Trivialpasswörtern aber nichts bringt.
Zum Vergrößern anklicken....
Die sicherste Variante bei sowas ist es, den Usern schon bei der Passworterstellung das Sicherheitsproblem aufzuzeigen und ihnen solche Passwörter gar nicht verwenden lassen.

Passwortannahme nur bei

  • mind. 8 Stellen
  • mind. ein Groß-, mind. ein Kleinbuchstabe
  • mind. eine Ziffer
  • mind. ein Sonderzeichen
Dann heißt das Passwort halt nicht mehr "gemein", sondern "Geheim7!", aber es bringt schon kräftig was.
 
Öhm, also ich musste solch eine Funktion bei einem Dienst schon wieder rausnehmen.
Weil...:
  • die User haben unverhältnismäßig oft die Passwörter neu angefordert
  • Accounts wurden unverhältnismäßig oft für eine kurze Zeitspanne gesperrt, weil sie das Passwort zu oft falsch eingaben
  • das Passwort hing an einem Post-It am Monitor
  • es kamen Beschwerden, dass die Browserfunktionalität des Speicherns von Passwörtern nicht ging (war ausgehebelt, damit es niemand nutzt)
 
ice-breaker schrieb:
  • die User haben unverhältnismäßig oft die Passwörter neu angefordert
  • Accounts wurden unverhältnismäßig oft für eine kurze Zeitspanne gesperrt, weil sie das Passwort zu oft falsch eingaben
  • das Passwort hing an einem Post-It am Monitor
Zum Vergrößern anklicken....
Sie waren zu dumm, es sich zu merken? Gut, ihr Problem, nicht deins als Webmaster.
ice-breaker schrieb:
  • es kamen Beschwerden, dass die Browserfunktionalität des Speicherns von Passwörtern nicht ging (war ausgehebelt, damit es niemand nutzt)
Zum Vergrößern anklicken....
Das versteh ich nicht. Was sie am Client machen, is ja ihre Sache. Ob sie Software nutzen, kannst du als Webmaster ja nicht beeinflussen.
Ich verwende sowas auch - empfehle es sogar - z.B. KeePass.

Ich weiß nur, wies bei uns an der Uni läuft. Dort sind genau solche Passwörter Pflicht und du kannst kein anderes verwenden. Es wurden ebenso mehrfache Buchstaben und Buchstabenfolgen (abcde, qwert) erkannt und ausgeschlossen.


Wenn die Nutzer nicht im Stande sind, auf ihre Passwörter aufzupassen, kann man ihnen auch nicht helfen. Wenn ich so ein System einbaue - hab ich bis jetzt nicht -, dann lass ich mich auch nicht von dem Symptomen aufhalten, die du geschildert hast.

Seh es mal aus der Sicht: Wenn sich ein User mit unsicherem (d.h. in obigem Post gelistete Richtlinien) Passwort anmelden will, dann is das genauso fahrlässig, wie, wenn ich meinen Wohnungsschlüssel von außen in der Tür stecken lass.
Und solchen Leuten vermiete ich erst gar keine Wohnung, weil der Einbruch ja vorprogrammiert is.
 
theHacker schrieb:
Sie waren zu dumm, es sich zu merken? Gut, ihr Problem, nicht deins als Webmaster.Das versteh ich nicht.
Zum Vergrößern anklicken....
Wenn ein Unternehmen dahinter steckt, was mit dem Dienst Geld verdient, dann ist sowas nicht egal.

theHacker schrieb:
Was sie am Client machen, is ja ihre Sache. Ob sie Software nutzen, kannst du als Webmaster ja nicht beeinflussen.
Ich verwende sowas auch - empfehle es sogar - z.B. KeePass.
Zum Vergrößern anklicken....
man kann unterbinden, dass der unsichere Passwort-Speicher des Browsers genutzt wird, gegen KeePass hab ich nix ;)

theHacker schrieb:
Wenn die Nutzer nicht im Stande sind, auf ihre Passwörter aufzupassen, kann man ihnen auch nicht helfen. Wenn ich so ein System einbaue - hab ich bis jetzt nicht -, dann lass ich mich auch nicht von dem Symptomen aufhalten, die du geschildert hast.
Zum Vergrößern anklicken....
privat läuft das nunmal anders ;)
Aber wenn der zahlende Kunde zunzufrieden ist, weil er sich ein sicheres Passwort merken muss :)ugly:), muss man eben teilweise Entwicklungen rückgängig machen.
Wenn Accounts gehackt und die Daten gelöscht werden, dann kann man dem Kunden immer noch ne sündhaft teure Extraktion seiner Daten aus den Backups anbieten :biggrin:
 
Hm.. wäre es nicht auch eine Möglichkeit, wenn man bei einem Passwort Zeichen für Zeichen durchgeht, ASCII-Code ausliest, erhöhen und entsprechendes Zeichen speichern? Am Ende daraus dann einen Hash generieren?

So etwas habe ich zwar noch nie gemacht, aber dann sollte doch am Ende aus einem Zeichenkauderwelsch ein Hash generiert werden.. Und Sonderzeichen sind doch als Passwort ziemlich sicher !?
 
chrissel schrieb:
Hm.. wäre es nicht auch eine Möglichkeit, wenn man bei einem Passwort Zeichen für Zeichen durchgeht, ASCII-Code ausliest, erhöhen und entsprechendes Zeichen speichern? Am Ende daraus dann einen Hash generieren?
Zum Vergrößern anklicken....
Es formaler ausgedrückt: Das Passwort vor dem Hashen noch verschlüsseln.

@ice-breaker:
Lass Unternehmen aus dem Spiel. Wenn es nicht nach deiner eigenen Nase läuft, dann interessiert es dich doch eh herzlich wenig, sondern setzt nur das um, was gewünscht wird.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben