Il mio metodo di autenticazione utente è sicuro? Sto reinventando la ruota?

Sai cosa non dovresti fare? Reinventare la ruota.

Ci sono molte librerie di autenticazione là fuori, specialmente per PHP. Quasi ogni singolo framework include uno. Usalo . Se non stai usando un framework, interrompi ciò che stai facendo e usane uno!

E sì, devi utilizzare TLS per il tuo sito.

Non dovresti mai tirare il tuo. C'è una cosiddetta "legge Schneier" che afferma:

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.

Questo significa che anche dopo aver fallito nel tentativo di rompere il tuo schema, un esperto l'ho spezzato in due secondi. Dai un'occhiata a questo articolo di Schneier.

Ci sono migliaia di metodi funzionanti e dovresti usarli, molti di questi sono stati testati da esperti di sicurezza e crittografia.

Inoltre, dovresti leggere questo Q & A.

I can't use openid because my auth is not based on email id

OpenID non dipende dall'e-mail: un'identità OpenID potrebbe essere qualcosa come someone.example.com .

Then insert ( useragent, ip, unique key which i create ). into a database.

Non è saggio legare le sessioni all'indirizzo IP. Gli indirizzi IP di alcuni utenti variano in modo legittimo (ad esempio perché si trovano dietro un cluster proxy o stanno passando da una rete mobile all'altra). Dare dei calci in cambio di IP renderebbe il tuo sito molto difficile da usare per un sottoinsieme del tuo pubblico.

L'IP di corrispondenza è in ogni caso di utilità molto limitata. Il solito attacco che sta tentando di risolvere è quello della perdita di token di sessione e il riutilizzo da un client malintenzionato. Tuttavia, le possibili cause di perdita di token sono generalmente quelle che consentono all'aggressore di effettuare richieste dal client (XSS, malware sul lato client, cattiva sicurezza del trasporto) o quelli che sono già catastrofici (compromissione del database, esecuzione del codice del server).

Allo stesso modo, la corrispondenza User-Agent ha poco valore in quanto la stringa UA non è un tipo di segreto ed è facilmente falsificata. La corrispondenza tra IP e UA può essere di qualche valore come un solo input per un complesso sistema di classificazione del rischio con una storia comportamentale, ma la corrispondenza primitiva è inefficace come misura di sicurezza e può causare più danni da falsi negativi che benefici.

Time stamp + ip + useragent + username and encrypt them many rounds = unique key !

Encrypt type = MCRYPT_RIJNDAEL_256

Then insert ( useragent, ip, unique key which i create ). into a database.

set the unique key in cookie and transmit it to user.

Poiché la "chiave univoca" inviata dal client viene verificata semplicemente confrontandola con il valore conosciuto nel database, il suo contenuto effettivo non ha alcuna rilevanza e non ha senso generarlo in modo così elaborato.

Una stringa di dati casuali farebbe altrettanto bene per questo, e quindi quello che avresti sarebbe funzionalmente equivalente al modo normale in cui gli utenti effettuano gli accessi in PHP: inserendo un ID utente registrato nella sessione . Riutilizzare le sessioni standard basate su PHPSESSID random di PHP avrebbe vantaggi in termini di prestazioni e la natura ben compresa della loro configurazione.

Esiste un altro modello di autenticazione un po 'comune, che potrebbe essere quello che stavi pensando con l'idea della "chiave unica". Qui è dove si crea un token in base agli elementi che si desidera autenticare (in genere ID utente, numeri di generazione di password / ripristino e tempo di scadenza del token) insieme a una firma crittografica su tali elementi (in genere HMAC) utilizzando una chiave segreta lato server. Il server può riconoscere e autenticare il token in entrata usando quella firma, dandogli il vantaggio che non ha bisogno di alcuna memoria persistente di database / sessione. Ma a meno che tu non abbia bisogno di quella particolare proprietà, rimango con semplici vecchie sessioni.

i think using TLS is must here

Sì. E ricorda di dare ai tuoi cookie il flag secure in modo che non trapelino attraverso una richiesta non TLS.

Le risposte precedenti che suggeriscono di non reinventare la ruota auth'ENTICation manca completamente il punto che stai creando un token auth'ORIZ'ation. La ruota migliore per i token di autorizzazione credo sia quella di utilizzare qualcosa come HMAC + SHA2.

Minor nit, non usare il timestamp della creazione ma una volta scaduto il token. E se possibile, non usare il login a meno che tu non ne abbia davvero bisogno. Dovrebbe essere applicato il principio del privilegio minimo, quindi per creare un token di autorizzazione per un servizio REST di logica aziendale che non ha bisogno di un nome utente, non fornirlo e non includerlo nella generazione di token auth.

Quindi finirai con qualcosa del tipo:

authkey = base64 (hmac (sha224, concat (scadenza, ip, useragent), tasto segreto))