Utilizzo della sola password per autenticare l'utente (nessun campo "username")

Il problema principale con l'utilizzo della sola password è che non puoi applicare sali .

In un normale server robusto che autentica gli utenti tramite password, le password non vengono memorizzate "come sono" ma hash . Il processo di hashing della password richiede un po 'di attenzione, perché un utente malintenzionato che ottiene una copia di quel file con password hash (ad esempio attraverso un attacco SQL injection) può eseguire un attacco dizionario : questo è" provare "potenziali password. Gli utenti umani tendono a scegliere password che sono "parole" in una lingua, o derivate semplici da quella (ad esempio aggiungendo una cifra), da cui il termine "dizionario".

Per rendere l'operazione più difficile per l'utente malintenzionato, il processo di hashing della password deve:

1. essere intrinsecamente lento imponendo, ad esempio, un milione di invocazioni di funzioni hash annidate;
2. essere salted : il sale è un parametro che altera il modo in cui funziona l'hashing e ogni password hash ha il proprio valore salt. In questo modo, quando l'utente malintenzionato tenta una potenziale password, deve prima scegliere quale password hash avrà come target.

Il nome utente è il selettore di sale: quando il server riceve il nome utente, lo cerca nel suo database, ottenendo la password hash e il valore salt che è stato usato per calcolare quell'hash ( entrambi sono memorizzati insieme). Ciò consente al server di ricalcolare l'hash, iniziando con quel valore salt e la password che l'utente ha fornito. Se il server ottiene lo stesso valore di hash di quello che è stato memorizzato, l'utente viene autenticato; in caso contrario, l'utente viene rifiutato. Buoni algoritmi per questo sono bcrypt e PBKDF2 . Preferisco bcrypt ( ma PBKDF2 non è male).

Senza nome utente, senza sale. Il server non può sapere quale valore di sale usare per la password specifica, quindi deve utilizzare lo stesso sale (cioè senza sale) per tutte le password memorizzate. Ciò consente agli aggressori di attaccare tutte le password contemporaneamente, il che è molto più efficiente.

È più semplice vederlo se pensi a un attacco di dizionario online , in cui l'utente malintenzionato cerca potenziali password sul tuo server. Con un nome utente + una password, l'utente malintenzionato deve inviare un nome utente e una password e ha successo se l'utente con quel nome ha effettivamente tale password . Senza il nome utente, l'autore dell'attacco invia semplicemente una potenziale password e riesce se qualsiasi utente sul sistema ha quella password. Se hai 1000 utenti, hai appena reso l'attacco 1000 volte più facile.

Inoltre, quando un nuovo utente si registra, sceglie la sua password. Se tale password si scontra con quella di un altro utente, non hai altra scelta che rifiutare la registrazione. A quel punto, il nuovo utente ha appena saputo che la password che voleva usare è già una password valida per un altro utente - hai appena trasformato il nuovo utente in un attaccante di successo, e lo sa ... .

Va bene, devo ricordare non per rispondere alla domanda dopo aver mangiato, ma prima del caffè. Ho appena notato che le tue "password" sono in realtà UUID con 122 bit di entropia generata casualmente. In tal caso, le cose andranno meglio. Non chiameremmo queste "password" UUID, dal momento che non sono "parole" e non sono scelte da un essere umano, né nemmeno ricordate da un essere umano. Questi sono token di autenticazione .

Continuerete a fare le vostre transazioni su SSL. Inoltre, poiché i clienti non li ricordano , li scriveranno, in file o su carta (più probabilmente file, in modo che possano tagliarli e incollarli - nessuno vuole digitare l'intero UUID su una base regolare). Ciò rende più difficile mantenere la segretezza di questi UUID. I tuoi clienti dovranno assumersi la responsabilità di mantenere segreti questi valori; questo potrebbe essere un po 'troppo chiedere a un cliente tipico.

Suggerirei di attenersi a un paio di stringhe, utente / password, pubblico / privato, a prescindere da come lo chiamiamo.

Sebbene non ci sia praticamente nessuna possibilità di collisione, non vedo ragioni per cui un'autenticazione basata esclusivamente su password possa essere migliore. D'altra parte, con una coppia di chiavi, quella pubblica potrebbe essere un ID fisso dell'utente, - consentendo un sacco di cose, come la registrazione -, non importa quante volte la password viene cambiata.

Non l'hai menzionato esplicitamente, ma ho l'impressione che tu salvi le credenziali (dal momento che "non è inteso per essere ricordato", proprio come le chiavi API), quindi non avrebbe importanza per il user quale metodo usi.

Dovresti avere un ID utente separato e amp; password in modo da poter cambiare la password se richiesto o desiderato senza modificare l'id utente. Assumerei i requisiti di controllo necessari per monitorare l'utente che esegue determinate attività, il che significa che l'utente dovrà autenticarsi (fornire la propria password), quindi un UUID nascosto specifico per PC sarà insufficiente.

La mia risposta su una domanda si applica anche qui:

Il semplice concetto di base che manca:

Identification and Authentication are not the same thing.

In parole povere, questi sono due requisiti separati e non devono essere confusi.
Un nome utente fornisce l'identificazione e una password consente di verificare l'identità richiesta (cioè l'autenticazione).

Ora, nel tuo schema proposto, la situazione è leggermente diversa - poiché ti aspetti che la "password" sia irrinunciabile, stai effettivamente cercando di implementare ciò che alcuni hanno definito un debole "qualcosa che hai "- poiché questo URL deve essere recuperato una volta e (presumo) salvato come preferito / preferito, l'accesso al desktop dell'utente presumibilmente controlla l'accesso all'account dell'utente.

Tuttavia, ci sono ancora alcuni problemi con questo:

• La "password" non può essere facilmente modificata (come è stato menzionato);
• La "password" non può essere facilmente hash, a causa del problema di recupero menzionato da @Thomas;
• è un fattore debole , a seconda del sistema che potresti non voler affidare alla sicurezza della macchina dell'utente;
• alcuni browser correnti sincronizzano le impostazioni del browser, inclusi i preferiti, su tutti i dispositivi. Ciò consentirebbe in effetti l'accesso a tutti i dispositivi sincronizzati;
• Poiché la "password" è nell'URL, questa potrebbe essere esposta tramite la cronologia o la cache del browser (ci sono attacchi che consentono di accedervi anche senza l'accesso fisico alla macchina dell'utente);
• Molte impostazioni causano la registrazione dell'URL, come i log del server web, i proxy inversi, ecc.
• Accesso HTTP accidentale (invece di HTTPS - anche se si reindirizza, l'utente continuerà a fare clic su quel segnalibro, dal momento che arriva comunque al sito in entrambi i modi ...).

Potrei andare avanti, trovando ulteriori scenari in cui sarebbe possibile esporre tale "password". Se si desidera evitare qualsiasi autenticazione basata su password, sarebbe meglio rilasciare solo certificati lato client e archiviare gli utenti. Il supporto del browser per quelli è abbastanza maturo (se non trasparente o banale) e i protocolli sono già in atto per supportare questo in modo sicuro.