Sicurezza dell'autenticazione utente auto codificata

1

Al momento utilizziamo Apache Shiro per le nostre esigenze di autenticazione degli utenti. Abbiamo bisogno dell'autorizzazione e dell'autenticazione dinamiche, in alcuni casi gli utenti verranno autenticati tramite Active Directory mentre altri verranno autenticati tramite JDBC, ma tutti gli utenti saranno autorizzati utilizzando JDBC.

Shiro si è dimostrato all'altezza, ma non bene. Funziona, ma solo qualche volta. I regni programmatici che ho creato non sembrano funzionare allo stesso modo ogni volta. A volte quando si tenta di accedere più volte fallirà, solo per riuscire infine. Questa è esattamente la stessa richiesta con gli stessi identici dati. Il debug mostra che a volte semplicemente non chiama le funzioni necessarie per ottenere i dati di autenticazione o di autorizzazione. Riavviare l'istanza di solito lo risolve, ma solo per un po 'di tempo. Sembra anche avere seri problemi con più applicazioni shiro esistenti sulla stessa istanza di Glassfish.

In quanto tale, Shiro sembra non essere una scelta sostenibile, soprattutto considerando la scarsa documentazione disponibile. Sto già sovrascrivendo i metodi di Shiro per dire esattamente come ottenere i dati, quindi mi piacerebbe semplicemente codificare le mie classi di autenticazione utente java.

Attualmente l'argomento migliore che ho sentito contro questo è che un sistema con codice personalizzato non è sicuro come quello standard del settore. Tuttavia, da quello che ho letto online e insegnato in classe, la maggior parte dei tentativi di hacking si concentrano sull'accesso a nomi utente e password, o su come inviare codice rouge nel sistema. La maggior parte dei metodi non viola effettivamente il software stesso; in pratica controlla solo i dati forniti e, a condizione che tutti gli input siano disinfettati, il software di autenticazione dell'utente non è di solito il problema. Questa valutazione è accurata?

Inoltre, ci sono delle insidie di cui dovrei essere a conoscenza? Capisco che ci sono altre opzioni come Spring Security o JAAS ma dal momento che ho già essenzialmente il sistema che ho bisogno di costruire all'interno di Shiro e devo solo rimuoverlo da quel software, sembra essere l'opzione migliore per usarlo a questo punto in il ciclo di sviluppo.

    
posta Marcel Marino 07.07.2017 - 14:04
fonte

2 risposte

2

Gli sviluppatori di software tendono ad essere esposti solo all'estremità dell'iceberg delle credenziali e dell'autenticazione perché il 98% dell'applicazione coinvolge la logica aziendale che l'app coinvolge e solo il 2% dell'applicazione gestisce l'autenticazione dell'utente. Gli schemi di autenticazione devono essere in grado di ostacolare i tentativi di cracking della forza bruta, intercettando le comunicazioni di rete, l'uomo nel mezzo, ecc. E molti altri modi per entrare in un sistema chiuso. Oltre all'autenticazione, devi anche assicurarti che la sessione utente, una volta autenticata, funzioni attraverso l'app e sia sicura, ad es. la sessione non può essere hi-jacked, ecc.

Tutto questo è ciò che Apache Shiro sta gestendo per te, e anche se non ho esperienza pratica per utilizzarlo, non riesco a trovare affermazioni di inaffidabilità, bug, ecc. Se fossi in me, direi concentrarsi su capire da dove viene l'inaffidabilità e risolverlo invece di far girare il mio. Perché anche se lo fai nel modo giusto ed è "sicuro" per gli standard odierni, ciò non significa che sarà comunque considerato sicuro per un anno, tre o cinque anni lungo la strada. Dovrai sempre essere informato sugli sviluppi dello spazio di sicurezza / cracking che si sviluppano nel tempo e che potrebbero mettere a rischio la tua metodologia di autenticazione, aggiornare, ecc.

Il set di documentazione sembra piuttosto buono: Documentazione di Apache Shiro

    
risposta data 07.07.2017 - 18:01
fonte
0

Quindi la risposta dipende da quanto è critico il sistema che stai sviluppando. Se il cracking non ha un impatto enorme sul tuo business, allora stai bene. Se lo fa, allora questa risposta è rilevante per te.

Quando arrotoli il tuo sistema di sicurezza, sei tu il responsabile di assicurarti che sia effettivamente sicuro, affidabile e continui a esserlo finché non viene ritirato.

Supponiamo che tu abbia ideato il tuo sistema di autenticazione, dovresti andare avanti e fare i test di penetrazione appropriati contro di esso e anche assicurarti che tutti i sistemi con cui interagire siano compatibili con esso. (Una volta sviluppato un sistema, l'aspettativa sarebbe che gli strumenti futuri relativi a questo useranno il tuo sistema di autenticazione dato che è già in uso).

Una volta che hai rilasciato la versione 1 di questo sistema, dovresti passare a questo per ogni nuova vulnerabilità trovata nelle librerie / logiche che stai utilizzando. Inoltre, tutte le versioni future dovranno passare attraverso questo processo.

Utilizzando un sistema che è già in commercio e open source, tieni questa responsabilità lontana da te. Questo è uno dei principali vantaggi che le aziende vedono nell'usare qualcosa che è già sul mercato.

TL; DR: Se arrotoli il tuo sistema di sicurezza che risolve un problema che è già stato risolto da altri, in pratica avresti speso una notevole quantità di tempo a sviluppare qualcosa che richiederebbe un considerevole tempo in futuro invece di spendere una notevole quantità di tempo ora e una piccola quantità di tempo in futuro.

    
risposta data 07.07.2017 - 20:05
fonte

Leggi altre domande sui tag