Requisiti di sicurezza per codice / token di accesso singolo nell'URL

Question

Requisiti di sicurezza per codice / token di accesso singolo nell'URL

#1 da (3 voti)

3

Ho un'applicazione che invierà un promemoria SMS per l'utente che contiene un URL per accedere. Vorrei evitare che l'utente digiti username / password e lo acceda direttamente. Per questo ho intenzione di utilizzare un token di accesso e aggiungerlo all'url, ad esempio:

www.mydomain.com?token=JFPIENBFIOHGDFGP3423432

Ora dal momento che si tratta di un SMS, non posso nasconderlo dietro il tag "a". Quindi vorrei limitare la lunghezza del token il più possibile per non spaventare troppo gli utenti. Forse anche limitare i simboli solo a lettere maiuscole o qualcosa del genere o qualche altro modo di "abbellirlo".

Questo è un approccio corretto per farlo e se sì, allora quale sicurezza dovrebbe essere applicata al token. Per quanto posso vedere ho bisogno di questo:

Genera il token utilizzando CSPRNG
Assicurati che ci sia abbastanza entropia (la mia applicazione non si occupa di informazioni molto sensibili, quindi suppongo che i 32 bit dovrebbero essere sufficienti, forse anche meno come username / password è solo telefono / codice pin digitale)
Assicurati che il token sia monouso e / o di breve durata (ad es. 24 ore)

authentication url sms token

posta Ilya Chernomordik 15.04.2016 - 15:35

fonte

1 risposta

Leggi altre domande sui tag authentication url sms token

E 'necessario disinfettare i dati passati nell'hash_hmac in php? Posso spostare la mia chiave privata in un token migliore?

score 3 · Accepted Answer

Questo è certamente un approccio ragionevole. Vorrei, come suggerisci nel tuo post, limitarlo sia a un token che è sia a tempo limitato che a una tantum.

Quanto tempo deve essere dipende da quanta entropia senti di dover introdurre. Se dovessi abbellirlo usando solo caratteri e numeri maiuscoli, questo ti avrebbe dato uno spazio di 36 caratteri. Un token di 8 caratteri, scelto in modo completamente casuale da questo spazio, avrà ~ 41,36 bit di entropia. Questo non è sufficiente per una password, ma potrebbe essere potenzialmente utilizzabile come token. A seconda di quanti sono stati emessi, e quanti tentativi di convalidare la tua applicazione supporta, questo potrebbe non dare abbastanza margine per la sicurezza, tuttavia. Un token di 12 caratteri, generato in modo completamente casuale, offrirà circa 62 bit di entropia e, se si desidera passare a 16 caratteri, si otterrà un livello di qualità della password con oltre 82 bit di entropia.

Quindi, è sicuramente uno schema praticabile con buona casualità, e la lunghezza dei token dipende principalmente dalla quantità di margine di sicurezza che si desidera. 8 caratteri è marginalmente lavorabile, 12 caratteri sono probabilmente un punto piuttosto ragionevole, 16 se si apprezza la sicurezza più della compattezza.