Accedi con un hash. È abbastanza sicuro?

Naviga le tue risposte
3

Devo fornire ai clienti del negozio uno strumento per verificare lo stato dei loro ordini di riparazione.
I client non hanno un utente o una password. Sono solo un record nel database. Eppure ho bisogno di dare loro un modo per accedere alla pagina web e controllare il loro stato (pronto o meno). Costringere quindi a registrarsi non è un'opzione.

Sono arrivato con questa idea:

  • All'utente viene richiesto il suo indirizzo email
  • Il sistema controlla se questa e-mail è registrata nel database, genera un hash e invia un e-mail speciale con l'hash.
  • Il controllo utente è l'email e va a questo indirizzo
  • Quando il sistema riceve una richiesta all'indirizzo speciale verifica se l'hash è nel database e recupera l'id_utente
  • Se è presente, voilà! Ciao John Doe Il tuo ordine # 3454364 è pronto per essere prelevato

L'algoritmo di generazione hash sarebbe. 

SELECT clients set hash = SUBSTRING(PASSWORD(UUID()), 2);

L'hash / password è salata e Bcrypt (ed) nel server.
Potrei aggiungere un timeout (hash valido per 1 giorno o qualcosa del genere)

C'è qualcosa di terribilmente sbagliato in questa idea?

UPDATE: Corretto il testo in modo che sia meno confuso.

Quale fattore di lavoro dovrei usare per Bcrypt? Sembra essere come l'idea generale è di aumentare il numero fino a quando ci vuole ~ 1 secondo.

Mi piace l'output di PASSWORD di MySQL per la generazione di hash perché è molto intuitivo. Ma questa è davvero l'unica ragione. Qualche altro suggerimento?

    
posta The Disintegrator 18.05.2013 - 09:32
fonte

2 risposte

3

L'idea stessa va bene, i tuoi utenti stanno eseguendo azioni non critiche usando un URL speciale. Tuttavia, ci sono due cose che potrebbero andare storte qui:

  • Il tuo identificatore è SUBSTRING(PASSWORD(UUID()), 2) , il problema è che UUID() non è molto affidabile per generare identificatori imprevedibili e non guidabili.

WARNING: Although UUID() values are intended to be unique, they are not necessarily unguessable or unpredictable. If unpredictability is required, UUID values should be generated some other way.

È molto meglio generare identificatori casuali basati sull'output di /dev/urandom

  • Non usando SSL (HTTPS) l'identificatore univoco verrà trasmesso in chiaro (e lo stato dell'ordine per quella materia) e quindi verrà esposto per chiunque stia annusando la connessione del tuo client.

Ma tutto sommato, dico che è una soluzione piuttosto buona per il tuo scopo.

    
risposta data 18.05.2013 - 09:48
fonte
4

Per il livello di sicurezza che il tuo servizio sembra richiedere, direi che sembra una soluzione ragionevole.

I rischi sono che qualcuno intercetterà un collegamento e avrà accesso alle informazioni dei clienti, quindi è necessario assicurarsi che l'accesso alla pagina di stato sia crittografato tramite SSL.

Per il timeout potresti scegliere l'approccio che hai (basato sul tempo) che sembra ragionevole date le circostanze, oppure puoi impostare ogni hash per essere usato una sola volta (cioè l'hash deve essere creato ogni volta che il cliente lo utilizza)

Un'alternativa che ho visto usata per questo tipo di sistema che è un po 'meno sicuro ma più facile da usare per i clienti, è quella di richiedere informazioni sull'ordine (ad esempio ID ordine, cognome cliente, codice postale cliente). Questo elimina il passaggio della posta elettronica, ma è suscettibile a un attacco di forza bruta.

La sicurezza che vuoi dipende in gran parte da quanto sono sensibili le informazioni e da quanto sarebbero irritati i clienti se qualcun altro dovesse accedervi.

    
risposta data 18.05.2013 - 09:48
fonte

Leggi altre domande sui tag

Autorizzazione dell'uso di app da un negozio pubblico senza alcun servizio di back-end Quanto è sicuro usare un index.html / index.php vuoto? [duplicare]