SSH authorized_keys viola il principio di "re-autenticarsi prima del cambio della password"?

Question

SSH authorized_keys viola il principio di "re-autenticarsi prima del cambio della password"?

#1 da (2 voti)

4

È generalmente accettato che i meccanismi di modifica della password dovrebbero chiedere all'utente la loro vecchia password (es. OWASP ) Il motivo è che un utente malintenzionato che ha accesso temporaneo alla sessione di un utente (tramite XSS, il computer rimasto connesso, qualunque cosa) avrà accesso solo a quella sessione.

Presumibilmente questo principio dovrebbe portare avanti altri meccanismi di autenticazione: certificati, token, ecc. (anche se non ho mai visto questo discusso)

Tuttavia, considera come funziona SSH authorized_keys. Se si ha accesso alla sessione di accesso di un utente, ma non alle proprie chiavi (ad esempio, se hanno lasciato il proprio accesso al computer), è possibile modificare il file authorized_keys. È possibile aggiungere la propria chiave al file, in modo da poter accedere all'account in futuro. Puoi anche rimuovere le chiavi legittime per bloccare il proprietario dell'account.

Quindi i progettisti di SSH dovrebbero essere in cerca di soluzioni per rafforzare questo? E quali approcci potremmo adottare per fermare questa vulnerabilità?

ssh password-management certificates

posta paj28 06.06.2014 - 13:17

fonte

1 risposta

Leggi altre domande sui tag ssh password-management certificates

L'utilizzo dell'autorizzazione basata su token rende superflui i controlli CSRF all'accesso? Strano Messaggio finito in TLS

score 2 · Accepted Answer

Sì, hai ragione, SSH authorized_keys consente le modifiche di autenticazione senza verifica se un avversario riceve (o ruba) accesso alla shell una volta (o ha accesso sufficiente ai file).

Vado qui su un arto qui e suggerisco che SSH authorized_keys è stato progettato come un miglioramento rispetto al paradigma .rhosts. Un modo per consentire un accesso senza interruzioni tra gli host ma con più di un semplice trust. Quindi, da quella prospettiva, i tasti_autentici sono davvero un grande miglioramento nella sicurezza. Non è per scusare il problema che stai descrivendo, ma per metterlo in un contesto.

L'unico approccio che risolverà davvero questo problema è quello di centralizzare l'autenticazione delle chiavi. Invece di utilizzare file chiave diversi, è necessario che gli utenti inviino le chiavi in un repository di sistema, così come inviano le loro password nel repository / etc / shadow tramite programmi intermedi. Significa che il codice, i problemi di proprietà e protezione dei file e la sostituzione di un semplice controllo di modifica dei file con un'interfaccia di manipolazione dei database più strutturata e probabilmente difficile (quella che richiede l'autenticazione per consentire la manipolazione!).

Fattibile? Certamente. Facile? No, sarà un po 'di lavoro. Probabile? Probabilmente no; questa area di debolezza è stata conosciuta e accettata per molto tempo, senza un nuovo slancio non vedo nessuno spingere strong per risolverlo.