it-swarm-eu.dev

È sicuro archiviare le password con la crittografia a 2 vie?

Sono un genitore che ha un account genitore presso il mio distretto scolastico locale in modo da poter accedere al loro sito Web per visualizzare i voti di mio figlio ecc.

Ho fatto clic sul pulsante "password dimenticata" e la mia password mi è stata inviata per e-mail in testo semplice. Questo mi riguardava, quindi ho inviato un'email al principale, inclusi alcuni collegamenti dal in fondo a questa pagina . Questa è la risposta che ho ricevuto dal dipartimento IT dell'organizzazione:

Le password principali non sono memorizzate in testo normale. Sono criptati. Non una crittografia a 1 via ma una crittografia a 2 vie. Ecco come il sistema è in grado di presentarlo via e-mail tramite l'utility CoolSpool di Ariande.

Per motivi di supporto, la password del genitore è visibile a determinati membri dello staff fino a quando il genitore non ha eseguito correttamente l'accesso 3 volte. Successivamente, nessuno staff può vedere quella password. Tuttavia, viene archiviato in modo tale che il sistema stesso possa rispedirlo all'e-mail verificata. In futuro, dopo 3 accessi riusciti da parte di un genitore, se dimenticano la password, al loro account di posta elettronica verificato verrà inviato un link per reimpostare la password, questa modifica è in corso.

Questa spiegazione giustifica la password in chiaro inviata tramite e-mail e le mie password sono al sicuro con loro?

In caso contrario, con quali riferimenti o risorse potrei rispondere?

139
43Tesseracts

No, questa non è una buona pratica. Vi sono due problemi distinti.

  • crittografare la password invece di eseguire l'hashing è una cattiva idea ed è al limite la memorizzazione di password di testo semplice. L'idea generale delle funzioni di hash lente è quella di contrastare l'esfiltrazione del database degli utenti. In genere, ci si può aspettare che un utente malintenzionato che abbia già accesso al database abbia accesso alla chiave di crittografia se l'applicazione Web può accedervi.

    Quindi, questo è un testo in chiaro borderline; Ho quasi votato per chiudere questo come duplicato di questa domanda , perché questo è quasi lo stesso e la risposta collegata si applica quasi direttamente, specialmente la parte relativa ai trasgressori in chiaro; c'è n'altra risposta anche per i trasgressori in chiaro.

  • inviare una password in chiaro tramite e-mail in chiaro è una cattiva idea. Potrebbero sostenere che non vi è alcuna differenza quando non si verifica il riutilizzo della password, ma dubito che saprebbero anche di cosa si tratta e perché è considerata una cattiva pratica. Inoltre, il riutilizzo della password è così comune che non sarebbe una buona risposta.

Inoltre, poiché sembrano funzionare sulla seconda parte (anche se i collegamenti di reimpostazione della password nelle e-mail in testo normale si trovano nello stesso campo di gioco, vale a dire una minaccia in grado di leggere la password dalla posta in chiaro può anche leggere il collegamento, forse prima di te possibile), potresti spiegare loro il problema di non eseguire l'hashing dalla mia risposta, inoltre sentiti libero di collegarti questa risposta direttamente.

Forse anche spiegare che la crittografia è un modo, ma può sempre essere invertita dalla funzione inversa del sistema crittografico in questione, appropriatamente chiamata decrittazione. L'uso di termini come "crittografia a una via" e "crittografia a due vie" anziché "hashing" e "crittografia" mostra una mancanza di comprensione.

Il vero problema è: l'implementazione di un ripristino della password non significa che avranno hash (correttamente) in futuro; non c'è molto che tu possa fare al riguardo, tranne usare un gestore di password e creare una passphrase lunga e forte, unica per questo sito e sperare per il meglio.

Ciò è particolarmente vero poiché sembrano voler mantenere la parte del loro sistema che dice allo staff la tua password (per assolutamente no buona ragione). L'implicazione è che continuano a non eseguire l'hashing in modo corretto: chi afferma che il personale può vedere solo la password in quei tre tempi di accesso non è vero; se l'app Web può accedere alla chiave, anche il personale amministrativo. Forse non è più il personale dell'assistenza clienti, ma non dovrebbero essere in grado di vederlo in primo luogo. Questo è un design orribile.

A seconda della tua posizione, le scuole come parte del settore pubblico hanno l'obbligo di avere un CISO che puoi contattare direttamente, esprimendo le tue preoccupazioni. E come al solito nel settore pubblico, dovrebbe esserci un'organizzazione che supervisiona la scuola; dovrebbero avere almeno un CISO, che potrebbe essere piuttosto interessato a questo procedimento.

192
Tobi Nary

Tutti si stanno concentrando sulla crittografia e sull'hashing ma, sebbene ciò sia di per sé negativo, trovo quanto segue più eclatante:

Per motivi di supporto, la password del genitore è visibile a determinati membri dello staff fino a quando il genitore non ha eseguito correttamente l'accesso 3 volte.

