Codifica e decrittografa la password per un'applicazione specifica

Suggerirei due cose.

1. Non fare la sicurezza da soli, a meno che tu non sappia veramente cosa stai facendo o stia sperimentando un'applicazione banale che i veri estranei / clienti non utilizzeranno.

2. Non dovresti memorizzare password, nemmeno password cifrate. Esamina "hash" e "sali", "rainbow tables" e password di sicurezza. Quando un utente tenta di connettersi, la password inserita deve essere sottoposta a verifica in modo sicuro e confrontata con l'hash della password impostata in origine. Poiché una funzione hash è unidirezionale, anche se un utente malintenzionato ha ottenuto l'elenco delle password hash degli utenti, non è stato possibile recuperare le password originali (non dico, dipende dall'implementazione di questa teoria e dalla potenza di calcolo dell'aggressore) .

EDIT:

In risposta ai commenti: Non sono a conoscenza di schemi per questo, mi dispiace. Nel qual caso credo che sia necessario tenere le password in modo che la loro crittografia sia la migliore che si possa fare. È possibile salvare le password crittografate sul computer degli utenti, inviarle al server crittografate, decodificarle e inviarle per l'autenticazione con JIRA utilizzando una connessione protetta. In questo modo, anche se il tuo server fosse stato violato, non avresti memorizzato le password alla fine. Se la macchina di un utente è compromessa ci sono cose peggiori che potrebbero fare piuttosto che provare a decifrare la crittografia per una sola password. Quando Chrome memorizza le password degli utenti, non sono così sicure, ma Google ha affermato di non voler dare alle persone un falso senso di sicurezza e quindi non hanno intenzione di migliorarle.

Il tuo approccio ammendato suona meglio - vedi le avvertenze qui sotto.

Il salvataggio delle password per conto di un'altra applicazione è veramente grande no no. Innanzitutto, se le chiavi di crittografia o il datastore sono compromessi, non solo hai esposto gli utenti della tua app, ma anche gli utenti delle altre app. E poiché le persone tendono a riutilizzare le password, è probabile che tu abbia compromesso la loro sicurezza anche su altri sistemi. Quindi salvare le password degli utenti su altri sistemi è brutto, cattivo, cattivo.

• OAuth è stato sviluppato proprio per questo motivo, quindi due sistemi potrebbero condividere l'autorizzazione senza esporre reciprocamente le credenziali dell'utente.

• In effetti, i vincoli relativi alle password sono così rigidi che solitamente persino un'applicazione non è autorizzata a salvare le password stesse crittografate. Piuttosto, salina e blocca la password e salva l'hash salato. In questo modo il meglio che un hacker può fare è ottenere gli hash. Tuttavia, ricorda quando LinkedIn ha hackerato e rilasciato solo i loro hash? Anche le password con hash sono come l'oro per gli hacker. Questo di per sé era un grosso problema: una brutta falla nella sicurezza.

La tua soluzione ammenda è migliore - dove ti attendi all'ID di sessione piuttosto che alle credenziali del cliente.

L'avvertenza è che gli utenti stanno ancora dando il loro nome utente / password per la tua applicazione e ti stanno fidando di fare la cosa giusta. I siti di phishing fanno praticamente la stessa cosa, con cattive intenzioni. La cosa migliore da fare sarebbe avere gli utenti che accedono a Jira in una finestra separata e poi reindirizzano al tuo sito con la sessione ID. In questo modo sempre e solo manda la loro password a Jira e tu non sei affatto nel ciclo, finché non ottieni un ID di sessione.

Potresti indagare e vedere se Jira supporta OAuth, che gestirà questo caso (completa divulgazione: sembra che dovrei saperlo). O se hanno qualche altro meccanismo per fare ciò che vuoi. Potrebbe essere che abbiano già fornito un hook per fare ciò che vuoi fare.

... e se non lo fanno, solleva una seria domanda se dovresti ...

Se questa è un'app interna di un'organizzazione, hai più margine di manovra, perché è meno probabile che qualcuno all'interno del firewall proverà a compromettere il sistema (a meno che tu non sia paranoico o lavori su Target).

Ma se si tratta di un'app esterna, rivolta al pubblico esposta a Internet, allora ... hmmmm ... vorresti sottrarti all'attività di gestione delle credenziali esterne delle persone non appena possibile.