Generazione di token e numeri casuali

2

Ho un server veloce, dove attualmente l'autenticazione viene gestita tramite una semplice combinazione di email + password hash. Voglio rimpiazzarlo con un token di accesso (+ scadenza), così posso rimuovere lo spazio di archiviazione della posta elettronica / password sul dispositivo degli utenti finali per migliorare leggermente la sicurezza, rendendo più semplice revocare l'accesso da punti finali specifici.

Attualmente l'implementazione è multipiattaforma, quindi posso sviluppare localmente (xcode, macOS) ma eseguirlo sulla mia scatola di Ubuntu. Quindi ho bisogno di un modo multipiattaforma per generare numeri casuali.

Dopo alcune ricerche ovviamente ho trovato /dev/urandom , quindi la mia domanda è abbastanza sicura da usare? O dovrei esaminare l'utilizzo di qualcosa come arc4random + chacha20 e se sì, perché e questa implementazione è valida?

Sto pensando di usare 128 bit come lunghezza, dato che ho letto di 64 bit semplicemente non essendo abbastanza sicuro (anche se probabilmente sulla mia scala sarebbe.)

per riferimento, ecco la mia attuale implementazione demo:

func random_data(_ length: Int) -> Data? {
    let stream = open("/dev/urandom", O_RDONLY)
    var buffer: [UInt8] = [UInt8](repeating: 0, count: length)

    let result = read(stream, &buffer, length)
    if result < 0 {
        return nil
    }
    return Data(bytes: buffer)
}

Ho una funzione strcmp sicura nella mia base di codice per prevenire gli attacchi di temporizzazione, ma in ogni caso probabilmente lo dividerò in 2 int64 per la verifica. Post scriptum Devo ancora capire se voglio azzerare la memoria del token generato casualmente dopo che il suo lavoro è finito. Questo è un compito noioso in fretta.

    
posta Antwan van Houdt 19.06.2017 - 21:54
fonte

2 risposte

1

/dev/urandom è la soluzione multipiattaforma che stai cercando!

Come hanno detto @dandavis e @DuncanXSimpson, /dev/urandom è perfettamente appropriato per questo, e si comporterà allo stesso modo su tutti i sistemi operativi Linux e unix-like. Se vuoi essere multipiattaforma con Windows, avrai bisogno di un'istruzione if per chiamare CAPI quando in un Ambiente Windows.

(Si noti che le implementazioni interne di /dev/urandom differiscono significativamente tra linux, BSD, OSX e Solaris, causando molta guerra di fiamma tra crittografi, ma tutte sono non-bloccanti, tutte sono sicure e tutte si comportano allo stesso modo dal tuo punto di vista.)

Nota sul rolling proprio

Non farlo. Come ha detto @dandavis, prendere un codice di flusso come ChaCha e costruire un RNG da esso è sorprendentemente difficile da ottenere. Ed è pericoloso perché è il tipo di cosa che guarderà ad un principiante come sta funzionando quando in realtà è pieno di sottili difetti.

Come recita il vecchio adagio:

Anyone can build a system that he himself cannot break, but very few can build a system that nobody can break.

/dev/random e /dev/urandom sono RNG consolidati destinati all'uso crittografico. Sentiti libero di approfittarne!

Nota su /dev/random rispetto a /dev/urandom

Benvenuti nella più lunga guerra di fuoco in crittografia!

Su questo non c'è carenza di post di blog in grado di google, ma aggiungerò che qualsiasi articolo che dice "Usa sempre /dev/random " o "Usa sempre /dev/urandom " è sbagliato, ognuno ha la sua posizione (eccetto su FreeBSD e Solaris dove funzionano in modo totalmente diverso e random è un collegamento simbolico a urandom , esistente solo per compatibilità multipiattaforma).

La sottile differenza tra loro è che /dev/random bloccherà e ritarderà il tuo programma se non crede di avere abbastanza casualità di alta qualità per riempire la tua richiesta, mentre /dev/urandom restituirà qualcosa indipendentemente dalla qualità (il ' u 'sta per' illimitato '). Questo è importante in alcuni edge case, in particolare in piccoli dispositivi embedded senza mouse / tastiera dai quali trarre casualità.

Detto questo, per server regolari che sono rimasti attivi per più di un'ora con molto traffico di rete o che sono in esecuzione su processori con RNG hardware incorporati (2013+ per Intel e 2015+ per AMD), quindi /dev/urandom va perfettamente bene.

    
risposta data 06.08.2017 - 03:29
fonte
0

Sì, /dev/urandom è sicuro. Non c'è motivo di usare /dev/random invece - Non è davvero più sicuro.

    
risposta data 06.08.2017 - 02:33
fonte

Leggi altre domande sui tag