Che tipo di metodo di sicurezza è chiamato (se ha un nome)?

Modifica 2 : dal momento che questo è stato migrato su Security.SE, dovrei probabilmente prefagiarlo con: Non sono un crittografo professionista e ci sono molte, molte ragioni per cui dovresti < a href="https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own"> non fai mai rotolare la tua sicurezza . Detto questo:

È una forma di autenticazione challenge-response (con diverse sfide inviate ogni volta) . L'algoritmo per trovare la risposta corretta è essenzialmente il "segreto" o "password". Sei aperto a un numero di attacchi, ma in sostanza, chiunque riesca a capire il tuo algoritmo può inficiare questa sicurezza, ed è relativamente banale eseguire il reverse engineering degli eseguibili.

Modifica : per mettere questo in prospettiva, considera il sommario di Wikipedia di Kerckhoffs principio e massima di Shannon:

In designing security systems, it is wise to assume that the details of the cryptographic algorithm are already available to the attacker. This principle is known as Kerckhoffs' principle — "only secrecy of the key provides security", or, reformulated as Shannon's maxim, "the enemy knows the system".

Nel tuo caso, hai creato un algoritmo segreto, ma non hai una "chiave" reale (non esiste un segreto condiviso tra i due endpoint, oltre all'algoritmo). Quando qualcuno capisce l'algoritmo, la sicurezza viene interrotta; così nel migliore dei casi hai alzato leggermente la barra per le persone che cercano di capirlo. Siate certi che chiunque voglia davvero romperlo, lo farà. In quella situazione, hai anche avuto un difficile problema di dover sostituire l'algoritmo compromesso (al contrario di cambiare semplicemente la chiave compromessa).

C'è una ragione per cui la crittografia moderna preferisce le grandi chiavi rispetto a algoritmi complessi, indipendentemente dalla complessità dell'algoritmo, può (e sarà) decodificato.

Questo è comunemente chiamato " Sicurezza per oscurità ".

I penso che stai mirando ad una qualche forma di protocollo Challenge-Response, ma questo è così banalmente debole che è ridicolo. Non chiamarlo nemmeno sicurezza ...

L'aspetto "Oscurità" qui è che la sicurezza totale dell'intero meccanismo si basa sul fatto che l'attaccante non ha idea di cosa sia questo meccanismo. Nel momento in cui ha qualche informazione, tutto si rompe.

Questo è il motivo per cui Security by Obscurity è più spesso evitato da chiunque abbia esperienza di sicurezza (nonostante il fatto che in alcuni scenari , Obscurity possa aggiungere un valore limitato.) Ma non qui.).

TL; DR: non farlo.

Potrebbe avere un nome più specifico, ma è una forma banale di handshaking :

In information technology, telecommunications, and related fields, handshaking is an automated process of negotiation, that dynamically sets parameters of a communications channel established between two entities before normal communication over the channel begins. It follows the physical establishment of the channel and precedes normal information transfer

Anche se non sono un esperto in sicurezza, quello che descrivi è tutt'altro che sicuro, è un semplice scambio di token ed è vulnerabile a tutti i tipi di attacchi. "3" è essenzialmente la tua password, ed è una password che ha un senso semanticamente, che è una brutta cosa. Tutto quello che devo fare per frenare la rete è lanciare numeri casuali su di esso. Potresti almeno cambiarlo in "blu", per esempio. Mi piacerebbe ancora entrare, ma probabilmente mi ci vorrà un po 'di più.

Dovresti passare un po 'di tempo a cercare autenticazione a più fattori , presto ti verrà in mente un modo migliore di identificando le tue applicazioni.

A parte la questione del suo nome, considererei la sicurezza piuttosto debole. I motivi per cui sono delineati nelle altre risposte, così come un discorso più generale da qui.

La sicurezza è difficile . Ecco perché gli esperti di sicurezza ricevono enormi pacchetti di pagamento ed è per questo che i sistemi operativi moderni si concentrano così tanto sulla sicurezza, ma a volte riescono a sbagliare.

Implementando la tua sicurezza stai dimostrando che potresti avere un brutto caso di "non inventato qui". Ti incoraggerei a lasciar perdere e ad usare la sicurezza integrata nella tua piattaforma, non importa quanto pensi potresti fare meglio, non puoi. Inoltre, gli amministratori di sistema ti ringrazieranno per l'utilizzo della sicurezza integrata anziché fornire loro un ulteriore livello non necessario di ulteriore sicurezza da gestire e gli utenti finali ti ringrazieranno per non forzare ancora un altro nome utente / password combinato.

