Login, sessions and 2FA in Laravel: how we protect accounts in company panels
The weakest link is often not the server, but the password “Company2024!” reused in three other services. Solid authentication is Laravel plus a password policy plus a second factor.
A CRM or accounting panel is a juicy target: invoices, customer data, sometimes card data. Attackers do not always break cryptography. More often they guess a password, steal a session or reset an account through a sloppy email flow. That is why we treat login as seriously as the business logic itself.
The foundation: Laravel Auth, not a homemade scheme
Laravel ships a maintained registration, login and password-reset flow. Passwords are hashed with bcrypt or argon2 — the database has no clear-text password and you cannot “recover” it, only set a new one. Reset uses a one-time, expiring email link, never a new password in the message body.
Sessions and APIs: two different worlds
The web panel (Vue + Laravel) uses a session or a Sanctum cookie with CSRF. The Android app talks to the API with Sanctum tokens — a token can be revoked if a phone is lost or an employee leaves. We do not store passwords in the mobile app. We do not mix browser sessions and mobile tokens in one bag.
What stops guessing and account takeover
- Login rate limits per IP and per account — after a burst of failures the account throttles, it does not wait forever.
- Blocked trivial passwords and a minimum length; for panels with financial data — 2FA as well.
- Idle session expiry and logout on all devices after a password change.
- An email warning on login from a new location or browser (where it makes sense).
- No precise “this email does not exist” message — attackers cannot enumerate accounts.
2FA people will actually turn on
Two-factor login is TOTP (authenticator app) or an SMS code, depending on the industry. For admins and accounting, 2FA is mandatory, not optional. Backup codes go to the client once, at activation — we do not email them later “just in case”.
Permissions after login
Being logged in is only the start. Laravel policies and gates decide whether a user can see an invoice, export the database or change a colleague’s role. We test this automatically: “a salesperson cannot download the payroll report” should be green on CI, not just “there seems to be no link in the menu”.
If your current panel shares a “office” account or keeps passwords in Excel — that is the first conversation, before new features. Describe who should access what. We will design login for the real risk, not an internet checklist. More on the threat background is in the OWASP and Laravel article.
Describe your project