email-and-password-best-practices

Überblick über den Skill email-and-password-best-practices

Der Skill email-and-password-best-practices ist ein fokussierter Better Auth-Setup-Leitfaden für Teams, die einen klassischen Login mit Zugangsdaten umsetzen und dabei die sicherheitsrelevanten Bausteine korrekt abdecken wollen, die oft übersehen werden: E-Mail-Verifizierung, Passwort-Reset, Passwortrichtlinien und die Konfiguration des Passwort-Hashings. Er eignet sich besonders für Entwickler, die sich bereits für Better Auth entschieden haben und einen schnellen, verlässlichen Weg zu produktionsreifen E-Mail/Passwort-Flows brauchen – nicht eine allgemeine Einführung in Authentifizierung.

Wobei dir dieser Skill hilft

Nutze diesen Skill, wenn deine eigentliche Aufgabe darin besteht, einen vollständigen E-Mail/Passwort-Flow sauber zu verdrahten, der sicher genug für den produktiven Einsatz ist:

• Better Auth E-Mail/Passwort-Login aktivieren
• Verifizierungs-E-Mails versenden
• bei Bedarf Verifizierung vor dem Sign-in erzwingen
• Reset-Password-Zustellung ergänzen
• Passwortrichtlinien und Validierung anwenden
• Hashing-Verhalten feinjustieren
• den erforderlichen Migrationsschritt ausführen

Für wen sich die Installation lohnt

Dieser Skill passt besonders gut zu:

• App-Teams, die Username-/E-Mail-Login in ein Better Auth-Projekt einbauen
• Entwicklern, die improvisierte Auth-Prompts durch einen wiederholbaren Setup-Pfad ersetzen wollen
• AI-gestützten Coding-Workflows, in denen der Agent sich Better Auth-spezifische Konfigurationsnamen und die richtige Reihenfolge merken soll

Weniger hilfreich ist er, wenn du noch zwischen verschiedenen Auth-Providern vergleichst oder deine App ausschließlich OAuth/Passkeys nutzt und keine Passwörter braucht.

Warum er besser ist als ein generischer Auth-Prompt

Ein generischer Prompt könnte einem Agenten nur sagen: „add login and reset password“. Dieser Skill präzisiert das auf die tatsächlichen Better Auth-Stellschrauben und die sinnvolle Setup-Reihenfolge, einschließlich emailAndPassword: { enabled: true }, emailVerification.sendVerificationEmail, Reset-Password-Handling und npx @better-auth/cli@latest migrate. Dadurch wird der Anwendungsfall email-and-password-best-practices for Access Control deutlich verlässlicher.

Was vor der Einführung am wichtigsten ist

Bevor du installierst, prüfe diese Entscheidungspunkte:

• du brauchst eine Funktion zum Versenden von E-Mails oder musst sie fest einplanen
• du musst entscheiden, ob Sign-in eine verifizierte E-Mail voraussetzen soll
• du solltest klare Erwartungen an deine Passwortrichtlinien haben
• du brauchst Zugriff, um Better Auth-Migrationen auszuführen
• du solltest bereit sein, die Auth-Server-Konfiguration zu bearbeiten, nicht nur Frontend-Formulare

So verwendest du den Skill email-and-password-best-practices

Installationskontext für den Skill email-and-password-best-practices

Installiere den Skill aus dem Better Auth skills repository:

npx skills add https://github.com/better-auth/skills --skill emailAndPassword

Rufe ihn dann in einer AI-Coding-Session auf, wenn du Better Auth Credential-Flows konfigurieren, prüfen oder verbessern möchtest.

Diese Datei zuerst lesen

Beginne mit:

• better-auth/emailAndPassword/SKILL.md

Dieser Repository-Ausschnitt ist bewusst schlank. Der eigentliche Mehrwert liegt daher weniger im Durchstöbern einer großen Support-Struktur als darin, die Hinweise korrekt auf deine Codebasis anzuwenden.

