Sicurezza, crittografia: Stupid Challenge - Protocollo di risposta?

Question

Ok ragazzi, solo un piccolo gioco:

Ho alcune specifiche per un progetto. Ad un certo punto chiedono quanto segue per crittografare una password in rete, dicendo che si tratta di un protocollo di risposta alla sfida:

CLIENT ----------------------------- SERVER

(1)ask for challenge -------------->

(2)    <---------------------------- send SHA1 taken from the time
                                       (this is the challenge)
(3) make SHA1 xor PASSWORD --------> if it's equal to SHA1 xor stored password

(4)    <---------------------------- Grant access

Per chi non lo sapesse SHA sta per Secure Hashing Algorithm, un algoritmo standard per la crittografia.

Spero sia chiaro. La domanda è: se annuso i pacchetti 2 e 3 (la "sfida" e la "sfida password xor", ho la password effettiva solo con un'altra xor tra di loro!?!? C'è un altro modo per implementare questo tipo del protocollo ??

Answer 1

Che ne dici di quanto segue:

1. Il server invia una sfida casuale
2. Il client invia un checksum SHA1 di (challenge + password)
3. Confronto tra server e checksum SHA1 di (challenge + password memorizzata)

Answer 2

Saresti in grado di decodificare la password. Vuoi inviare lo SHA della password, non la password stessa. Rotolare i tuoi protocolli di sicurezza non è quasi mai una buona idea. Non puoi usare SSL o qualcosa di equivalente?

http://en.wikipedia.org/wiki/Cryptographic_nonce

Answer 3

È un protocollo piuttosto orribile. Se questo è qualcosa che qualcuno vuole farti implementare, rifiuta. Esistono protocolli già controllati per questo tipo di cose. Se questo è un gioco in cui metti in evidenza tutti i difetti - okay.

• Chiunque ascolti i passaggi 2 e amp; 3 conosce la password
• Chiunque ascolta il passaggio 3 e nota l'ora può forzare la password se ha idea della precisione dell'ora sul server
• Posso fingere di essere un server (avvelenamento da arp, riduzione del DNS, ecc.) e ottenere la tua password, senza mai completare il passaggio 4 e fingere un timeout
• Vulnerabile agli attacchi Man in the Middle perché non esiste un segreto condiviso tra client / server o certificati sul server
• Si affida al server che archivia SHA1 (tempo) e attende una risposta, quindi posso sovraccaricare il server con richieste di sfide e non rispondere mai.

E mi mancherà sicuramente ancora un po '.

Answer 4

Hai ragione: se acquisisci la sfida e (sfida la password XOR), estrarre la password è facile.

È necessario utilizzare la crittografia corretta al passaggio 3, non XOR. Crittografa la sfida con la password.

Per rendere più difficile la vita di un utente malintenzionato, potresti aggiungere dati casuali a ciò che crittografi: ad es. imbottitura crittografica. Al server non importa quale sia il riempimento, sa dove cercare la sfida, ma significa che un attaccante non saprà quale sia l'intero testo in chiaro.

Answer 5

Come hanno sottolineato gli altri, hai ragione. Inoltre, tieni presente che qualcuno potrebbe intercettare la comunicazione (3) e potenzialmente inviarla di nuovo mentre l'utente reale sta riscontrando problemi di rete (ad es. Un DDOS), l'impostore verrebbe quindi registrato e spesso ciò è sufficiente per cambiare la password (ovvero , molti sistemi non richiedono che tu fornisca una password inorder per cambiarla dopo aver effettuato l'accesso).

Potresti prendere in considerazione HMAC (Keyed-Hash Message Authentication Code). Ne ho fatto un blog in dettaglio qui: http://blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.html e fornirò un breve riassunto di seguito.

HMAC è un metodo per garantire che un messaggio sia stato generato da qualcuno con accesso a un segreto condiviso. HMAC utilizza una sorta di funzione di hashing unidirezionale (come MD5 o SHA-1) per crittografare il segreto insieme a un messaggio. Questo genera un breve riassunto di 16-20 byte che funge da impronta digitale del messaggio + combinazione segreta. Quando il digest viene inviato insieme al messaggio, il destinatario (il nostro server) può rigenerare l'hash con lo stesso calcolo HMAC e confrontare il digest generato localmente con il digest fornito con il messaggio. Ricorda: anche il server ha il segreto, quindi ha abbastanza informazioni per confermare il digest. (Ciò considera solo il problema di verificare l'origine di un messaggio, ma è possibile utilizzare lo stesso approccio per crittografare l'intero messaggio, se si utilizza un segreto diverso, dire una serie di chiavi pubbliche.)

Answer 6

Il modo in cui lo farei è il seguente:

1. Sfida il server.

2. Il server risponde con la sua chiave pubblica (per, diciamo crittografia RSA) digitalmente firmato.

3. Il client verifica PK e crittografa password con la chiave, quindi firma digitalmente il crittografato password.

4. Il server verifica la firma e la decrittografia la password per archiviarla / controllarla.

La firma digitale è importante qui in quanto funge da inizio per prevenire gli attacchi dell'uomo nel mezzo.

Answer 7

Come altri hanno sottolineato, sì, questo è un algoritmo di risposta alla sfida scadente.

Probabilmente vuoi controllare Digest Authentication , come utilizzato da HTTP. In effetti, se il tuo protocollo è su HTTP, puoi saltare la tua scrittura e utilizzarlo o implementarlo.

Answer 8

crittografia a chiave pubblica? Utilizzare la chiave pubblica del server per crittografare la password.

Answer 9

Anche se non è mai una buona soluzione per implementare il proprio protocollo crittografico, ed è qualcosa che non consiglierei ....

Per superare il problema che stai affrontando ... F - Una funzione che accetta la password e un valore pseudocasuale che aumenta monotonicamente e restituisce un numero. Ad es. Hash (Hash (Password) ^ Timestamp)

1. Server: chiedi sfida, invia (timestamp). Ricorda il timestamp inviato.
2. Client, Invia risposta (Invia F (Password, Timestamp) e Timestamp)
3. Server: controlla il client utilizzando Hash (password) e il timestamp inviati dal client (> timestamp inviato nella sfida).
4. Se il Cliente ha ragione, concedi l'accesso.
5. Assicurati che il timestamp attuale sia maggiore di tutti i timestamp inviati dal client prima della prossima sfida per prevenire gli attacchi replay.

Cordiali saluti, Ashish Sharma

Answer 10

Credo che Diffie-hellman sia un protocollo di scambio di chiavi ben noto e solido?