- bullseye 4.10.0-1
- bullseye-backports 4.18.1-1~bpo11+1
- testing 4.18.1-1
- unstable 4.18.1-1
CRYPT(3) | Library Functions Manual | CRYPT(3) |
BEZEICHNUNG¶
crypt
, crypt_r
,
crypt_rn
, crypt_ra
—
Hashen von Passphrasen
BIBLIOTHEK¶
Crypt Library (libcrypt, -lcrypt)
ÜBERSICHT¶
<crypt.h>
char *
crypt
(const
char *phrase, const char *setting);
char *
crypt_r
(const char *phrase,
const char *setting, struct crypt_data
*data); char *
crypt_rn
(const
char *phrase, const char *setting,
struct crypt_data *data, int
size); char *
crypt_ra
(const
char *phrase, const char *setting,
void **data, int *size);
BESCHREIBUNG¶
Die Funktionen crypt
,
crypt_r
, crypt_rn
und
crypt_ra
führen einen nicht umkehrbaren
»Hash« der phrase mit einer
»Hash-Methode« zur Speicherung in der Systempasswortdatenbank
(shadow(5)) durch. Das Ergebnis dieser Aktion wird
»gehashte Passphrase« oder einfach nur »Hash«
genannt. Die Hash-Methoden sind in crypt(5)
beschrieben.
setting steuert, welche Hash-Methode verwandt werden soll und stellt auch verschiedene Parameter für die ausgewählte Methode bereit, am wichtigsten ein zufälliges »salt«, das sicherstellt, dass keine zwei Hashes identisch sind, selbst falls die Zeichenketten phrase identisch sind.
Das Argument data von
crypt_r
ist eine Struktur des Typs
struct crypt_data. Sie hat mindestens die folgenden
Felder:
struct crypt_data { char output[CRYPT_OUTPUT_SIZE]; char setting[CRYPT_OUTPUT_SIZE]; char phrase[CRYPT_MAX_PASSPHRASE_SIZE]; char initialized; };
Wird von crypt_r
erfolgreich
zurückgekehrt, dann wird die gehashte Passphrase in
output gespeichert. Anwendungsprogrammierer werden
ermutigt (es ist aber nicht verpflichtend), die Felder
phrase und setting zu verwenden,
um die Zeichenketten zu speichern, die sie als phrase
und setting an crypt_r
übergeben. Dies erleichtert es, sämtliche sensitiven Daten zu
löschen, wenn diese nicht mehr benötigt werden.
Das Feld initialized muss auf
Null gesetzt werden, bevor erstmalig ein Objekt struct
crypt_data in einem Aufruf an
crypt_r
()
verwandt wird. Wir empfehlen vor dem ersten Einsatz, das gesamte Objekt mit
Nullen zu überschreiben, nicht nur initialized
und die dokumentierten Felder. (Natürlich sollte dies erfolgen, bevor
Sie etwas in setting und phrase
speichern.)
Das Argument data von
crypt_rn
sollte auch auf ein Objekt
struct crypt_data zeigen und
size sollte die Größe dieses Objektes
sein, nach einem Cast auf int. Wird dies zusammen mit
crypt_rn
verwandt, dann muss das gesamte Objekt
data (außer den Feldern
phrase und setting) vor dem
ersten Einsatz mit Nullen überschrieben werden; dies ist nicht nur
eine Empfehlung, wie bei crypt_r
. Abgesehen davon
haben die Felder die gleichen Zwecke wie bei
crypt_r
.
Beim ersten Aufruf von crypt_ra
sollte
data die Adresse einer Variablen void
*, die auf NULL gesetzt ist, sein, und size
sollte die Adresse einer Variablen int sein, die auf
Null gesetzt ist. crypt_ra
wird mittels
malloc(3) ein Objekt struct
crypt_data reservieren und initialisieren und seine Adresse und
Größe in die Variablen schreiben, auf die
data und size zeigen. Dies kann
in nachfolgenden Aufrufen wiederverwertet werden. Nachdem die Anwendung mit
dem Hashen von Passwörtern fertig ist, sollte sie das Objekt
struct crypt_data mittels free(3)
freigeben.
RÜCKGABEWERTE¶
Nach erfolgreichem Abschluss liefern
crypt
, crypt_r
,
crypt_rn
und crypt_ra
einen
Zeiger auf eine Zeichenkette zurück, die sowohl die gehashte
Passphrase als auch die Einstellungen, die zur Kodierung verwandt wurden,
enthält. Diese Zeichenkette kann direkt als
setting in anderen Aufrufen von
crypt
, crypt_r
,
crypt_rn
und crypt_ra
und
als prefix in Aufrufen von
crypt_gensalt
,
crypt_gensalt_rn
und
crypt_gensalt_ra
verwandt werden. Sie wird komplett
in ASCII darstellbar sein und wird keine Leerraumzeichen oder die Zeichen
‘:
’,
‘;
’,
‘*
’,
‘!
’ oder
‘\
’ enthalten. Siehe
crypt(5) für weitere Details über das Format
der gehashten Passphrasen.
crypt
legt sein Ergebnis in einem
statischen Speicherbereich ab, der bei nachfolgenden Aufrufen von
crypt
überschrieben wird. Es ist nicht
sicher, crypt
aus verschiedenen Threads simultan
aufzurufen.
crypt_r
, crypt_rn
und crypt_ra
legen ihr Ergebnis in dem Feld
output ihres Arguments data ab.
Es ist sicher, sie aus mehreren Threads simultan aufzurufen, solange
separate data -Objekte für jeden Thread
verwandt werden.
Im Fehlerfall schreiben crypt_r
,
crypt_rn
und crypt_ra
eine
ungültige
gehashte Passphrase in das Feld output ihres Arguments
data und crypt
schreibt einen
ungültigen Hash in seinen statischen Speicherbereich. Diese
Zeichenkette wird kürzer als 13 Zeichen sein und mit einem
‘*
’ beginnen und bei Vergleichen nicht
mit setting übereinstimmen.
Im Fehlerfall liefern crypt_rn
und
crypt_ra
einen Null-Zeiger zurück.
crypt_r
und crypt
können auch einen Null-Zeiger zurückliefern oder sie
können einen Zeiger auf einen ungültigen Hash
zurückliefern, abhängig davon, wie Libcrypt konfiguriert
wurde. (Die Option, einen Zeiger auf einen ungültigen Hash
zurückzuliefern, dient der Kompatibilität zu alten
Anwendungen, die annehmen, dass crypt
keinen
Null-Zeiger zurückliefern kann. Siehe
HINWEISE ZUR
PORTABILITÄT weiter unten.)
Alle vier Funktionen setzen errno beim Fehlschlag.
FEHLER¶
EINVAL
- setting ist ungültig oder es wurde eine nicht unterstützte Hash-Methode erbeten.
ERANGE
- phrase ist zu lang (mehr als
CRYPT_MAX_PASSPHRASE_SIZE
Zeichen; einige Hash-Methoden könnten niedrigere Begrenzungen haben).
Nurcrypt_rn
: size ist zu klein für die durch setting erbetene Hash-Methode. ENOMEM
- Interner Zwischenspeicher konnte nicht reserviert werden.
Nurcrypt_ra
: Speicher für data konnte nicht reserviert werden. ENOSYS
oderEOPNOTSUPP
- Das Hashen der Passphrase wird auf dieser Plattform überhaupt nicht unterstützt oder die in setting erbetene Hash-Methode wird nicht unterstützt. Diese Fehlercodes werden von dieser Libcrypt-Version nicht verwandt, könnten aber auf anderen Plattformen beobachtet werden.
HINWEISE ZUR PORTABILITÄT¶
crypt
ist Teil von POSIX, aber
crypt_r
, crypt_rn
und
crypt_ra
kommen in keinem der Standards vor.
POSIX legt keine Hash-Methode fest und verlangt nicht, dass gehashte Passphrasen zwischen Systemen portierbar sind. In der Praxis sind gehashte Passphrasen portierbar, solange beide Systeme die verwandte Hash-Methode unterstützen. Allerdings unterscheidet sich die Gruppe der unterstützten Hash-Methoden zwischen Systemen deutlich.
Das Verhalten von crypt
bei Fehlern ist
nicht gut standardisiert. Einige Implementierungen können schlicht
nicht fehlschlagen (außer durch Absturz des Programms), andere
liefern einen NULL-Zeiger oder eine bestimmte Zeichenkette zurück.
Die meisten Implementierungen setzen errno nicht,
andere wiederum tun dies. POSIX legt fest, dass ein NULL-Zeiger
zurückgeliefert und errno gesetzt werden soll,
es definiert aber nur einen möglichen Fehler,
ENOSYS
, falls crypt
überhaupt nicht unterstützt wird. Einige ältere
Anwendungen sind nicht in der Lage, mit durch crypt
zurückgelieferten NULL-Zeigern umzugehen. Das oben für diese
Implementierung beschriebene Verhalten, d.h. das Setzen von
errno und dem Zurückliefern einer
ungültigen gehashten Passphrase, die sich von
setting unterscheidet, wurde gewählt, um diese
Anwendungen zu einem Fehlschlag zu bewegen, wenn ein Fehler auftritt.
Aufgrund historischer Einschränkungen zum Export von
kryptographischer Software aus den USA ist crypt
eine optionale POSIX-Komponente. Anwendungen sollten daher darauf
vorbereitet sein, dass crypt
nicht verfügbar
ist oder zur Laufzeit einen Fehler zurückliefern (
errno auf ENOSYS
setzen).
POSIX spezifiziert, dass crypt
in
<unistd.h>
deklariert ist,
aber nur falls das Makro _XOPEN_CRYPT
definiert ist
und einen Wert größer oder gleich Null hat. Da Libcrypt nicht
<unistd.h>
bereitstellt,
deklariert es stattdessen crypt
,
crypt_r
, crypt_rn
und
crypt_ra
in
<crypt.h>
.
Auf einer Minderzahl an Systemen (insbesondere neueren Versionen
von Solaris) verwendet crypt
einen Thread-sicheren
statischen Speicherpuffer, wodurch es sicher ist, es von mehreren Threads
aus simultan aufzurufen, aber nicht verhindert, dass jeder Aufruf innerhalb
eines Threads die Ergebnisse des vorherigen Aufrufs überschreibt.
FEHLER¶
Im Fehlerfall liefern einige Implementierungen von
crypt
einen ungültigen Hash zurück,
der an einem nur-lesbaren Ort gespeichert oder nur einmal initialisiert
wird, was bedeutet, dass es nur sicher ist, dass der Puffer gelöscht
wird, auf den vom Rückgabewert von crypt
gezeigt wird, wenn kein Fehler auftrat.
struct crypt_data könnte recht groß sein (32 kB in dieser Implementierung von Libcrypt; mehr als 128 kB in einigen anderen Implementierungen). Dies ist groß genug, so dass es nicht ratsam sein könnte, dieses auf dem Stack zu reservieren.
Einige neu entwickelte Hash-Methoden benötigen noch mehr
Zwischenspeicher, aber die Schnittstelle crypt_r
ermöglicht es, die Größe von struct
crypt_data zu ändern, ohne die
Binärkompatibilität zu brechen. Die Schnittstelle
crypt_rn
könnte größere
Reservierungen für bestimmte Hash-Methoden berücksichtigen,
aber der Aufrufende von crypt_rn
hat keine
Möglichkeit zu erkennen, wieviel Speicher reserviert werden muss.
crypt_ra
erledigt die Reservierung selbst, aber kann
malloc(3) nur ein einziges Mal aufrufen.
ATTRIBUTE¶
Siehe attributes (7) für eine Erläuterung der in diesem Abschnitt verwandten Ausdrücke.
Schnittstelle | Attribut | Wert |
crypt | Multithread-Fähigkeit | MT-Unsafe race:crypt |
crypt_r , crypt_rn , crypt_ra | Multithread-Fähigkeit | MT-Safe |
GESCHICHTE¶
Eine Rotor-basierende Funktion crypt
erschien in Version 6 AT&T UNIX. Das
»traditionelle«, DES-basierende crypt
erschien erstmalig in Version 7 AT&T
UNIX.
crypt_r
entstammt der GNU-C-Bibliothek. Es
gibt auch eine Funktion crypt_r
unter HP-UX und MKS
Toolkit, allerdings unterscheiden sich deren Prototyp und Semantik.
crypt_rn
und
crypt_ra
entstammen dem Openwall-Projekt.
SIEHE AUCH¶
crypt_gensalt(3), getpass(3), getpwent(3), shadow(3), login(1), passwd(1), crypt(5), passwd(5), shadow(5), pam(8)
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Eberhard Schauer <Martin.E.Schauer@gmx.de> und Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer
11. Oktober 2017 | Openwall-Projekt |