Welche Eingaben der Skill von dir braucht

Gib dem Agenten den Kontext, den das Repository nicht selbst ableiten kann:

• den Pfad zu deiner Better Auth-Konfigurationsdatei
• ob E-Mail/Passwort bereits teilweise aktiviert ist
• deinen E-Mail-Versand-Provider oder eine vorhandene Helper-Funktion
• ob E-Mail-Verifizierung optional oder verpflichtend ist
• welche Reset-Password-UX du willst
• Anforderungen an Passwortlänge oder Komplexität
• ob du benutzerdefinierte Hashing-Einstellungen brauchst

Ohne diesen Kontext kann der Agent zwar ein Grundgerüst erzeugen, das Ergebnis bleibt dann aber generisch.

Aus einem groben Ziel einen starken Prompt machen

Schwacher Prompt:

• “Set up auth with Better Auth.”

Besserer Prompt:

• “Use the email-and-password-best-practices skill to configure Better Auth email/password login in src/lib/auth.ts, require email verification before sign-in, add sendVerificationEmail using our existing sendEmail() helper, implement reset-password email sending, and tell me what migration command and test steps I need.”

Das funktioniert besser, weil Dateipfad, gewünschte Durchsetzung, vorhandene Mail-Funktion und erwartete Deliverables klar benannt sind.

Empfohlener Setup-Workflow

Eine praxistaugliche Reihenfolge ist:

1. E-Mail/Passwort in Better Auth aktivieren.
2. Versand von Verifizierungs-E-Mails hinzufügen.
3. Entscheiden, ob Verifizierung vor dem Sign-in Pflicht sein soll.
4. Reset-Password-E-Mail-Zustellung ergänzen.
5. Regeln zur Passwortvalidierung anwenden.
6. Hashing-Einstellungen nur dann prüfen, wenn es einen konkreten Grund zur Anpassung gibt.
7. Migration ausführen.
8. Sign-up-, Verifizierungs-, Sign-in- und Reset-Flows Ende-zu-Ende testen.

Diese Reihenfolge reduziert Nacharbeit und entspricht dem typischen Vorgehen von Teams beim Debugging eines Auth-Rollouts.

Zentrale Konfiguration, auf der der Skill aufbaut

Der Skill dreht sich um einige zentrale Better Auth-Features:

• emailAndPassword: { enabled: true }
• emailVerification.sendVerificationEmail
• emailAndPassword.requireEmailVerification
• sendResetPassword
• Konfiguration der Passwortrichtlinien
• Anpassung des Hashing-Algorithmus
• npx @better-auth/cli@latest migrate

Wenn dein Prompt nicht erwähnt, welche dieser Punkte du brauchst, wählt der Agent möglicherweise Defaults, die du so gar nicht wolltest.

E-Mail-Verifizierung ist der wichtigste Adoptionsblocker

Für die meisten Teams ist nicht das Aktivieren von Passwort-Auth der schwierigste Teil, sondern das sichere Ausrollen der Verifizierung. Der Skill ist hier nützlich, weil er den Agenten daran erinnert, dass sendVerificationEmail { user, url, token } erhält und dass die bereitgestellte url den Verifizierungslink bereits enthält. So vermeidest du, Links unnötig selbst zusammenzubauen, obwohl schon eine vollständige URL vorhanden ist.

Wann verifizierte E-Mail verpflichtend sein sollte

Nutze emailAndPassword.requireEmailVerification, wenn dein Access-Control-Modell davon ausgeht, dass eine bestätigte Identität vor der Kontonutzung erforderlich ist. Die Repository-Hinweise nennen außerdem ein wichtiges Verhalten: Nicht verifizierte Nutzer erhalten beim Sign-in-Versuch erneut eine Verifizierungs-E-Mail. Genau solche praktischen Details fehlen in generischen Prompts oft.

Hinweise zur Nutzung von Passwort-Reset

