Ho bisogno di un valore casuale "crittograficamente sicuro" per un URL non visitabile?

3

tl; dr: una stringa generata in modo pseudocasuale non è sufficientemente gestibile da essere utilizzata come token in un URL?

Sto facendo un'applicazione web, per amor di discussione supponiamo che sia un altro PasteBin. Consentono agli utenti di incollare il testo e generare loro un URL casuale che possono passare ai loro amici, ma altrimenti rimarranno sconosciuti al pubblico.

Come dovrei generare questo URL? Sarà qualcosa come https://pastebin.example.com/%s dove %s è una stringa casuale.

Quanto è sicuro usare semplicemente un valore pseudo-casuale, come il risultato di uniqid ? In che modo l'utilizzo di qualcosa come openssl_random_pseudo_bytes migliora il modo in cui L'ID è?

Supponiamo che gli utenti non possano inviare arbitrariamente molte paste al minuto, esiste un sistema di limitazione della velocità (come un captcha e un controllo IP). Supponiamo anche di aver preso misure per impedire ai motori di ricerca di indicizzare la pagina. Il rischio di condividere le informazioni protette solo da un incomprensibile L'URL non rientra nell'ambito di questa domanda.

Per chiarezza: la stringa casuale viene utilizzata SOLO come identificatore, NON viene utilizzata successivamente per le operazioni di crittografia.

    
posta jornane 17.03.2017 - 10:18
fonte

2 risposte

0

Hai bisogno di qualcosa "crittograficamente sicuro"?

Sì, se vuoi che l'URL: s non sia percorribile (con altri mezzi oltre alla forza bruta) dovrai usare un crittografico generatore di numeri pseudo casuali sicuro (CSPRNG).

I numeri saranno ancora pseudo casuali - i computer non possono generare numeri casuali "veri". L'unica differenza è che i numeri futuri non sono ipotizzabili dai numeri precedenti. E questo è ciò che fa la differenza qui.

Capisco che le parole "crittograficamente sicure" stanno causando una certa confusione qui. Come dici tu, non stai facendo crittografia, quindi perché dovresti averne bisogno? Basta tradurli in "inconcepibili" e le cose diventano più chiare.

La limitazione della velocità aiuta alcuni qui. Definirà definitivamente più difficile per un utente malintenzionato ottenere una lunga lista di ID sequenziali. Ma rende impossibile per un utente malintenzionato prevedere i futuri ID? No, probabilmente no.

Che dire di quelle funzioni PHP?

uniqid è basato sul tempo corrente in microsecondi. Secondo il manuale , non è crittograficamente sicuro:

Caution: This function does not generate cryptographically secure values, and should not be used for cryptographic purposes. If you need a cryptographically secure value, consider using random_int(), random_bytes(), or openssl_random_pseudo_bytes() instead.

Utilizza invece una delle funzioni suggerite e assicurati che il tuo ID sia sufficientemente lungo da impedire la forzatura bruta.

    
risposta data 17.03.2017 - 10:48
fonte
1

uniqid potrebbe non essere la scelta migliore, in parte perché i documenti menzionano (in rosso):

Warning This function does not guarantee uniqueness of return value. Since most systems adjust system clock by NTP or like, system time is changed constantly. Therefore, it is possible that this function does not return unique ID for the process/thread. Use more_entropy to increase likelihood of uniqueness.

E tenderei a sospettare che le collisioni con ID sarebbero abbastanza disastrose nel tuo caso.

Penso che la risposta di base sia che se si ha davvero un requisito per non gestibile, piuttosto che semplicemente unico, probabilmente si vuole usare un RNG crittograficamente sicuro.

O usa un UUID ( link ) - ci sono opzioni, in particolare UUIDv5, che sembrerebbero più adatte al tuo caso that uniqid .

    
risposta data 17.03.2017 - 10:33
fonte

Leggi altre domande sui tag