Come generare token casuali ma unici per l'autenticazione?

Usare os.urandom() è perfettamente a posto. Genera un crittograficamente sicuro flusso casuale di byte. Questo sarebbe impossibile da indovinare per chiunque.

L'utilizzo di guid() è anche piuttosto sicuro , anche se non del tutto casuale.

L'uso di XOR per codificare i parametri nel token è una cattiva idea. Per uno, è vulnerabile agli attacchi di bit flipping. Anche se l'utente non può decodificare il token, può modificare il contenuto codificato in esso. Una soluzione migliore è inviare un HMAC insieme ai dati, in modo che l'utente non possa manometterlo.

L'utilizzo di os.urandom() utilizza le fonti crittograficamente sicure accettate, quindi continua a utilizzarle se puoi, altrimenti dovrebbe esserci un altro modo per accedere alle stesse fonti casuali, o allo stesso modo sicure, nell'implementazione che stai usando ( php java ). La cosa più importante è che non può essere prevedibile, il che significa che qualsiasi tipo di semina eseguita manualmente (ad esempio utilizzando l'ora) è una cattiva idea.

Modifica: puoi chiarire cosa intendi esattamente con "usa XOR enc per memorizzare i dati nella stringa"?

Modifica 2: vorrei far notare che usando anche un casuale GUID è not un buon modo per farlo ( tranne forse in Java ). La maggior parte dei metodi di creazione di un GUID sono relativamente deterministici e, sebbene possano essere utili per evitare collisioni, l'altra caratteristica che si desidera da un token di reimpostazione della password è imprevedibilità .

can we use XOR enc to store data in the string itself to optimize the DB queries?

Sì, ma non sarà più chiamato token, ma piuttosto un ticket (se si utilizza una crittografia simmetrica) o un certificato (se si utilizza la crittografia simmetrica). Come token, ticket e certificati sono stringhe utilizzate per l'autenticazione, ma in realtà contengono dati crittografati e / o crittografati, anziché solo un numero casuale.

Il server emette un ticket / certificato, crittografando tutti i dettagli di autenticazione come chi è l'utente e le relative autorizzazioni, un timestamp e un periodo di validità e, eventualmente, un salt. Per autenticare, il server decrittografa il ticket / certificato e convalida questi valori. I ticket e i certificati vengono spesso utilizzati nell'autenticazione distribuita senza un server centrale o in cui il server centrale potrebbe non essere raggiungibile dall'applicazione.

I biglietti e i certificati sono più difficili da implementare in modo sicuro, rispetto ai token; ma a causa della loro natura decentralizzata, possono scalare meglio ed essere utilizzabili in situazioni in cui l'autenticazione centrale non è possibile.

Tuttavia, raccomanderei qualcosa di più specifico della crittografia XOR. Mentre XOR è una parte di molti algoritmi di flusso, la parte più difficile nel fare la crittografia XOR sta generando il flusso pseudo casuale che hai usato per XOR sui dati.