Wenn deine App eine „Passwort vergessen“-Wiederherstellung unterstützt, solltest du den Agenten ausdrücklich bitten, sendResetPassword zu verdrahten und die komplette User Journey darzustellen:

• Reset anfordern
• E-Mail erhalten
• Link öffnen
• neues Passwort setzen
• erneut anmelden

Bitte nicht nur um ein „reset password backend“, sonst bekommst du unter Umständen nur eine Teilimplementierung ohne eigentlichen Versand.

Passwortrichtlinien und Client-Validierung

Der Skill deckt Passwortrichtlinien ab, aber du bekommst bessere Ergebnisse, wenn du konkret angibst:

• Mindestlänge
• ob Sonderzeichen erforderlich sind
• ob die Frontend-Validierung die Backend-Regeln spiegeln soll
• ob benutzerfreundliche Validierungsfehler zurückgegeben werden sollen

Das ist besonders wichtig, wenn dein Team konsistentes Verhalten über Sign-up-, Passwortänderungs- und Reset-Flows hinweg erwartet.

Hashing-Anpassung ist nicht immer nötig

Der email-and-password-best-practices usage-Pfad umfasst auch Hashing-Anpassungen, aber das solltest du als fortgeschrittene Anforderung behandeln. Wenn du keinen Compliance-, Migrations- oder Performance-Grund hast, bitte den Agenten lieber darum, sichere Defaults beizubehalten und zu erklären, statt den Algorithmus unnötig zu ändern.

Praktische Test-Checkliste nach der Implementierung

Bitte den Agenten, diese Szenarien zu validieren:

• Sign-up eines neuen Nutzers funktioniert
• Verifizierungs-E-Mail wird versendet
• Verifizierungslink funktioniert
• Sign-in ohne Verifizierung wird blockiert, falls erforderlich
• wiederholter Sign-in löst erwartungsgemäß eine neue Verifizierungs-E-Mail aus
• Reset-Password-E-Mail wird erfolgreich versendet
• altes Passwort funktioniert nach dem Reset nicht mehr
• Passwortvalidierung schlägt bei schwacher Eingabe klar nachvollziehbar fehl

Hier wird der email-and-password-best-practices guide deutlich wertvoller als ein bloßes Überfliegen des Repos: Er hilft dir, Verhalten zu testen – nicht nur Konfiguration einzufügen.

FAQ zum Skill email-and-password-best-practices

Ist dieser Skill nur für Better Auth gedacht?

Ja. Das ist ein provider-spezifischer Skill für Better Auth-Konfiguration und entsprechende Flows. Wenn du Better Auth nicht verwendest, lassen sich die Konfigurationsnamen und der Migrationsschritt nicht direkt übertragen.

Ist der Skill email-and-password-best-practices anfängerfreundlich?

Größtenteils ja – sofern du bereits weißt, wo deine Auth-Konfiguration liegt und wie deine App E-Mails versendet. Absolute Einsteiger brauchen unter Umständen zusätzliche Hilfe bei SMTP, Transactional-Email-Providern, Route-Verdrahtung und Frontend-Formularen.

Installiert er von selbst etwas?

Nein. Der Skill ist eine Leitlinie für einen AI-Workflow. In deinem Projekt muss Better Auth weiterhin eingerichtet sein, inklusive der E-Mail-Provider-Integration, auf die du setzt, und der Migrationsbefehl muss in deiner Umgebung ausgeführt werden.

Wann sollte ich diesen Skill nicht verwenden?

Überspringe ihn, wenn:

• du nur OAuth oder Passkeys brauchst
• du Auth-Plattformen vergleichst, statt Better Auth umzusetzen
• deine App Passwort-Login vollständig ausschließt
• du eine umfassende Sicherheitsarchitektur-Prüfung willst statt einer Better Auth-Konfigurationsaufgabe

Worin unterscheidet sich das von einer allgemeinen LLM-Frage zu Auth?

