Forza brutale

Quindi hai un alfabeto di dimensioni 36 e 6 caratteri. Questo ti dà circa due miliardi di token diversi. Diciamo che hai mille documenti diversi. Questo ti dà una possibilità di uno su due milioni di indovinare un token associato a un documento. Provare da mille diversi IP: s ogni ora per un anno ti darebbe quasi dieci milioni di ipotesi - questo dovrebbe darti un paio di documenti.

Certo, il CAPTCHA rende questo più difficile. Ma non sono perfetti e possono sempre essere violati da human .

Il problema qui è che dal momento che si inserisce un token e nessun ID di documento è possibile solo valutare il limite su IP e non sul documento. Ciò rende molto difficile la protezione contro il bruto forcing, a meno che non si disponga di uno spazio molto grande da cui prelevare i token.

Condivisione

Una password è personale e sei incoraggiato a non condividerlo. Ciò significa che può essere facilmente modificato se viene compromesso e tu hai il controllo su chi ci mette le mani sopra.

Un token documento come questo dovrebbe essere condiviso dal design. Hai pochissimo controllo su chi lo ottiene. Finirà su server di posta e backup e pubblicherà i suoi desktop su tutto il mondo.

Non hai idea di chi abbia accesso al token e, se hai bisogno di cambiarlo, dovrai ridistribuirlo a tutte le persone che dovrebbero averlo. Non è né sicuro né pratico.

Conclusione: deve esserci un modo migliore

Questo non ti darà una sicurezza molto buona. Se la risorsa che stai proteggendo non è molto importante potrebbe essere sufficiente, ma non la userei per nulla di valore.

Non conosco il tuo caso d'uso esatto, ma qualunque esso sia, deve esserci un modo migliore per risolvere questo problema rispetto al rollare la tua API. L'utilizzo di una soluzione esistente potrebbe anche farti risparmiare il problema di dover scrivere il tuo codice.

Utilizza un servizio di archiviazione cloud esistente, una connessione VPN nell'intranet aziendale o qualcos'altro. Non accendere il tuo IDE e iniziare a codificare.

Aggiornamento: il tuo caso d'uso

Questo è uno dei casi in cui un token di accesso è probabilmente una buona idea. Ma per aggirare i problemi di cui sopra farei questo:

• Mantieni sia il CAPTCHA che il limite di velocità per IP. (Potresti voler riconsiderare come viene eseguita la limitazione della velocità per evitare DOS accidentali o deliberati.)
• Per far fronte alla forzatura bruta, aumenterei la dimensione del token. Google Drive utilizza 49 caratteri con lettere maiuscole, minuscole e numeri. Questo dovrebbe essere sufficiente anche per te.
• Per aggirare il problema di condivisione, stampa l'URL con il token in un codice QR sul documento stesso. Questo porta il problema del buco nei domini di carte fisiche con cui peoplpe è abituato a trattare. Le persone che vedranno il documento avranno accesso all'originale digitale. È facile da capire.
• Considerare l'impostazione di un limite su quante volte è possibile accedere al documento o almeno un tempo massimo per la durata di utilizzo del token. Se l'auto deve essere registrata entro una settimana, non c'è motivo per il token di funzionare dopo due.
• Non memorizzare i token in testo normale nel tuo database. Stringili. (Qualcosa di veloce come SHA256 dovrebbe essere sufficiente qui - non c'è bisogno di lanciare bcrypt quando si hanno grandi token casuali.)
• Utilizza un CSPRNG per generare i token, altrimenti potrebbero essere indovinati da un utente malintenzionato che ha accesso a pochi token.

Dato che tu dici che "chiunque abbia in mano la visualizzazione del token a 6 lettere può accedere al documento originale", presumo non ci sia nulla di veramente segreto in questi (cioè non potrei commettere frodi semplicemente trovando un gettone nella spazzatura del mio vicino). Altrimenti scegli uno schema di autenticazione regolare con la registrazione e le password e-mail.

Molti sistemi basati su token sono usati nel modo in cui descrivi, anche se nel tuo caso la lunghezza del token è sorprendentemente piccola. Ti suggerisco di usare i token almeno il doppio del tempo: questo renderebbe impraticabili gli attacchi di forza bruta senza rendere il sistema molto più difficile da usare.

PS. Oh, e per favore escludi le lettere O e I dal tuo alfabeto, se non l'hai già fatto.

Limiting calling the API from a single IP more than 3 times/hour

Per prima cosa, questo è un enorme rischio di negazione del servizio. Rimanere bloccato per un'ora solo perché qualcuno ha confuso "l" e "1" è inaccettabile.

Tieni presente che praticamente tutti i computer dell'ufficio sono dietro a NAT44. Ci sono diversi utenti dietro ogni IP. Con CGNAT (NAT444) e NAT464, vedrai anche molti utenti domestici in edifici diversi che usano lo stesso IP.