Ragionevole sicurezza computazionalmente leggera?

Question

Ragionevole sicurezza computazionalmente leggera?

#1 da (2 voti)

1

Ho letto un sacco su come si dovrebbe usare bcrypt o PBKDF2 come una buona via di mezzo tra il carico di lavoro sintonizzabile e il tempo accettabile per rendere la forza bruta e gli attacchi di collisione non fattibili.

Che cosa succede se il sistema non è un sistema di calcolo generalizzato, off-the-shelf?

Lavoro con un sistema embedded, che gira su una CPU ARM 200MHZ e oltre il 90% del tempo della CPU è dedicato all'esecuzione del lavoro effettivo che il sistema sta facendo, continuamente. Tutto il resto è secondario, lento e conservativo in termini di memoria, tempo della CPU e così.

Attualmente, l'accesso al controllo remoto è protetto da una grezza challenge-response basata su md5; dispositivo genera una stringa casuale e lo invia al client, il client invia md5 (password + stringa). Questo è per fermare gli script kiddies e gli amatori eccessivamente curiosi, ma sono consapevole che questa sicurezza è piuttosto patetica.

Ora aggiungerei volentieri qualcosa di meglio, a parte il fatto che non posso davvero risparmiare molta RAM, tempo della CPU o persino spazio su disco per soluzioni fantasiose e preferirei che un client valido sia in grado di entrare in un tempo ragionevole. Inoltre, lo stesso protocollo deve essere utilizzato per autenticare questi dispositivi comunicando tra loro, quindi i vincoli devono essere applicati a tutti i sistemi di autenticazione.

Come risolverlo ragionevolmente? Qualsiasi algoritmo e metodo che consentirebbe una ragionevole sicurezza, assumendo il vincolo che non deve imporre una penalizzazione delle prestazioni superiore all'1%?

authentication cryptography

posta SF. 21.12.2012 - 12:36

fonte

1 risposta

Leggi altre domande sui tag authentication cryptography

Qual è il modo più standard per proteggere le connessioni Internet e proteggere la privacy? Dove posso trovare il campione di traffico worm?

score 2 · Accepted Answer

Proteggere le password in spazio di archiviazione e transito sono due problemi separati. Il motivo principale per l'utilizzo di PBKDF2 o bcrypt è che la loro resistenza al crack di hash è elevata, nei casi in cui gli hash vengono catturati dal server (ad esempio tramite un dump del database tramite SQLi).

Dato che stai cercando di proteggere le password in transito, penso che potresti essere già caduto in una trappola inaspettata. Se un utente legittimo invia una richiesta con una risposta corretta alla sfida, cosa impedisce all'attaccante di eseguire un attacco man-in-the-middle e di modificare i contenuti della richiesta, mantenendo il token di risposta valido?

Quindi, per prima cosa devi definire ciò di cui hai bisogno:

Riservatezza della password.
Integrità del messaggio.
Autenticazione del client (con la password e il messaggio)

Un sistema di risposta alle sfide da solo non può farlo, a meno che non si integri un MAC (codice di autenticazione dei messaggi) in esso. In effetti, ciò di cui tecnicamente è necessario è un MAIC (codice di autenticazione e integrità dei messaggi), poiché è necessario assicurarsi che il messaggio esatto ricevuto sia quello inviato dall'utente, che non sia stato manomesso e che l'utente è chi dicono di essere.

Ora ti imbatti in aree in cui ci sono errori da fare e dove i difetti di implementazione si scatenano. Scrivere un protocollo che offra in modo efficace l'autenticazione, la riservatezza e l'integrità è difficile, specialmente su un sistema embedded che utilizza linguaggi di basso livello. Tuttavia, TLS (SSL) fa esattamente questo. Contrariamente a quanto alcuni dicono, TLS è straordinariamente efficiente in termini di utilizzo della CPU e della memoria. L'ho visto implementato su microcontrollori Atmega da 40MHz con pochissimi problemi.

Quindi, in conclusione, consiglio vivamente di trovare una libreria SSL (libssl forse?) che verrà compilata su ARM, e poi usarla.