Perché Google richiede la ri-autenticazione prima di poter avviare la procedura di modifica della password?

Naviga le tue risposte
1

Quando un utente desidera modificare la password per un account, la maggior parte delle applicazioni Web presenta un modulo in cui l'utente deve inserire la nuova password e la vecchia password. Finora ho pensato di capire i benefici di questo approccio. Ad esempio, la vecchia password è un'ulteriore attenuazione a CSRF ed evita il dirottamento dell'account (ad esempio, cambia la password per un account) se un utente malintenzionato ottiene la sessione Web.

A Google - ovviamente;) - è diverso. Quando l'utente fa clic sul collegamento per modificare la password, viene presentato un modulo di accesso e l'utente deve eseguire nuovamente l'autenticazione. Dopo la nuova autenticazione viene mostrato un modulo in cui l'utente deve solo inserire la nuova password. La vecchia password non è richiesta di nuovo.

Ci sono alcuni pro e contro con gli approcci:

  • Chiedere la password proprio lì dove avviene il cambiamento (primo approccio) ha il vantaggio che il rischio che le debolezze dell'intero processo possano essere sfruttate è notevolmente ridotto. La nuova password e la vecchia password vengono elaborate in coppia. Se qualcosa va storto (ad esempio un utente malintenzionato è in grado di impostare un utente arbitrario per la sessione Web), allora c'è un'alta probabilità che la vecchia password protegga ancora la modifica della password.
  • Per il secondo approccio (Google) potrebbero esserci punti deboli nel processo dopo la nuova autenticazione (ad esempio, la protezione CSRF potrebbe fallire, bug nella gestione delle sessioni).
  • Il secondo approccio ha il vantaggio che l'applicazione per cambiare la password non è accessibile prima della ri-autenticazione. Quindi i punti deboli nell'applicazione non sono accessibili prima della ri-autenticazione. Le debolezze non accessibili non possono essere sfruttate.
  • Forse Google vuole implementare un solo modo per fare l'autenticazione. Penso che Google utilizzi una sorta di analisi dei rischi per il login e che sia possibile che Google voglia semplicemente utilizzare quei meccanismi per il processo di modifica della password.

A mio parere, il rischio di punti deboli nel secondo approccio è molto più elevato, soprattutto perché possono verificarsi molte cose tra la nuova autenticazione e l'invio della nuova password. Inoltre, ritengo che riutilizzare l'analisi dei rischi e cose del genere dovrebbe essere possibile senza grandi sforzi anche per un processo di modifica della password.

Quindi la mia domanda è: mi manca qualcosa che rende il secondo approccio (Google) superiore?

    
posta DanielE 05.07.2016 - 21:59
fonte

4 risposte

3

La mia ipotesi sarebbe che per Google consenta loro di gestire più facilmente tutte le loro diverse opzioni per TFA (autenticazione a due fattori). Fuori dalla mia testa supportano almeno 3 o 4 metodi diversi. Ti consentono inoltre di attivare più TFA contemporaneamente in modo da poter scegliere quale utilizzare.

Non è detto che non si possa gestire tutto ciò sulla stessa pagina di modifica della password con i vecchi e nuovi campi password, ma è sicuramente più complicato della semplice richiesta della vecchia password insieme a quella nuova.

    
risposta data 06.07.2016 - 01:02
fonte
0

Una cosa da considerare è che Google ha dedicato molto tempo a progettare il suo sistema di autenticazione, con ciò che equivale a un think-tank di ingegneri di livello PHD. Sembra che proteggere il modulo di modifica della password sia solo un'altra implementazione di tale funzionalità, come lo scopo del codice portatile e riutilizzabile. IMHO, dovrebbe fare leva più spesso. In questo modo gli sviluppatori non devono costruire ciò che è fondamentalmente una seconda forma del loro sistema di autenticazione (ad esempio oldpw == currentPW? ChangePW: returnError) quando quello originale funziona bene.

Hai ragione nella tua valutazione che le debolezze in una PW cambiano forma che non è accessibile senza il log-in, presenti come rischi ridotti.

Sviluppato e implementato correttamente, non so se una versione di questa storia sia migliore dell'altra (come hai dimostrato di avere pro e contro) quindi penso che dipenda da preferenza, architettura e decisioni aziendali su dove concentrare il tempo e gli sforzi del loro sviluppatore.

    
risposta data 05.07.2016 - 22:40
fonte
0

Avrebbe avuto senso per me se avessero chiesto il secondo fattore anche nella re-autenticazione, ma non lo hanno fatto. E la nuova pagina delle password richiede la nuova autenticazione se viene riaperta. Quindi è molto simile al primo caso ma diviso in 2 pagine. Quindi nessuna opportunità per CSRF.

I GUESS era più una scelta architettonica che di sicurezza. Inoltre le vecchie e le nuove password nella stessa pagina sono troppo mainstream per Google, suppongo XD.

In realtà voglio vedere un motivo migliore di questo però.

    
risposta data 05.07.2016 - 23:44
fonte
0

È perché le persone si allontanano dal loro computer, lasciandole sbloccate e registrate.

Il secondo requisito di accesso significa che il ragazzo sulla sedia accanto a te non può rubare il tuo account quando vai a prendere più caffè o se devi correre per il tuo aereo e hai dimenticato di disconnetterti o se qualcuno ruba la tua sessione

Lo fanno per tutto ciò che riguarda la sicurezza.

Non c'è davvero nessun downside.

    
risposta data 12.11.2018 - 19:22
fonte

Leggi altre domande sui tag

Capire un overflow del buffer basato su stack reale C'è un modo per impedire la modifica dell'indirizzo MAC su una macchina Windows?