Sicurezza per oscurità. Una domanda alla quale la risposta attesa è errata quando viene fornita solo l'informazione presentata nella sfida richiede alcune conoscenze "segrete" aggiuntive che solo il software "in" ha. Il guaio è che il software è nelle mani del tuo aggressore, che può decompilarlo per scoprire il segreto. Questo è quindi molto debole, perché si basa su un segreto statico di bassa entropia (il "segreto" è quello di aggiungere 1 alla risposta alla domanda indicata).

Se due programmi devono fidarsi l'un l'altro, ognuno sapendo che l'altro non può essere garantito al 100% da chi dicono di essere e non da impostore, il metodo usuale è un po 'di "verifica indipendente"; se una terza parte fidata afferma che questo programma è quello che dice di essere, è una "prova" che puoi usare per aumentare la tua sicurezza.

I certificati sono una forma di questa verifica; un server che desidera provare da solo ottiene un certificato da una terza parte indipendente, che ha crittografato le sue informazioni utilizzando una chiave privata non fornita al server, ma che può essere letta da chiunque richieda il certificato del server, utilizzando una chiave pubblica distribuito indipendentemente dalla terza parte. Il server (o un utente malintenzionato che desidera simulare questa posizione) pertanto non può modificare le informazioni nel certificato e, fintanto che le informazioni corrispondono alla posizione effettiva e agli identificatori pubblici del server, i client possono essere sicuri che il server sia tale Dice che lo è.

Senza i certificati, la maggior parte dei sistemi si basa su un modello di prova "a conoscenza zero". Le prove a conoscenza zero di solito richiedono ancora una sorta di terza parte, che distribuisce le prove che i programmi usano per rispondere alle sfide. Nel mondo reale, questo è di solito un server di autenticazione. La differenza è che nessuno deve sapere tutto sullo schema di autenticazione e le informazioni utilizzate possono essere ottenute in tempo reale e quindi possono cambiare ogni volta che vengono eseguite.

Ecco un esempio: Alice è accolta da Bob, di cui Alice non si fida. Bob dice di conoscere Cindy e quindi, dice, è degno di fiducia. Per provare questo fatto, Alice chiama Cindy, che conosce Alice, e chiede metà della coppia di chiavi asimmetriche. Quindi sfida Bob a crittografare un messaggio segreto che può essere decodificato dalla chiave di Alice. Bob chiama Cindy, che conosce anche Bob, e gli dà l'altra metà della coppia di chiavi. Bob crittografa il messaggio, che Cindy non conosce mai, e lo consegna ad Alice, che la decifra con la sua chiave e ottiene il messaggio originale. Bob non avrebbe potuto crittografare il messaggio correttamente senza conoscere l'altra metà della chiave, e l'unico modo in cui avrebbe potuto ottenere è Cindy. Cindy, da parte sua, non conosce mai il messaggio segreto, quindi non può dare a Bob il messaggio da inviare a meno che Bob non le dica (e se Cindy lo avesse chiesto, Bob sarebbe stato sospettoso che forse Cindy non fosse chi lei dice che lo è).

Nel mondo reale, Alice e Bob sarebbero programmi usati dagli utenti finali (forse lo stesso utente finale) e Cindy sarebbe un sistema di autenticazione centrale. Gli utenti finali dei due programmi avrebbero segreti offline (username / password) che avrebbero usato per l'autenticazione con il sistema centrale, e una volta fatto ciò i programmi possono dimostrare l'un l'altro che i loro utenti finali sono utenti validi sul sistema, senza o app che conosce le credenziali dell'altro utente o il servizio centrale che conosce il segreto passato tra i due programmi come parte del loro handshake.

Affinché questo tipo di schema possa essere infranto, un attaccante David deve convincere Cindy che in realtà è Bob, o deve anche avere una complice Emily, che deve convincere Alice che è Cindy, prima di dare liberamente a Bob l'altra metà della chiave che ha generato per Alice. Come Alice sa che Cindy è davvero Cindy e non Emily, e come Cindy sa che Alice e Bob sono chi dicono, richiedono i loro schemi con i loro segreti. Questi schemi possono coinvolgere anche terze parti, ma alla fine si finisce con le terze parti; ad un certo punto devi fare affidamento sul trasferimento di un segreto offline, come un set di credenziali utente, per verificare che qualcuno sia chi dice senza dover consultare terze parti.

Si chiama " password ". È piuttosto insicuro (un personaggio), ma è comunque una forma di segreto condiviso.

D'altra parte, se la domanda fosse "Qual è la superficie dell'Ohio" e la risposta era l'ultima riga del Gettysburg Address base64-encoded. Bene, allora avresti una password migliore e una sicurezza migliore.

In effetti, hai visto questo stesso sistema in atto quasi ovunque. In genere la domanda è "qual è la tua password", a cui rispondi con una stringa che si spera imprevedibile. Ma estendere il sistema in modo tale da rispondere con password diverse per prompt diversi è solo un'estensione dello stesso concetto.