Logowanie, sesje i 2FA w Laravelu: jak chronimy konta w panelach firmowych
Najsłabszym ogniwem aplikacji często nie jest serwer, tylko hasło „Firma2024!” używane jeszcze w trzech innych serwisach. Dobre uwierzytelnianie to połączenie Laravela, polityki haseł i drugiego składnika.
Panel CRM albo księgowy to łakomy kąsek: są tam faktury, dane klientów, czasem dane kart. Atakujący nie zawsze łamie kryptografię. Częściej zgaduje hasło, kradnie sesję albo resetuje konto przez źle zrobiony e-mail. Dlatego logowanie projektujemy tak samo poważnie jak samą logikę biznesową.
Fundament: Laravel Auth, nie własny wymysł
Laravel ma gotowy, utrzymywany mechanizm rejestracji, logowania i resetu hasła. Hasła hashujemy algorytmem bcrypt albo argon2 — w bazie nie ma jawnego hasła i nie da się go „odzyskać”, tylko ustawić nowe. Reset idzie jednorazowym, wygasającym linkiem na e-mail, nigdy nowym hasłem w treści wiadomości.
Sesje i API: dwa różne światy
Panel webowy (Vue + Laravel) opieramy na sesji albo cookie Sanctum z CSRF. Aplikacja Android rozmawia z API przez tokeny Sanctum — token można unieważnić, gdy telefon zginie albo pracownik odejdzie z firmy. Nie trzymamy haseł w aplikacji mobilnej. Nie mieszamy sesji przeglądarki z tokenem mobilnym w jednym worku.
Co blokuje zgadywanie i kradzież konta
- Limit prób logowania (rate limiting) na IP i na konto — po serii błędów konto się przycina, a nie „czeka w nieskończoność”.
- Blokada prostych haseł i wymóg minimalnej długości; przy panelach z danymi finansowymi — dodatkowo 2FA.
- Wygasanie sesji przy bezczynności i wylogowanie na wszystkich urządzeniach po zmianie hasła.
- Ostrzeżenie e-mail przy logowaniu z nowej lokalizacji albo nowej przeglądarki (tam, gdzie to ma sens).
- Brak szczegółowego komunikatu „nie ma takiego e-maila” — atakujący nie enumeruje kont.
2FA, które ludzie naprawdę włączą
Dwuskładnikowe logowanie opieramy na TOTP (aplikacja authenticator) albo kodzie SMS, zależnie od branży. Dla administratorów i księgowości 2FA jest obowiązkowe, nie opcjonalne. Kody zapasowe trafiają do klienta raz, przy aktywacji — nie wysyłamy ich potem mailem „na wszelki wypadek”.
Uprawnienia po zalogowaniu
Zalogowanie to dopiero początek. W Laravelu policies i gates decydują, czy użytkownik może zobaczyć fakturę, wyeksportować bazę albo zmienić rolę kolegi. Testujemy to automatycznie: scenariusz „handlowiec nie pobierze raportu płac” ma być zielony na CI, nie tylko „wydaje się, że w menu nie ma linku”.
Jeśli Twój obecny panel ma wspólne konto „biuro” albo hasła w Excelu — to pierwszy temat do rozmowy, jeszcze przed nowymi funkcjami. Opisz, kto i do czego ma mieć dostęp. Zaprojektujemy logowanie pod realne ryzyko, nie pod checklistę z internetu. Więcej o tle zagrożeń jest w artykule o OWASP i Laravelu.
Opisz projekt