Schema di sicurezza personalizzato api / client

0

A prima vista, vorrei sapere se esiste una libreria o uno standard ampiamente utilizzato che potrei adottare per sostituire il mio schema "personalizzato". Sono certo che io, come persona, non posso produrre qualcosa di meglio di una biblioteca prodotta dalla comunità.

Detto questo, sono un debuttante della sicurezza, e mentre esaminavo altre implementazioni non ne trovavo uno che sembrava soddisfare le mie esatte esigenze. Probabilmente era proprio sotto il mio naso e non l'ho capito.

Sto sviluppando una API riposante e un client javascript. Ho intenzione di implementare onestamente il resto e andare apolidi, ovvero senza sessioni lato server. Tutte le informazioni per rispondere a qualsiasi richiesta devono essere passate dal client al server come parte della richiesta.

La soluzione di sicurezza deve fornire protezione contro un attaccante remoto di terze parti da moderatamente seriamente risolto.

Non intendo proteggere contro un utente malintenzionato che si trova in custodia fisica del sistema client o server.

Quindi, con tutto ciò in mente, ecco la mia custom :( soluzione.

  • HTTPS a livello di sito
  • Al momento della registrazione al servizio, la password dell'utente viene passata 'clear' al server in cui è memorizzata in un hash sha-3 salato.
  • Al momento dell'accesso, il client javascript non trasmette l'ID utente e la password al server. Invece, genera una stringa casuale e la memorizza nello spazio window.name. Quindi utilizza questa stringa come passphrase per eseguire la crittografia AES a 256 bit sul nome e sulla password, memorizzando questo testo cifrato in un cookie. Questo cookie ha una durata di 1 ora.
  • Quindi, tutte le chiamate API richiedono che il client acceda alla stringa window.name, decifri il cookie e passi il nome utente / password 'clear' al server. Viene anche passato un timestamp unix-epoch.
  • Il server, dopo aver ricevuto qualsiasi richiesta, recupera l'utente salt, esegue un hash sha-3 sulla password e lo confronta con il valore memorizzato nel db. Garantisce inoltre che il timestamp sia entro 60 secondi dall'ora del server.
  • Se superano questi controlli, il client viene considerato autenticato per quella singola richiesta.

Non sono sicuramente un esperto di sicurezza, ma immagino che questo forum sia. Qualunque cosa tu suggerisca, ti prenderò a cuore.

    
posta user36581 02.01.2014 - 17:12
fonte

1 risposta

1

Site-wide HTTPS

Questo è buono.

At registration to the service, the user's password is passed 'clear' to the server where it is stored in a salted sha-3 hash.

Questo è male. Hash password con un algoritmo di hashing della password lenta come pbkdf2 , bcrypt o scrypt invece.

Upon login, the javascript client does not pass the user id and password to the server. Instead, it generates a random string and stores that in the window.name space. It then uses this string as a passphrase to perform 256bit AES encryption on the name and password, storing this cipher text in a cookie. This cookie has a life of 1 hour.

Henceforth, all API calls require that the client access the window.name string, decrypt the cookie, and pass the username/password 'clear' to the server. A unix-epoch timestamp is also passed.

The server, upon receiving any request, retrieves the user's salt, performs a sha-3 hash on the password, and compares it to the stored value in the db. It also ensures that the timestamp is within 60 seconds of the server time.

Questo mi sembra troppo complesso. Puoi semplicemente passare il nome utente e la password tramite HTTPS al server durante il login. Se l'autenticazione ha esito positivo, generare un token casuale sul lato server e restituirlo al client. Qualsiasi richiesta futura deve includere quel token per essere considerato autenticato. Se necessario, puoi invalidare il token dopo un certo periodo di tempo sul lato server.

    
risposta data 02.01.2014 - 17:24
fonte

Leggi altre domande sui tag