Quando viene data la chiave privata al client? [chiuso]

Question

Quando viene data la chiave privata al client? [chiuso]

#1 da (2 voti)
#2 da (1 voti)

2

Ho letto l'articolo e non l'ho ancora capito. Quando viene fornita la chiave privata al client?

Dire che ho un client JavaScript - dove conserverei questa chiave privata (una volta assegnata) - un cookie?

Penso che questo possa essere fatto durante l'autenticazione di un utente, se un client JavaScript effettua una richiesta di posta e autentica un utente, il server convalida l'input e restituisce l'id dell'utente (una chiave pubblica) e quindi una stringa generata (memorizzata in una tabella) = la chiave privata?

E poi basta seguire l'approccio (citato) dall'articolo:

[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
[CLIENT] Hash (HMAC-SHA1 or SHA256 preferably) the blob of data data (from Step #1) with your private key assigned to you by the system.
[CLIENT] Send the server the following data:
    Some user-identifiable information like an “API Key”, client ID, user ID or something else it can use to identify who you are. This is the public API key, never the private API key. This is a public value that anyone (even evil masterminds can know and you don’t mind). It is just a way for the system to know WHO is sending the request, not if it should trust the sender or not (it will figure that out based on the HMAC).
    Send the HMAC (hash) you generated.
    Send all the data (parameters and values) you were planning on sending anyway. Probably unencrypted if they are harmless values, like “mode=start&number=4&order=desc” or other operating nonsense. If the values are private, you’ll need to encrypt them.
(OPTIONAL) The only way to protect against “replay attacks” on your API is to include a timestamp of time kind along with the request so the server can decide if this is an “old” request, and deny it. The timestamp must be included into the HMAC generation (effectively stamping a created-on time on the hash) in addition to being checked “within acceptable bounds” on the server.
[SERVER] Receive all the data from the client.
[SERVER] (see OPTIONAL) Compare the current server’s timestamp to the timestamp the client sent. Make sure the difference between the two timestamps it within an acceptable time limit (5-15mins maybe) to hinder replay attacks.
    NOTE: Be sure to compare the same timezones and watch out for issues that popup with daylight savings time change-overs.
    UPDATE: As correctly pointed out by a few folks, just use UTC time and forget about the DST issues.
[SERVER] Using the user-identifying data sent along with the request (e.g. API Key) look the user up in the DB and load their private key.
[SERVER] Re-combine the same data together that the client did in the same way the client did it. Then hash (generate HMAC) that data blob using the private key you looked up from the DB.
    (see OPTIONAL) If you are protecting against replay attacks, include the timestamp from the client in the HMAC re-calculation on the server. Since you already determined this timestamp was within acceptable bounds to be accepted, you have to re-apply it to the hash calculation to make sure it was the same timestamp sent from the client originally, and not a made-up timestamp from a man-in-the-middle attack.
[SERVER] Run that mess of data through the HMAC hash, exactly like you did on the client.
[SERVER] Compare the hash you just got on the server, with the hash the client sent you; if they match, then the client is considered legit, so process the command. Otherwise reject the command!

In secondo luogo, credo che sarebbe più leggibile dall'articolo stesso ...

Sto ottenendo questo giusto?

api security server client

posta user2821171 10.03.2014 - 19:33

fonte

2 risposte

1

Se la chiave è condivisa dal client e dal server, non è in realtà una chiave privata, è una chiave segreta. In particolare, è un segreto condiviso.

Se la chiave è una chiave privata, si utilizza la crittografia a chiave pubblica. La chiave privata viene creata sul server e mai lascia il client. Il client utilizza la sua chiave privata per firmare una richiesta di firma del certificato che include una copia della sua chiave pubblica. Questo va al server, che strappa la chiave pubblica, lo firma e restituisce un certificato.

Tornando al tuo protocollo, sembra che tu stia utilizzando un HMAC, che richiede una chiave segreta condivisa. In genere registrerai il segreto condiviso prima di iniziare questo protocollo.

risposta data 11.03.2014 - 01:38
fonte

Leggi altre domande sui tag api security server client

Rendere compatibile la metodologia Agile e DevOps con i requisiti PCI [chiuso] in che modo ORM è un esempio di accoppiamento di messaggi?

score 2 · Answer 1

Quello che stai considerando è chiamato "schema di hashing".

Prendi il contenuto di un messaggio e crei un hash (ad es. HMAC).
L'hash includerà anche una "stringa segreta" fornita dal server.
Il client invia l'hash insieme al messaggio.
Il server può ricreare l'hash dal messaggio e assicurarsi che il suo valore di hash corrisponda esattamente a quello inviato dal client.
Se non corrisponde, allora errore.

La sicurezza arriva perché un "Man in the Middle" può creare un hash per il contenuto, ma non può creare un hash che include la "stringa segreta". .. perché solo client e server conoscono la stringa segreta.

È possibile ottenere la "stringa segreta" attraverso una comunicazione fuori dal canale (come da una e-mail che si taglia e incolla nella configurazione, nel database o da qualche altra parte e la carica con la pagina), o come una richiesta unica al server che utilizza SSL e amp; cache che da qualche parte.

Nelle conversazioni a cui ho partecipato in merito alla sicurezza web, ci sono un paio di punti centrali che emergono.

1) se dai una "chiave segreta" a un browser, non è più un segreto. Javascript nel browser è troppo aperto per mantenere la chiave segreta.

Tuttavia, se non stai passando segreti nucleari o informazioni sulla carta di credito, potrebbe essere un buon compromesso per te. Potrebbe essere che un hacker non si prenda la briga di caricare uno script dannoso per annusare la tua stringa segreta. Ma tienilo a mente.

Ricordo di aver visto un'implementazione javascript dello schema di hashing di OAuth 1 con un grande disclaimer che diceva, "Non eseguire questo codice in produzione, perché un browser pubblico non è sicuro."

2) Alcune tecnologie hanno difficoltà a produrre un hash. Questo non suona come un problema per te, ma se hai solo semplici pagine web senza javascript disponibili, o forse un vecchio script Flash, allora potresti non essere in grado di fare i calcoli necessari per l'hash.

