Registrierung und Passwort-Hashing
Registrierung und Passwort-Hashing
~16 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Ohne Registrierung kann sich NIEMAND einloggen – Zeit, dass neue Nutzer sich selbst anmelden können, mit sicher gehashten Passwörtern.
Warum Passwörter NIEMALS im Klartext gespeichert werden
Achtung: Ein Klartext-Passwort in der Datenbank bedeutet: bei JEDEM Datenbank-Leck (Hack, Fehlkonfiguration, unachtsamer Mitarbeiterzugriff) sind ALLE Passwörter SOFORT kompromittiert – UND, da viele Nutzer Passwörter wiederverwenden, potenziell auch deren Konten bei ANDEREN Diensten. Ein Hash ist eine EINWEG-Transformation: aus dem Passwort lässt sich der Hash berechnen, aber NICHT umgekehrt.
Den Registrierungs-Controller erstellen
php bin/console make:registration-formFragt interaktiv nach der User-Entity, ob E-Mail-Bestätigung gewünscht ist (für dieses Kapitel: nein, Kapitel 38 behandelt E-Mail-Versand separat) und generiert Controller, Form Type UND Template.
<?php
declare(strict_types=1);
namespace App\Form;
use App\Entity\User;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\EmailType;
use Symfony\Component\Form\Extension\Core\Type\PasswordType;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolver;
use Symfony\Component\Validator\Constraints as Assert;
class RegistrationFormType extends AbstractType
{
public function buildForm(FormBuilderInterface $builder, array $options): void
{
$builder
->add('name', TextType::class, ['label' => 'Name'])
->add('email', EmailType::class, ['label' => 'E-Mail'])
->add('plainPassword', PasswordType::class, [
'label' => 'Passwort',
'mapped' => false,
'constraints' => [
new Assert\NotBlank(message: 'Bitte geben Sie ein Passwort ein.'),
new Assert\Length(
min: 8,
minMessage: 'Ihr Passwort muss mindestens {{ limit }} Zeichen lang sein.',
),
],
])
;
}
public function configureOptions(OptionsResolver $resolver): void
{
$resolver->setDefaults(['data_class' => User::class]);
}
}'mapped' => false ist ENTSCHEIDEND: das plainPassword-Feld wird NICHT automatisch auf eine User-Eigenschaft abgebildet (die User-Entity hat schließlich nur ein GEHASHTES password-Feld, Kapitel 26) – wir lesen den Klartext-Wert manuell aus und hashen ihn selbst, statt ihn ungehasht in $user->password landen zu lassen.
Der Registrierungs-Controller
<?php
declare(strict_types=1);
namespace App\Controller;
use App\Entity\User;
use App\Form\RegistrationFormType;
use Doctrine\ORM\EntityManagerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\PasswordHasher\Hasher\UserPasswordHasherInterface;
use Symfony\Component\Routing\Attribute\Route;
class RegistrationController extends AbstractController
{
#[Route('/register', name: 'app_register')]
public function register(
Request $request,
UserPasswordHasherInterface $passwordHasher,
EntityManagerInterface $entityManager,
): Response {
$user = new User();
$form = $this->createForm(RegistrationFormType::class, $user);
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
$klartextPasswort = $form->get('plainPassword')->getData();
$user->setPassword(
$passwordHasher->hashPassword($user, $klartextPasswort)
);
$entityManager->persist($user);
$entityManager->flush();
$this->addFlash('success', 'Registrierung erfolgreich! Sie können sich jetzt anmelden.');
return $this->redirectToRoute('app_login');
}
return $this->render('registration/register.html.twig', [
'registrationForm' => $form,
]);
}
}UserPasswordHasherInterface ist ein von Symfony bereitgestellter Service (Autowiring, Kapitel 8) – hashPassword($user, $klartextPasswort) nutzt AUTOMATISCH den in security.yaml konfigurierten Algorithmus ('auto' aus Kapitel 26 wählt aktuell bcrypt oder Argon2id, je nach PHP-Umgebung).
Warum $user als erstes Argument von hashPassword()?
Manche Hash-Algorithmen (u. a. bcrypt) beziehen NUTZERSPEZIFISCHE Daten (z. B. einen "Salt") in die Berechnung ein – zwei Nutzer mit IDENTISCHEM Passwort erhalten dadurch UNTERSCHIEDLICHE Hashes in der Datenbank, was gezielte "Rainbow-Table"-Angriffe deutlich erschwert.
Das Registrierungs-Formular rendern
{% extends 'base.html.twig' %}
{% block body %}
<h1>Registrieren</h1>
{{ form(registrationForm) }}
{% endblock %}Achtung: unique: true auf dem email-Feld der Entity (Kapitel 26) verhindert DOPPELTE Registrierungen auf Datenbank-Ebene – ergänzen Sie zusätzlich einen #[Assert\Unique]- oder UniqueEntity-Constraint am Form Type, damit der Nutzer eine LESBARE Fehlermeldung statt eines rohen Datenbank-Fehlers sieht, falls die E-Mail bereits vergeben ist.