--- title: "Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa" description: "260.000 APP_KEY Laravel esposte su GitHub. La rotazione graceful e il rehashing automatico in Laravel 11/12 sono misure di sicurezza non più rimandabili." canonical: "https://www.mauriziofonte.it/blog/post/laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.html" author: "Maurizio Fonte" date: "2025-02-14T10:04:55+01:00" modified: "2026-04-14T17:48:55+02:00" section: "Laravel" tags: ["Laravel", "Sicurezza Applicazioni"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) # [Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa](https://www.mauriziofonte.it/blog/post/laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.html) Venerdì 14 Febbraio 2025, alle 10:04 ![Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa](https://www.mauriziofonte.it/image/001360200-laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.jpg) In una piattaforma marketplace con migliaia di utenti attivi, l'`APP_KEY` Laravel non era stata ruotata dal giorno dell'installazione - cinque anni prima. Le password degli utenti erano hashate con bcrypt a 10 round, il valore di default al momento dello sviluppo iniziale. Nessuno dei due aspetti era percepito come un problema: "funziona, non tocchiamo nulla." Una ricerca congiunta [GitGuardian/Synacktiv](https://blog.gitguardian.com/exploiting-public-app_key-leaks/) pubblicata nel luglio 2025 ha dimostrato quanto questa percezione sia pericolosa: 260.000 `APP_KEY` Laravel sono state trovate esposte su GitHub, e oltre 600 applicazioni sono risultate vulnerabili a Remote Code Execution (RCE) tramite deserializzazione di payload crittografati con la chiave nota - un attacco documentato fin dal 2018 (CVE-2018-15133) ma ancora sfruttabile su migliaia di installazioni. ## Perché la rotazione dell'APP_KEY è un'operazione di sicurezza critica? L'`APP_KEY` è la chiave crittografica che Laravel usa per tutte le operazioni di crittografia e firma: cookie di sessione, token XSRF, dati crittografati con il facade `Crypt`, URL firmati. Un attaccante che la conosce può forgiare cookie di sessione validi (session hijacking), decrittografare qualsiasi dato protetto con `Crypt::encrypt()`, e in molte configurazioni ottenere RCE tramite deserializzazione di oggetti PHP. La ricerca Synacktiv ha analizzato 625.059 cookie XSRF-TOKEN raccolti via Shodan, trovando che il 3,56% delle istanze Laravel pubbliche era compromettibile con chiavi note - molte provenienti da template commerciali CodeCanyon che distribuiscono la stessa `APP_KEY` a migliaia di installazioni. Prima di Laravel 11, ruotare l'`APP_KEY` significava invalidare tutte le sessioni attive e rendere illeggibili tutti i dati crittografati nel database. Laravel 11 ha introdotto la [rotazione graceful](https://laravel.com/docs/12.x/encryption): la variabile `APP_PREVIOUS_KEYS` nel file `.env` accetta una lista di chiavi precedenti, separate da virgola. Quando Laravel deve decrittografare un valore, prova prima con la chiave corrente; se fallisce, itera sulle chiavi precedenti. Le nuove crittografie usano sempre la chiave corrente: ```text ; dopo la rotazione: nuova chiave attiva, vecchia in fallback APP_KEY=base64:nuovaChiaveGenerata...== APP_PREVIOUS_KEYS=base64:vecchiaChiaveOriginale...== ``` Il processo operativo: salvare la chiave corrente, eseguire `php artisan key:generate`, spostare la vecchia chiave in `APP_PREVIOUS_KEYS`, deployare. Le sessioni attive continuano a funzionare, i dati crittografati restano leggibili. Come fase successiva - non urgente ma consigliata - un comando Artisan custom può re-crittografare i dati nel database con la nuova chiave, permettendo di rimuovere le chiavi precedenti da `APP_PREVIOUS_KEYS`. ## Rehashing automatico delle password: da bcrypt a Argon2id L'[OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) classifica esplicitamente bcrypt come opzione "legacy systems only" - la raccomandazione primaria è Argon2id, un algoritmo memory-hard che resiste sia ad attacchi GPU che ad attacchi ASIC. Le [linee guida NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final), pubblicate nel luglio 2025, raccomandano l'uso di funzioni memory-hard per il password hashing. Laravel 11 ha introdotto il rehashing automatico: quando un utente si autentica tramite `Auth::attempt()`, il framework verifica se l'hash memorizzato è stato generato con i parametri correnti di `config/hashing.php`. Se i parametri non corrispondono - bcrypt con round inferiori, o un algoritmo diverso - la password viene ri-hashata in modo trasparente e salvata nel database. La configurazione per abilitare Argon2id: ```php // config/hashing.php return [ 'driver' => env('HASH_DRIVER', 'argon2id'), 'bcrypt' => [ 'rounds' => env('BCRYPT_ROUNDS', 12), 'verify' => true, ], 'argon2id' => [ 'memory' => 65536, // 64 MiB (OWASP minimum: 19 MiB) 'time' => 4, 'threads' => 1, 'verify' => true, ], ]; ``` Con questa configurazione, al prossimo login ogni utente con hash bcrypt verrà automaticamente migrato ad Argon2id - senza email di reset, senza migrazione batch, senza interruzioni. L'unico prerequisito tecnico è che il modulo PHP `sodium` (o `libargon2`) sia compilato e disponibile, e che la colonna `password` nella tabella `users` sia `VARCHAR(255)` (l'hash Argon2id è più lungo di quello bcrypt). ## Errori che compromettono la sicurezza delle credenziali Il primo errore è non ruotare mai l'`APP_KEY`. Ogni applicativo Laravel dovrebbe avere una procedura documentata di rotazione - almeno annuale, e immediatamente dopo qualsiasi sospetto di esposizione del file `.env`. Con `APP_PREVIOUS_KEYS` disponibile da Laravel 11, non ci sono più scuse operative per rimandare. Il secondo è aumentare i parametri di hashing senza verificare l'impatto sulle performance. Argon2id con `memory: 65536` e `time: 4` aggiunge circa 100-200ms al processo di login su un server standard - accettabile per un login interattivo, ma potenzialmente problematico se l'applicativo esegue hashing in batch (importazione utenti, API di registrazione ad alto volume). Testare con `time php -r "password_hash('test', PASSWORD_ARGON2ID, ['memory_cost' => 65536, 'time_cost' => 4, 'threads' => 1]);"` prima del deploy in produzione. Il terzo è dimenticare i dati crittografati con `Crypt` quando si pianifica la rotazione della chiave. La rotazione graceful copre la decrittografia in fallback, ma i dati nel database restano crittografati con la vecchia chiave finché non vengono esplicitamente ri-crittografati. Se la vecchia chiave viene rimossa da `APP_PREVIOUS_KEYS` prima della ri-crittografia, quei dati diventano inaccessibili. Un [audit di sicurezza](https://www.mauriziofonte.it/blog/post/audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.html) dovrebbe includere un inventario di tutti i campi crittografati con `Crypt` nel database. Il quarto è esporre l'`APP_KEY` in repository Git, file di log, pagine di debug o screenshot condivisi. La ricerca GitGuardian ha trovato chiavi esposte non solo in file `.env` committati, ma anche in screenshot di errori Laravel postati su Stack Overflow e in issue GitHub. La [compliance GDPR e NIS2](https://www.mauriziofonte.it/blog/post/applicativi-php-gdpr-nis2-pmi-compliance-sicurezza-laravel-symfony.html) richiede misure tecniche adeguate alla protezione dei dati - un'`APP_KEY` esposta invalida qualsiasi crittografia applicativa dichiarata nella privacy policy. La sicurezza delle credenziali non è un'operazione una tantum ma un processo che segue l'evoluzione degli standard crittografici e del panorama delle minacce. Laravel 11 e 12 forniscono gli strumenti - [rotazione graceful](https://laravel.com/docs/12.x/encryption) e [rehashing automatico](https://laravel.com/docs/12.x/hashing) - ma la responsabilità di attivarli e integrarli nel ciclo di manutenzione resta dell'operatore. L'[hardening del server](https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html) che ospita l'applicativo è il complemento infrastrutturale indispensabile. Per conoscere il mio approccio alla sicurezza applicativa Laravel, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se la tua `APP_KEY` non è mai stata ruotata e le password dei tuoi utenti sono hashate con parametri di anni fa, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dalla verifica dello stato crittografico attuale. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteRefactoring applicazione Laravel 10: guida passo-passo per adottare la struttura snella di Laravel 12 e centralizzare la configurazione13 Febbraio 2025](https://www.mauriziofonte.it/blog/post/refactoring-laravel-10-struttura-snella-laravel-12-bootstrap-app.html)[Articolo successivo »Modernizzare i Model Eloquent Laravel: guida al refactoring da $casts array (L9/L10) al potente metodo casts() in Laravel 1217 Febbraio 2025](https://www.mauriziofonte.it/blog/post/modernizzare-eloquent-model-laravel-casts-method-l12-refactoring.html) ### Articoli correlati a Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa - [Applicazione Laravel compromessa via APP_KEY su GitHub: forensics, contenimento e ripristino in cinque giorni](https://www.mauriziofonte.it/blog/post/ripristino-laravel-attacco-informatico-emergenza.html) Un CRM Laravel 9 per una PMI logistica veneta è stato compromesso perché un file .env con l'APP KEY era stato committato su un repository GitHub · 30 Giugno 2025 ![Applicazione Laravel compromessa via APP_KEY su GitHub: forensics, contenimento e ripristino in cinque giorni](https://www.mauriziofonte.it/image/001900070-ripristino-laravel-attacco-informatico-emergenza.jpg) - [Applicativi PHP, GDPR e NIS2: come la tua PMI può garantire compliance e sicurezza con Laravel e Symfony](https://www.mauriziofonte.it/blog/post/applicativi-php-gdpr-nis2-pmi-compliance-sicurezza-laravel-symfony.html) GDPR e NIS2 richiedono misure tecniche concrete negli applicativi PHP. Laravel e Symfony offrono crittografia, access control, logging e gestione · 30 Gennaio 2025 ![Applicativi PHP, GDPR e NIS2: come la tua PMI può garantire compliance e sicurezza con Laravel e Symfony](https://www.mauriziofonte.it/image/001320070-applicativi-php-gdpr-nis2-pmi-compliance-sicurezza-laravel-symfony.jpg) - [Conformità GDPR nelle applicazioni Laravel: dove le PMI sbagliano e come correggere prima di un'ispezione](https://www.mauriziofonte.it/blog/post/gestione-urgente-gdpr-laravel-sicurezza.html) La maggior parte delle applicazioni Laravel nelle PMI italiane viola il GDPR in almeno tre punti: dati personali in chiaro, log senza retention · 24 Giugno 2025 ![Conformità GDPR nelle applicazioni Laravel: dove le PMI sbagliano e come correggere prima di un'ispezione](https://www.mauriziofonte.it/image/001850070-gestione-urgente-gdpr-laravel-sicurezza.jpg) - [Penetration testing di un'applicazione Laravel: metodologia e vulnerabilità tipiche](https://www.mauriziofonte.it/blog/post/penetration-testing-applicazione-laravel-metodologia-vulnerabilita.html) In un recente assessment su un gestionale Laravel per una PMI manifatturiera, ho trovato mass assignment non protetto, IDOR su quattro endpoint · 8 Ottobre 2025 ![Penetration testing di un'applicazione Laravel: metodologia e vulnerabilità tipiche](https://www.mauriziofonte.it/image/002650070-penetration-testing-applicazione-laravel-metodologia-vulnerabilita.jpg) - [Modernizzare un gestionale finanziario PHP 5.4 sotto vincolo NIS2: quattro mesi per portare a compliance un sistema di 93.000 righe con dati di 11.000 clienti](https://www.mauriziofonte.it/blog/post/modernizzazione-php-legacy-settore-finanziario-nis2-dora-compliance.html) Gestionale PHP 5.4 di un intermediario creditizio: 93.000 righe, dati di 11.000 clienti, password in MD5, zero cifratura, backup su disco USB. · 18 Febbraio 2026 ![Modernizzare un gestionale finanziario PHP 5.4 sotto vincolo NIS2: quattro mesi per portare a compliance un sistema di 93.000 righe con dati di 11.000 clienti](https://www.mauriziofonte.it/image/002330070-modernizzazione-php-legacy-settore-finanziario-nis2-dora-compliance.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.html Pubblicato: 2025-02-14 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.