Sichere Authentifizierung in Rust: Schreiben eines geschützten Backends

Warum Rust die ideale Wahl für Authentifizierung ist?

Wenn Sie eine Webanwendung in Rust schreiben, sind Sie der Sicherheit bereits einen Schritt voraus. Rust verzeiht keine Speicherfehler, daher werden viele Schwachstellen (Pufferüberlauf, Use-after-free) bereits zur Kompilierzeit ausgeschlossen. Aber der Compiler schützt Sie nicht vor schlechter Authentifizierungslogik. Genau darum geht es – wie man eine sichere Authentifizierung in Rust mit modernen Praktiken aufbaut.

In diesem Artikel erstellen wir ein vollständiges Authentifizierungsmodul: Passwort-Hashing mit bcrypt, Ausstellung von JWT-Tokens, Middleware-Prüfung in Actix-web und Schutz vor typischen Angriffen. Der Code ist funktionsfähig – Sie können ihn bedenkenlos in Ihrem Projekt verwenden.

1. Passwort-Hashing: Warum bcrypt und nicht SHA-256?

Viele Anfänger denken: „Ich nehme SHA-256, es ist schnell und zuverlässig.“ Und das ist ein fataler Fehler. SHA ist eine kryptografische Hash-Funktion, aber sie ist zu schnell. Ein Angreifer kann Milliarden von Kombinationen pro Sekunde durchprobieren. Wir brauchen eine langsame Funktion, die speziell für Passwörter entwickelt wurde.

bcrypt ist der Goldstandard. Es enthält ein „Salt“ und einen „Kostenfaktor“ (Cost Factor), der mit steigender Rechenleistung erhöht werden kann.

bcrypt zu Cargo.toml hinzufügen

[dependencies]\nbcrypt = "0.15"

Passwort hashen

use bcrypt::{hash, verify, DEFAULT_COST};\n\nfn hash_password(plain: &str) -> Result<String, bcrypt::BcryptError> {\n    hash(plain, DEFAULT_COST) // cost = 12 (Standard)\n}\n\nfn verify_password(plain: &str, hashed: &str) -> bool {\n    verify(plain, hashed).unwrap_or(false)\n}

Beachten Sie: verify extrahiert das Salt automatisch aus dem Hash. Sie müssen das Salt nicht separat speichern – es ist bereits im Hash-String enthalten. Das ist sicher und praktisch.

2. JWT-Tokens: Wie man die Authentifizierung nicht vermasselt

Nachdem der Benutzer sein Passwort eingegeben hat, müssen wir ihm einen „Passierschein“ ausstellen. JWT (JSON Web Token) ist ein kompaktes und eigenständiges Format. Aber der Teufel steckt im Detail:

\n
• Speichern Sie den geheimen Schlüssel nicht im Code. Verwenden Sie Umgebungsvariablen.
\n
• Legen Sie eine kurze Lebensdauer fest. Access-Token – 15–30 Minuten, Refresh-Token – 7–30 Tage.
\n
• Fügen Sie keine sensiblen Daten in die Payload ein. Nur Benutzer-ID und Rolle.
\n

Implementierung von JWT mit jsonwebtoken

use jsonwebtoken::{encode, decode, Header, Validation, EncodingKey, DecodingKey};\nuse serde::{Serialize, Deserialize};\nuse chrono::{Utc, Duration};\n\n#[derive(Debug, Serialize, Deserialize)]\npub struct Claims {\n    pub sub: String,       // Benutzer-ID\n    pub exp: usize,        // Ablaufzeitstempel\n    pub iat: usize,        // Ausstellungszeitstempel\n}\n\npub fn create_token(user_id: &str, secret: &str) -> Result<String, jsonwebtoken::errors::Error> {\n    let now = Utc::now();\n    let claims = Claims {\n        sub: user_id.to_owned(),\n        exp: (now + Duration::minutes(30)).timestamp() as usize,\n        iat: now.timestamp() as usize,\n    };\n    encode(&Header::default(), &claims, &EncodingKey::from_secret(secret.as_bytes()))\n}\n\npub fn validate_token(token: &str, secret: &str) -> Result<Claims, jsonwebtoken::errors::Error> {\n    let token_data = decode::<Claims>(\n        token,\n        &DecodingKey::from_secret(secret.as_bytes()),\n        &Validation::default(),\n    )?;\n    Ok(token_data.claims)\n}

3. Alles zusammenfügen: Actix-web + Middleware

Jetzt verbinden wir Hashing und JWT in einer vollständigen Webanwendung mit Actix-web. Wir schreiben eine Middleware, die das Token bei jeder geschützten Anfrage überprüft.

Projektstruktur

src/\n├── main.rs\n├── auth.rs       # Hashing, JWT\n├── middleware.rs # Token-Prüfung\n└── handlers.rs   #