Dovresti interpretarlo come "lo staff IT conosce la mia password". Hanno ammesso apertamente che alcuni membri del loro staff possono conoscere la tua password. Questo è oltre il male. Suppongo che questo contatore venga resettato dopo aver cambiato la password, quindi usare una password fittizia tre volte e poi cambiarla in una password "reale" non farà nulla. Non inserire nulla su quella piattaforma che non desideri sia reso pubblico e, se hai utilizzato la stessa password su altri siti, modificali.

72
MrZarq

No, come hai correttamente ipotizzato, questo comportamento non è chiaramente sicuro.

Quello che puoi e dovresti fare non è fidarti del loro sistema. Non utilizzare una password sul sistema scolastico che assomigli al tuo sistema bancario o ad altre password. Non inserire più informazioni di quelle necessarie per far passare il bambino a scuola. Se tuo figlio porta a casa una nota che dice "accedi e aggiorna le tue informazioni", non mettere nulla di scomodo da rivelare.

Almeno il loro scenario "in futuro" sembra che stiano implementando il comportamento di cui hanno bisogno per supportare password con hash sicuro; se avranno effettivamente eseguito l'hashing sicuro delle password (dopo tre accessi) anziché crittografarle sarà una domanda diversa. E non sarai in grado di rispondere a questa domanda osservando. Se sei ancora preoccupato, puoi contattare il fornitore del software e chiedere loro come funziona.

19
John Deters
  1. Non dovresti presumere che la tua password sia mai sicura. C'è un motivo per cui i gestori di password sono la strada da percorrere consigliata

    La realtà è che nei tuoi tentativi di gestire da solo tutte quelle password, commetterai il peccato cardinale di riutilizzarne alcune. Questo è in realtà molto più rischioso rispetto all'utilizzo di un gestore di password. Se un singolo sito che utilizza questa password cade, ogni account che la utilizza è compromesso. Dovrai ricordare tutti i siti in cui hai riutilizzato quella password e poi cambiarli tutti.

  2. Il modo consigliato per eseguire un ripristino è generare una chiave univoca affinché un utente possa eseguire il proprio ripristino su un sito Web protetto TLS. Email, anche con TLS abilitato, è ancora intrinsecamente insicuro

    Sebbene TLS e SSL costituiscano senza dubbio una base vitale per l'approccio di qualsiasi azienda alla sicurezza dei dati, ci sono ancora alcune prove che suggeriscono che si tratti di un sistema che comporta una serie di potenziali vulnerabilità.

    Il principale punto di debolezza deriva dalla mancanza di comprensione da parte delle aziende su come crittografare le e-mail, poiché molti credono che il canale di trasporto, e quindi l'e-mail, sia completamente protetto con l'uso di TLS.

  3. L'hash è fondamentalmente diverso dalla crittografia. Questo è stato ben esplorato su Stack Overflow

    [Le funzioni di crittografia] forniscono una mappatura 1: 1 tra input e output di lunghezza arbitraria. E sono sempre reversibili .

    Come notato da SmokeDispenser, se riescono a ottenere il tuo database, possono ottenere la chiave di crittografia. In che cosa differisce dall'hashing? Gli hash sono sempre a senso unico . I dati entrano e non escono mai. In altre parole, non ci sono chiavi da rubare.

    Utilizzare una funzione hash quando si verifica la validità dei dati di input. Ecco per cosa sono progettati. Se hai 2 input e vuoi verificare se sono uguali, esegui entrambi tramite una funzione hash. La probabilità di una collisione è astronomicamente bassa per input di piccole dimensioni (presupponendo una buona funzione hash). Ecco perché è consigliato per le password.

    In altre parole, memorizzi la tua password sul mio sito. L'ho usato con una stringa casuale (chiamata salt) più e più volte con qualcosa di lento (come bcrypt). Per convalidarti, inserisci di nuovo la password e la lavo attraverso lo stesso hash. Con lo stesso algoritmo (oltre a quante volte l'ho passato, chiamato costo), salt e password, dovrei ottenere lo stesso hash che ho memorizzato. Pertanto, non ho bisogno di memorizzare una password crittografata reversibile o non crittografata.

14
Machavity

Per definizione, se una password è memorizzata da qualcuno diverso da te, non viene archiviata in modo sicuro. Non è mai necessario archiviare la password.

Se il personale IT ha mai un motivo legittimo per accedere al tuo account senza che tu fornisca la password, non è necessario che la password sia archiviata da qualche parte. Possono reimpostare la password, accedere al tuo account, sostituire la password con l'originale. Tutto senza mai conoscere la tua password.

Se possono inviarti la tua password, possono inviarla a qualcuno che finge di essere te. Quindi non è sicuro.

PS. Non hanno assolutamente bisogno di memorizzare la password per l'autenticazione. Possono archiviare un hash salato, dal quale è impossibile recuperare la password. Questa è la pratica standard. Come possono inviarlo a qualcuno che finge di essere te? Si chiama ingegneria sociale. Qualcuno chiama, li convince che sei tu e che il tuo indirizzo e-mail è cambiato e che inviano la password alla persona sbagliata.

1
gnasher729