Thema: authentication
-
Tale MCP: Deployment-Endpunkt und Organisationsbereich
Tale stellt für Wissen und Automatisierungen einen deploymentspezifischen MCP-Endpunkt bereit, der Bearer-API-Keys und die Eingrenzung auf eine Organisation verwendet. Diese Referenz fasst die dokumentierten Verbindungs- und Berechtigungsgrenzen zusammen.
-
Kerberos-Client-Grundlagen unter Linux: krb5.conf, kinit/klist/kdestroy und Keytabs
Ein Linux-Host nutzt Kerberos über /etc/krb5.conf, einen benutzer- oder dienstbezogenen Credential Cache, der mit kinit, klist und kdestroy verwaltet wird, sowie Keytabs für die unbeaufsichtigte Authentifizierung. Zeitabweichungen und die Gross-/Kleinschreibung von Realm-Namen verursachen die meisten Fehler, auf die ein Agent stösst.
-
Kerberos unter Windows: klist, klist purge und setspn -L/-Q bei SPN-Problemen
Windows stellt gecachte Kerberos-Tickets über klist und Service Principal Names über setspn zur Verfügung. Doppelte SPNs und Zeitabweichungen zwischen Client und Domänencontroller sind die zwei Fehlerursachen, die am häufigsten als unklare «Authentifizierung nicht möglich»-Meldungen statt als eindeutige Kerberos-Fehler auftreten.
-
JSON Web Tokens: Was schiefgehen kann und die Antworten von RFC 8725
JWTs sind signierte Claims, keine verschlüsselten Geheimnisse; den Algorithmus gegen eine Positivliste prüfen, Aussteller, Zielgruppe und Ablauf verifizieren, Lebensdauern kurz halten, 'none' nie akzeptieren, und daran denken, dass sich ein zustandsloses Token ohne serverseitige Liste nicht widerrufen lässt.
-
Cookie-Attribute: Secure, HttpOnly, SameSite, Domain, Path und das Präfix __Host-
Jedes Set-Cookie-Attribut schränkt ein, wohin ein Cookie gesendet wird oder wer es lesen kann: Secure beschränkt es auf TLS, HttpOnly verbirgt es vor Skripten, SameSite=Strict/Lax/None regelt das seitenübergreifende Senden, Domain weitet die Auslieferung auf Subdomains aus (bei einem host-only-Cookie weglassen), Path ist keine Sicherheitsgrenze, und das Präfix __Host- lässt den Browser Secure, Path=/ und kein Domain erzwingen. Cookies isolieren nicht nach Port.
-
SSH-Meldung „Permission denied (publickey)“ mit ssh -v richtig lesen
„Permission denied (publickey)“ in OpenSSH bedeutet, dass alle vom Client angebotenen Schlüssel abgelehnt wurden oder gar keiner angeboten wurde – welcher Fall vorliegt, sagt die Meldung nicht. Der Artikel zeigt, wie ssh -v genau die probierten Schlüssel benennt, und behandelt falsche Benutzernamen, IdentitiesOnly, Rechte von authorized_keys auf dem Server sowie den mit OpenSSH 8.8 deaktivierten Standard ssh-rsa (SHA-1).
-
Passwort-Reset-Abläufe, die keine Konten oder Tokens preisgeben
Ein Reset-Ablauf ist ein zweiter Anmeldeweg und verdient dieselbe Sorgfalt: Jede Anfrage identisch beantworten, ein einmal verwendbares, ablaufendes, zufällig erzeugtes Token an die hinterlegte Adresse senden, den Link aus einem festen Origin statt aus dem Host-Header aufbauen, nichts am Konto ändern, bevor das Token vorgelegt wird, und am Ende die Nutzerin oder den Nutzer benachrichtigen und über die normale Anmeldung führen.
-
Konto-Enumeration in Login-, Registrierungs- und Reset-Formularen verhindern
Jeder Unterschied zwischen der Antwort für ein bestehendes und ein nicht bestehendes Konto (Nachrichtentext, HTTP-Status, Weiterleitung, Zeitverhalten) erlaubt es einer angreifenden Partei, eine Liste gültiger Nutzerinnen und Nutzer für einen Angriff aufzubauen. Dieselbe generische Nachricht und denselben Status zurückgeben, auf beiden Pfaden dieselbe Arbeit verrichten, die unterscheidende Information in eine E-Mail verlagern und drosseln, damit die verbleibenden Unterschiede nicht in grossem Massstab abgetastet werden können.
-
Speichern von Passwörtern und API-Schlüsseln
Passwörter werden nur als gesalzene, langsame Hashes gespeichert (Argon2id, scrypt, bcrypt); API-Schlüssel mit hoher Entropie können einen schnellen, geschlüsselten Hash verwenden; beide werden in konstanter Zeit verglichen und nach der Ausgabe nie protokolliert oder zurückgegeben.
-
Zeitbasierte Einmalpasswörter als zweiter Faktor
TOTP (RFC 6238) leitet aus einem gemeinsamen Geheimnis und dem aktuellen Zeitschritt einen kurzen Code ab; es schützt vor der Wiederverwendung von Passwörtern, aber nicht vor Echtzeit-Phishing, und braucht sichere Speicherung des Geheimnisses, Uhrentoleranz und Wiederherstellungscodes.
-
OAuth-2.0-Client-Credentials für Machine-to-Machine-Zugriff
Der Client-Credentials-Grant erlaubt es einem Dienst oder Agenten, mit eigener Client-ID und eigenem Secret ein Access Token zu erhalten, ohne einen Benutzer; Scope und Resource Indicators grenzen das Token ein, und das Secret muss wie ein Passwort behandelt werden: vom Server gehasht gespeichert und vom Client rotiert.
-
Verringern generische Anmelde- und Reset-Meldungen die Kontoübernahme messbar, wenn Breach-Korpora ohnehin schon verraten, welche Adressen existieren?
Offene Frage: Empfehlungen verlangen nicht unterscheidbare Antworten für existierende und nicht existierende Konten, zu realen Kosten bei der Benutzbarkeit; hat irgendein Dienst gemessen, ob Credential-Stuffing oder gezieltes Phishing gegen ihn zurückgingen, nachdem die Enumeration geschlossen wurde – wenn Angreifer bereits über E-Mail-Listen aus Breaches anderer Seiten verfügen?
-
Grundlagen des Session-Managements für Webanwendungen
Session-Identifikatoren müssen zufällig, lang, auf ein Cookie mit Secure/HttpOnly/SameSite begrenzt, bei der Anmeldung neu erzeugt, serverseitig befristet und widerrufbar sein; Zustand serverseitig oder in signierten Tokens mit kurzer Lebensdauer speichern.
-
Kontosperre und Passwortqualität unter Linux mit pam_faillock und pwquality
pam_faillock sperrt ein Konto nach wiederholten fehlgeschlagenen Anmeldungen, der Befehl faillock zeigt diesen Zustand an oder setzt ihn zurück; pam_pwquality erzwingt Regeln für die Passwortstärke aus pwquality.conf. Beide werden unter RHEL-Derivaten über authselect und unter Debian/Ubuntu über pam-auth-update in PAM eingebunden, nicht durch direktes Bearbeiten des PAM-Stacks.
-
API-Schlüssel oder OAuth für Drittanbieter-Integrationen
Ein API-Schlüssel identifiziert eine aufrufende Anwendung und eignet sich für serverseitige Integratoren, die im eigenen Namen handeln; OAuth 2.0 ist nötig, wenn ein Dritter im Namen einer Nutzerin oder eines Nutzers handelt, weil es einen abgegrenzten, widerrufbaren Zugriff je Partei ermöglicht, ohne die Zugangsdaten der Nutzenden weiterzugeben. Viele APIs brauchen beides.
-
MFA-Wiederherstellungscodes: Erzeugen, Speichern und Verwenden
Wiederherstellungscodes sind Look-up-Secrets: eine kleine Menge zufälliger, einmal verwendbarer Codes, die bei der Einrichtung eines zweiten Faktors ausgegeben werden, wie Passwörter gehasht gespeichert, ratenbegrenzt und einzeln verbraucht werden. Sie sind der Rückfall, wenn Telefon oder Schlüssel verloren gehen, daher müssen ihre Ausgabe, Nutzung und Neuausstellung so gut geschützt sein wie der Faktor, den sie ersetzen.
-
Phishing-resistente Anmeldung mit WebAuthn und Passkeys
WebAuthn authentifiziert mit einem seitenspezifischen Public-Key-Paar: Der Browser lässt eine Anmeldeinformation nur durch Origins verwenden, die unter der Relying-Party-ID liegen, für die sie registriert wurde, und der Authentifikator signiert eine Challenge des Servers, sodass eine Nachahmerseite nichts Wiederverwendbares erhält; Passkeys sind entdeckbare WebAuthn-Anmeldeinformationen, die oft zwischen den Geräten einer Person synchronisiert werden.
-
LDAP und Active Directory unter Linux mit ldapsearch abfragen, ohne Passwort auf der Kommandozeile
ldapsearch unterstützt einen Simple Bind mit Bind-DN und Passwort oder einen SASL/GSSAPI-Bind mit einem vorhandenen Kerberos-Ticket, ausserdem seitenweise Ergebnisse (Paged Results) sowie StartTLS/LDAPS für eine verschlüsselte Verbindung. Die Optionen -y und -W gibt es gerade deshalb, damit ein Passwort nie als Klartext-Argument auf der Kommandozeile stehen muss.
-
Timing-Angriffe und der zeitkonstante Vergleich von Geheimnissen
Eine gewöhnliche Gleichheitsprüfung bricht beim ersten abweichenden Byte ab, sodass die Antwortzeit verrät, wie viel eines erratenen Tokens oder MAC korrekt ist; Geheimnisse mit den zeitkonstanten Funktionen der Plattform vergleichen (hmac.compare_digest, crypto.timingSafeEqual, subtle.ConstantTimeCompare), die Eingaben gleich lang halten und unbekannten Nutzenden denselben Codepfad geben wie bekannten.
-
OAuth-2.0-Authorization-Code-Flow mit PKCE für öffentliche Clients
Ein öffentlicher Client (Single-Page-App, native App oder CLI-App) kann kein Client-Secret geheim halten, daher bindet er jede Autorisierungsanfrage an einen einmaligen Code Verifier: Er sendet den SHA-256-Hash als code_challenge, und der Token-Endpunkt gibt Tokens nur an diejenige Seite heraus, die den passenden Verifier vorlegt. RFC 9700 macht PKCE für öffentliche Clients verpflichtend und rät von der Implicit-Grant-Variante ab.
Maschinenlesbar: JSON