https://wiki-de.moshellshocker.dns64.de/index.php?action=history&feed=atom&title=BcryptBcrypt - Versionsgeschichte2026-05-23T04:33:46ZVersionsgeschichte dieser Seite in Wikipedia (Deutsch) – Lokale KopieMediaWiki 1.43.8https://wiki-de.moshellshocker.dns64.de/index.php?title=Bcrypt&diff=2185712&oldid=previmported>TaxonBot: Bot: Auflösung doppelter toter Links nach https://de.wikipedia.org/w/index.php?title=Wikipedia:Bots/Anfragen&oldid=266185123#Aufl%C3%B6sung_der_doppelten_Toten_Links2026-04-16T13:06:03Z<p>Bot: Auflösung doppelter toter Links nach https://de.wikipedia.org/w/index.php?title=Wikipedia:Bots/Anfragen&oldid=266185123#Aufl%C3%B6sung_der_doppelten_Toten_Links</p>
<p><b>Neue Seite</b></p><div>{{DISPLAYTITLE:bcrypt}}<br />
'''bcrypt''' ist eine [[kryptologische Hashfunktion]], die speziell für das Hashen und Speichern von [[Passwort|Passwörtern]] entwickelt wurde. Die auf dem [[Blowfish]]-Algorithmus basierende Funktion wurde von Niels Provos und David Mazières konzipiert und auf der [[USENIX]]-Konferenz im Jahre 1999 der Öffentlichkeit präsentiert.<br />
<br />
== Hintergrund ==<br />
<br />
Um Benutzer einer Anwendung oder Website zu [[Authentifizierung|authentifizieren]], wird in der Regel eine Kombination von Benutzername oder [[E-Mail-Adresse]] und einem Passwort eingesetzt. Die Website muss das Passwort hierzu speichern, allerdings ist das Speichern des Passworts in unverschlüsselter Form ein beachtliches Sicherheitsrisiko. Falls Passwort und Benutzername einem Dritten bekannt werden (etwa, falls die Website gehackt wird), kann dieser sich gegenüber der Website authentifizieren. Da viele Anwender für viele Dienste die gleiche Kombination von Benutzername und Passwort verwenden, kann dies auch weitere Dienste betreffen.<br />
<br />
Dieses Problem wird in der Regel mittels kryptographischer Hashfunktionen umgangen. Dabei wird mit einer solchen Funktion ein Hashwert des Passwortes ermittelt und gespeichert. Solche Funktionen zeichnet aus, dass das Original-Passwort nicht wiederhergestellt werden kann. Um den Benutzer zu authentifizieren, wird die Eingabe des Benutzers mit der gleichen Funktion gehasht und die beiden Hashwerte verglichen – wenn die Original-Passwörter gleich sind, sind auch die Hashwerte gleich.<br />
<br />
Die Hashfunktionen [[MD5]] und die [[Secure Hash Algorithm]] (SHA1 usw.) sind mit dem Ziel entwickelt worden, die Daten möglichst effizient zu hashen, da sie etwa auch zur Verifizierung von großen Dateien verwendet werden. Diese Effizienz erleichtert es aber auf der anderen Seite, die Passwörter mittels [[Brute-Force-Attacke]]n zu erraten oder sog. [[Rainbow-Table]]s zu erstellen, weswegen diese nicht mehr zum Hashen von Passwörtern verwendet werden sollten.<br />
<br />
== Design ==<br />
<br />
Passwort-Hashing-Verfahren wie [[PBKDF2]], [[scrypt]] und auch bcrypt wurden im Gegensatz zu regulären Hashing-Verfahren mit dem Ziel entwickelt, das Hashing möglichst aufwändig zu gestalten. Für normale Anwendungszwecke fällt dieser Aufwand gegenüber anderen Faktoren nicht ins Gewicht, erst wenn die Berechnung häufig hintereinander durchgeführt werden soll (wie z.&nbsp;B. bei einem Brute-Force-Angriff) tritt eine erhebliche Verlangsamung ein.<br />
<br />
Die Präsentation von bcrypt führte zu diesem Zweck einige Design-Kriterien für Passwort-basierte Schlüsselableitungsfunktionen ein:<br />
* Bcrypt verfügt über einen je nach Anwendungszweck einstellbaren Kostenfaktor, der den Arbeitsaufwand der Hashwert-Berechnung definiert. Mit diesem Faktor kann auch der Aufwand erhöht werden, wenn sich in der Zukunft die Leistungsfähigkeit der Computer weiterentwickelt.<br />
* Die Funktion soll für den Kontext, für den sie konstruiert wurde, optimiert sein. Performance-Vorteile für Hardware-Implementierungen und andere Programmiersprachen sollen gering ausfallen, da solche Vorteile einem Angriff zugutekommen.<br />
** Eine (moderate) Speicheranforderung begrenzt den Vorteil von Hardware-Optimierungen. Bcrypt fordert 4 KB Arbeitsspeicher an.<br />
** Software-Implementierungen sollen auf Operationen beruhen, die für CPUs optimiert sind, wie exklusiv-Oder, Addition oder Shift-Operationen.<br />
<br />
Die [[National Institute of Standards and Technology|NIST]]-Empfehlung von 2010 zur PBKDF2<ref>Meltem Sonmez Turan; Elaine B. Barker; William E. Burr; Lidong Chen: [https://www.nist.gov/customcf/get_pdf.cfm?pub_id=907381 ''Recommendation for Password-Based Key Derivation Part I: Storage Applications'']. NIST SP – 800-132, 2010. </ref> berücksichtigt nur das erste Kriterium. Aufgenommen und erweitert wurden diese Kriterien jedoch in der Schlüsselableitungsfunktion [[scrypt]] und von der [[Password Hashing Competition]].<ref>Password Hashing Competition: {{Webarchiv | url=https://password-hashing.net/call.html | wayback=20130902044128 | text=''Call for submissions''}}. Kriterien für Passwort-basierte Schlüsselableitungsfunktionen.</ref><br />
<br />
== Funktionsweise ==<br />
<br />
Bcrypt unterscheidet sich nur in einigen Punkten von der [[Blockverschlüsselung]] Blowfish. Die Verlangsamung findet hauptsächlich innerhalb der Passwort-abhängigen Berechnung der Runden-Schlüssel und der [[S-Box]]en statt. Diese werden in mehreren Runden abhängig vom [[Salt (Kryptologie)|Salt]] und dem Passwort durch die Funktion ''EksBlowfishSetup'' modifiziert. Die Anzahl dieser Runden ist 2 hoch der ''cost''-Parameter. Im Anschluss daran wird mit den so erzeugten Runden-Schlüsseln und S-Boxen der 192-Bit-Wert „OrpheanBeholderScryDoubt“ 64-mal im [[Electronic Code Book Mode|ECB-Modus]] verschlüsselt.<br />
<br />
Das Resultat der bcrypt-Referenz-Implementierung ist eine 60 Zeichen lange Zeichenabfolge, die an die Erfordernisse des ursprünglichen Anwendungszwecks, der Benutzer-Authentifizierung von [[OpenBSD]], angepasst ist. Mit dem Zeichen „$“ wird die Zeichenfolge eingeleitet und jeweils Versionsnummer, Kostenfaktor und eine Zeichenfolge bestehend aus Salt und Hashwert getrennt. Salt und Hashwert werden mit einer speziellen [[Base64]]-Kodierung abgebildet; der eigentliche Hashwert ist in den letzten 31 Zeichen enthalten. Dieses Format wird auch von anderen Implementierungen übernommen.<br />
<br />
== Sicherheit ==<br />
<br />
Die Länge des Passworts ist bei bcrypt auf 56 Bytes beschränkt, auch wenn die meisten Passwörter diese Grenze nicht überschreiten.<br />
<br />
Die Speicheranforderung von 4 KB wird der Anforderung, Hardware-Implementierungen beispielsweise in [[Field Programmable Gate Array|FPGAs]] und [[Anwendungsspezifische integrierte Schaltung|ASICs]] zu limitieren, nicht gerecht.<br />
Unter Einbeziehung der Energieeffizienz und der Kosten für die Hardware ist bcrypt vor allem durch parallel rechnende FPGAs angreifbar ([[Wörterbuchangriff]] oder [[Brute-Force-Methode]]). Ein Angriffsszenario mit speziellen ASICs wäre noch aussichtsreicher.<ref>Katja Malvoni, Solar Designer, Josip Knezovic: [https://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/WOOT14-Energy-Efficient-Cracking-Paper.pdf ''Are Your Passwords Safe: Energy-Efficient Bcrypt Cracking with Low-Cost Parallel Hardware'']. Untersuchung über die Performance von Hardware zum Brechen von bcrypt-Hashwerten (pdf). ''(englisch)''</ref><ref>[https://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/slide-59.html ''Energy-efficient bcrypt cracking: Takeaways'']. Präsentation bei openwall. ''(englisch)''</ref><ref>Wiemer, F., Zimmermann, R.: {{Toter Link |datum=2024-07 |url=https://www.emsec.rub.de/media/crypto/veroeffentlichungen/2014/10/22/reconfig14_bcrypt.pdf |text=''High-speed implementation of bcrypt password search using special-purpose hardware'' |archivebot=2024-07-22 17:46:12 InternetArchiveBot}}. In 2014 International Conference on Reconfigurable Computing and FPGAs (ReCoFig), 2014.</ref><br />
Dennoch schneidet bcrypt bei Vergleichen in Bezug auf Angriffe mit spezialisierter Hardware oft besser ab als die meisten anderen Passwort-basierten Schlüsselableitungsfunktionen, abgesehen von [[scrypt]].<ref>Colin Percival: [https://www.tarsnap.com/scrypt/scrypt.pdf ''Stronger Key Derivation via Sequential Memory-Hard Functions'']. Präsentation auf dem BSDCan'09. Auf S. 14 werden die Kosten zum Brechen verschiedene Funktionen miteinander verglichen. </ref><ref>European Union Agency for Network and Information Security: {{Webarchiv|url=https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-size-and-parameters-report-2014/at_download/fullReport |wayback=20151017094652 |text=''Algorithms, key size and parameters report – 2014.'' }} S. 53. (pdf)</ref><ref>https://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/ Enthält auf S. 45 und 46 einen Vergleich bezüglich FPGAs/ASICs und GPUs.</ref><ref>Markus Dürmuth and Thorsten Kranz: {{Webarchiv|url=https://www.mobsec.rub.de/media/mobsec/veroeffentlichungen/2015/04/02/duermuth-2014-password-guessing.pdf |wayback=20150626141501 |text=''On Password Guessing with GPUs and FPGAs'' }}. 2014 (PDF; 391&nbsp;kB).</ref><br />
<br />
== Weiterentwicklung ==<br />
<br />
Mit ''Pufferfish'' von Jeremi Gosney nimmt ein Algorithmus an der [[Password Hashing Competition]] teil, der stark an bcrypt angelehnt ist.<ref>Wiki der Password Hashing Competition: {{Webarchiv|url=https://password-hashing.net/wiki/doku.php/pufferfish |wayback=20140819083228 |text=Pufferfish. }} ''(englisch)''</ref> Auch der an [[scrypt]] angelehnte Algorithmus ''yescrypt'' nimmt den Mechanismus des schnellen, zufälligen Zugriffs, der den Algorithmus GPU-resistent macht, auf.<ref>Wiki der Password Hashing Competition: {{Webarchiv|url=https://password-hashing.net/wiki/doku.php/yescrypt |wayback=20140819082820 |text=yescrypt. }} ''(englisch)''</ref><br />
<br />
== Weblinks ==<br />
* [https://www.usenix.org/events/usenix99/provos.html A Future-Adaptable Password Scheme], von Niels Provos und David Mazières ''(englisch)''<br />
<br />
== Einzelnachweise ==<br />
<references /><br />
<br />
[[Kategorie:Kryptographische Hashfunktion]]</div>imported>TaxonBot