generatore di numeri casuali con chiave condivisa con oscuramento del pannello di amministrazione

Question

generatore di numeri casuali con chiave condivisa con oscuramento del pannello di amministrazione

#1 da (1 voti)

-1

Sto provando a creare un altro livello di sicurezza sopra il livello 2FA per il pannello di amministrazione super / login

ciò che ho in mente finora è una chiave condivisa (seme condiviso) per generare guidi casuali creati dalla comunicazione client-server (c # client, asp.net core server api), il client / server comunica per ottenere il numero della sequenza di numeri casuali (entrambi hanno una chiave privata condivisa), in modo che entrambi possano generare lo stesso guid che l'amministratore può usare per accedere al suo pannello (che poi usa 2FA per accedere)

supponi che questa chiave condivisa sia dinamica e nessun altro abbia accesso a questo strumento ma l'amministratore (utilizzato per generare la chiave condivisa), quindi sarebbe sicuro?

(limiterà l'utilizzo di questa pagina di accesso a una volta in meno di 5 minuti), è abbastanza sicuro? qualsiasi buco del loop non riesco a vedere?

anche supponendo che le comunicazioni API / client del server siano protette con una password time pad crittografata all'interno del client con un altro time pad e il generatore casuale non è lineare e non è facile da prevedere (non come PRNG lineare )

authentication encryption passwords obscurity administration

posta m s lma 01.06.2017 - 17:43

fonte

1 risposta

Leggi altre domande sui tag authentication encryption passwords obscurity administration

LineageOS è più sicuro di Android Vanilla? [chiuso] Come proteggere l'accesso per creare credenziali di sistema?

score 1 · Accepted Answer

Non so che questo è uno schema ideale. Sembra che tu stia tentando di autenticare la macchina (utilizzando un'applicazione client che contiene / utilizza una chiave precondivisa), ma se questo è il caso, probabilmente non è questo il modo per farlo.

La gestione delle chiavi è difficile. È necessario proteggere la chiave precondivisa sia sul server che sul client in questo progetto, oppure tutto è perduto, almeno per quanto riguarda questo particolare livello di sicurezza. Probabilmente sarebbe più semplice e sicuro usare un meccanismo stabilito come i certificati client.

Inoltre dici:

also assume that server api / client communications are secured with one time pad password that is encrypted inside the client with another one time pad...

Non sono sicuro di quale sia il vero design che hai per il canale di comunicazione, ma non costruisci qualcosa da te. Usa TLS.

Quindi, come ha sottolineato un commentatore, questo suona come il 2FA basato sul TOTP. Poiché hai già un meccanismo 2FA stabilito per l'utente, non eseguire il rollback di una versione aggiuntiva. Usa qualcosa come i certificati client per l'autenticazione client aggiuntiva, e chiamalo un giorno.