"Remember me" cookies - li ho implementati in modo sicuro?

Stai complicando la soluzione, e non ne guadagni davvero molto. Altri hanno superato i difetti con la tua implementazione, ma descriverò un approccio migliore.

Quando un utente sceglie di ricordare la sua autenticazione attraverso le sessioni del browser, usa un CSPRNG per generare una stringa casuale a 128 bit. Invia loro questa stringa, quindi esegui l'hash (SHA-2/256 va bene) e memorizza l'hash accanto al record dell'utente. Quando l'utente rivisita il tuo sito, cancella il token che ha fornito e cerca il record utente corrispondente con quel token. Quando un utente si disconnette esplicitamente, elimina il cookie dal browser ed elimina l'hash del token dal database.

Probabilmente rilascerò i token ogni volta che un utente si autentica con uno (ad es. dovrebbero essere validi per un solo uso). E conserva la data di scadenza accanto al token hash per assicurarne la durata massima sul lato server.

Solo perché un UUID è altamente probabile che sia unico non significa che sia difficile da indovinare. Gli UUID versione 4 contengono 122 bit casuali e io lo consiglierei o versione 5 (SHA-1). Onestamente, di solito uso SHA256 o superiore e una lunga serie di numeri casuali concatenati. Quindi memorizzare l'hashcode sia nel database che in un cookie.

Non c'è molto vantaggio nel ridisegnare il token a lungo termine perché un utente malintenzionato con accesso al database probabilmente non ha bisogno di rubare le sessioni. Suppongo che potrebbe attenuare i casi d'angolo in cui l'attaccante ha autorizzazioni limitate al database o la sessione è condivisa su più endpoint.

Qual è il tuo sale? Lo stai archiviando nel database? (cattiva idea) Che cosa ti fa acquistare esattamente l'ID utente hash / salato? Non penso che sia una vulnerabilità, ma è necessario solo memorizzare il token di sessione a lungo termine (che potrebbe includere l'UUID / numero casuale, un valore salt e un nome utente). Quando l'utente si disconnetterebbe altrimenti, cerca la loro sessione corrente nel database e confronta la colonna di sessione a lungo termine con il valore nel cookie.

I eco del commento di glidersecurity sugli UUID con un link di Wikipedia: link

Con la tua soluzione attuale (se la sto leggendo correttamente), se un utente malintenzionato ottiene l'accesso al database di sola lettura, deve solo fornire i cookie in questo modo:

foreach userID in the users table:
    foreach random_number in the remember_me_cookie table:
        try to start a session with userID+random_number

per forzare brute-force una voce nel tuo sistema.