Può utilizzare questo sistema di sicurezza sui siti Web?

Non dimenticare il principio di usabilità di AviD:

Security at the expense of usability comes at the expense of security.

Questo è ciò che rende questo schema inutilizzabile, per qualsiasi proprietà di sicurezza che possa avere su qualsiasi altra forma di password. Sarebbe semplicemente inconcepibile aspettarsi che le persone, che hanno tanti problemi come noi con semplici password, cerchino di far fronte a nuovi schemi di password algoritmici casuali che richiedono non solo di ricordare una password, ma ricordando un algoritmo associato alla password, e collegare una nuova serie di variabili ogni volta che è necessario utilizzare la password e calcolarla correttamente. L'intera idea è un disastro di complessità.

In definitiva, questo è un problema (relativamente) risolto. L'autenticazione a più fattori è la soluzione. È sicuro al di sopra e al di là delle semplici password e molto meno nuovo e complesso di quello che tu proponi.

Esistono scenari molto specifici in cui questo schema potrebbe essere utile, ma i servizi comuni non sono uno di questi scenari.

Ci sono seguenti problemi con questo approccio:

1. Le password con formule sembrano essere archiviate in testo semplice. Quindi sarebbe meglio se fosse diviso in due parti: la prima parte conosciuta e la seconda parte la formula. In questo modo la prima parte può essere archiviata come hash.

2. Un meccanismo simile è usato dai token crittografici, dove si inserisce la password seguita dal numero dal token crittografico (come "password" + "123456" che è "password123456"). Il token Crypto è un piccolo dispositivo hardware che mostra il numero dopo aver premuto il pulsante. Ogni hardware del token crittografico ha una chiave diversa, quindi tutti devono utilizzare il proprio token. Ora il fatto è che il problema è che la formula è molto facile da invertire se è molto semplice. In realtà, dovrebbe essere una sorta di crittografia strong che la persona non può eseguire in memoria.

Ad ogni modo, sembri essere sulla buona strada e quello che stai cercando di fare può essere raggiunto nel modo seguente, ad esempio:

1. Crea un'applicazione software token crittografico, quindi questa app accetterà semplicemente la chiave segreta con il tuo server durante l'installazione e sarà in grado di generare token crittografici in modalità offline (o anche online).

2. Il tuo sito web può leggere la password e rimuovere gli ultimi 6 numeri, quindi controllare la password con l'hash memorizzato. (i 6 numeri cambiano molto o 10 secondi o poco più, quindi la sincronizzazione dell'ora è importante, ma se non c'è nessuno, è possibile sincronizzare controllando i token passati / futuri e fare le regolazioni).

3. Quindi il tuo sito web può contattare l'API e controllare se il token crittografico per il nome utente corrisponde.

Ora la cosa da sapere è che i token crittografici funzionano con il tempo e la chiave segreta. In modo che il token generato in un minuto non è valido in tempi diversi.

Tuttavia la sfida principale sarebbe quella di proteggere la sicurezza dei token crittografici. È possibile eseguire il provisioning di un server cloud dedicato per ciascun cliente che lo utilizza, ad esempio, consentendo l'accesso solo dai suoi server e mantenendo una pianificazione di aggiornamento estrema per patch di sicurezza, difesa multilivello e buona architettura software in cui tutte le librerie vengono mantenute attivamente e il codice sorgente viene controllato.

Tale soluzione potrebbe essere utile non solo per i siti Web ma anche per qualsiasi sistema aziendale che includa Active Directory. Tuttavia, per venderlo ai clienti, è necessario conformarsi alle politiche di sicurezza ufficiali una volta e, in secondo luogo, rivederle da istituzioni educative / governative che sono sicuro che saranno utili.

Lo scenario complessivo proposto è buono perché da parte tua non rischi molto - se i token crittografici vengono rubati, le password non sono comunque conosciute, e puoi rilasciare l'aggiornamento al token soft crypto o forzare la riattivazione di questi.

Lo svantaggio è che richiede un token crittografico soft dedicato per accedere a un singolo servizio che lo utilizzerebbe. Quindi il token crittografico hardware è molto più pratico, ma quello soft è ancora valido per la demo e lo sviluppo.

Per quanto riguarda "inserire le lettere 1, 3 e 5 dalla seconda password" è un po 'più debole ma molto più economico rispetto ai token. Tuttavia, produrre token non è difficile oggi dato che è una lunga vita e una sicurezza molto più strong.

Il modello di business di questo è basato sul mantenimento di un metodo di comunicazione sicuro e di un'adeguata archiviazione sicura dei token crittografici, quindi l'intera azienda dalla tua parte deve focalizzarsi adeguatamente su di esso, quindi è lavoro per le società terze e non le banche stesse . In questo modo la superficie di attacco viene ridotta nel modo in cui i token vengono archiviati e verificati dalla società di terze parti.

Non penso sia una buona cosa La cosa del calcolo e la traduzione di lettere in cifre è semplicemente troppo complessa per la maggior parte degli utenti. Vogliono che sia veloce e facile. Inoltre, il fatto che la regola debba essere archiviata in chiaro in modo ordinato affinché lo schema funzioni è un difetto grave nella progettazione della sicurezza.
E quale problema risolve questo problema che non è già stato affrontato? Perché non una semplice autenticazione a 2 fattori con TOTP? Reinventare le cose esistenti in un modo leggermente diverso di solito non migliora le cose.

Non è facile da usare e incompatibile con i gestori di password, quindi qualsiasi utente normale manterrà le sue formule il più banale possibile.

Ciò significa che qualsiasi attaccante che intercetta più coppie di numeri / password può decodificare la formula abbastanza facilmente. Fare questa intercettazione sulla tua implementazione di esempio è facile perché non supporta https.