Der email-and-password-best-practices skill ist enger gefasst und direkter umsetzbar. Er lenkt das Modell auf die tatsächliche Konfigurationsoberfläche von Better Auth und auf die operativen Details rund um Verifizierungs- und Reset-Flows. Das reduziert halluzinierte APIs und fehlende Zwischenschritte.

Ist er für email-and-password-best-practices for Access Control nützlich?

Ja, besonders wenn deine Access Control davon abhängt, dass Identitäten vor dem App-Zugriff verifiziert sind. Die Anforderung, Sign-ins ohne Verifizierung zu blockieren, ist eine der wichtigsten Policy-Entscheidungen, bei deren korrekter Umsetzung dieser Skill hilft.

So verbesserst du den Skill email-and-password-best-practices

Gib dem Skill deine exakte Auth-Datei und Mail-Helper mit

Der schnellste Hebel für bessere Ergebnisse ist, dem Agenten die richtige Datei und die vorhandene E-Mail-Utility zu zeigen. Zum Beispiel:

• “Edit src/lib/auth.ts and use lib/email/sendEmail.ts.”

Das nimmt unnötiges Raten aus dem Prozess und reduziert erfundene Abstraktionen.

Formuliere deine Verifizierungs-Policy von Anfang an klar

Bei email-and-password-best-practices-Arbeit sorgt ein einziger fehlender Satz oft für viel unnötige Schleifen:

• “Users must verify email before first sign-in.”

oder

• “Users can sign in before verification, but we still send verification email.”

Wenn du das nicht festlegst, ist die Implementierung möglicherweise sicher, aber trotzdem falsch für dein Produkt.

Bitte um Ende-zu-Ende-Ausgabe, nicht nur um Konfiguration

Eine stärkere Anfrage ist:

• “Configure the backend and show the frontend/user flow, email triggers, migration command, and manual test plan.”

So vermeidest du unvollständige Ergebnisse, bei denen zwar der Auth-Server konfiguriert ist, aber unklar bleibt, wie Nutzer den Flow tatsächlich abschließen.

Achte auf typische Fehlermuster

Häufige Probleme bei der Nutzung dieses Skills sind:

• der eigentliche E-Mail-Versand wird vergessen
• eigene Verifizierungslinks werden generiert, obwohl url bereits bereitgestellt wird
• Verifizierung wird aktiviert, ohne zu entscheiden, ob Sign-in blockiert werden muss
• der Reset-Password-Transport wird verdrahtet, ohne den Callback-Pfad zu testen
• Passwortregeln im Frontend stimmen nicht mit der Backend-Validierung überein

Gib Policy-Details an, wenn Passwort-Handling robust sein soll

Wenn Passwortstärke in deiner Umgebung wichtig ist, nenne die Anforderungen exakt. „Use strong passwords“ ist zu vage. Bessere Prompts nennen Länge, verbotene Muster, Erwartungen an Reset-Verhalten und ob bestehende Nutzer sofort compliant sein müssen oder erst bei Änderung/Reset.

Bitte den Agenten, Trade-offs zu erklären statt nur Code zu patchen

Gute Ergänzung für den Prompt:

• “Explain why you kept defaults or changed hashing settings, and note any security/usability tradeoffs.”

Das verbessert die Reviewbarkeit und hilft Teams, Cargo-Cult-Sicherheitsänderungen zu vermeiden.

Iteriere nach dem ersten Entwurf mit konkreten Fehlerfällen

Nachdem der Agent eine erste Implementierung erzeugt hat, kannst du sie gezielt verbessern, zum Beispiel mit:

• “Now review this for unverified-user edge cases.”
• “Add manual test cases for expired reset links.”
• “Check whether password validation is consistent between sign-up and reset.”

Oft zahlt sich die email-and-password-best-practices install-Entscheidung genau in diesem zweiten Durchgang aus, weil der Skill die Iteration an echtem Better Auth-Verhalten orientiert hält statt an generischen Auth-Ratschlägen.