L'alternativa a "hashing" è token-passing.

Ciò significa che il client riceve un token dal server e lo invia insieme a qualsiasi richiesta. Il server verifica che riconosca il token. Ciò significa che devi comunicare usando SSL, perché altrimenti il tuo token sarà visibile al "Man in the Middle" che sta fiutando il traffico internet. Ma con SSL va bene.

Sfortunatamente, questo è un argomento delicato nella comunità della sicurezza. OAuth 1 utilizzava l'hashing, ma OAuth 2 si spostava da hashing a token passando. Questo è stato per rinviare i timori di crittografia a SSL, che lo stava facendo comunque. Ma è ancora un problema abbastanza controverso.

La forma più semplice di passaggio di token per un client browser è il solito cookie di "sessione". Il client chiama il server con nome utente e password e ottiene un cookie di sessione "sicuro". Quindi, finché il client invia il cookie di sessione con una richiesta, il server può autorizzare le chiamate del client.

Tuttavia, devi assicurarti che il flag "sicuro" sia impostato sul cookie, perché non vuoi mai passarlo in chiaro.

OAuth 2 fornisce uno schema di passaggio token che aggiunge sicurezza scadendo i token.
La risposta breve è ...

Se non vuoi seguire il percorso OAuth, solo a) invia nome utente / password per recuperare un cookie sicuro "sessione", quindi passa sicuro em> cookie di sessione con ogni richiesta al server. Chiedi al server di confrontarlo con l'elenco dei cookie sicuri che ha distribuito.

Puoi diventare più fanatico, ma questo è un punto di partenza di base.

score 1 · Answer 2

Se la chiave è condivisa dal client e dal server, non è in realtà una chiave privata, è una chiave segreta. In particolare, è un segreto condiviso.

Se la chiave è una chiave privata, si utilizza la crittografia a chiave pubblica. La chiave privata viene creata sul server e mai lascia il client. Il client utilizza la sua chiave privata per firmare una richiesta di firma del certificato che include una copia della sua chiave pubblica. Questo va al server, che strappa la chiave pubblica, lo firma e restituisce un certificato.

Tornando al tuo protocollo, sembra che tu stia utilizzando un HMAC, che richiede una chiave segreta condivisa. In genere registrerai il segreto condiviso prima di iniziare questo protocollo.