Perché i moduli di accesso usano ancora "name=" pass "" o simili?

3

Dato che ci sono molti script di MitM che annusano la password, che creano un pettine per frasi chiave come "pass" e "password".

Perché i produttori mantengono gli stessi nomi di variabili e facilitano gli aggressori?

Sicuramente i produttori (di router, ecc.) potrebbero usare la variabile "pass" nel codice sorgente ma cambiarla in una stringa casuale specifica per quel dispositivo al momento del rilascio, rendendo quasi impossibile individuare la password senza la scansione manuale di un grande file di pacchetti catturati.

    
posta aidan 23.07.2017 - 11:39
fonte

2 risposte

4

Riempimento automatico. La maggior parte dei browser ora dispone di gestori di password, che sono probabilmente più sicuri che ricordare la password in quanto consentono di avere password diverse che sono illeggibili per ogni sito. Come può un utente ricordare che la sua password di Facebook è "a! 34-tU62-He4M" e la sua password di google "e4T? -Y5Bf-6gR6". Composto che con il numero di account persone hanno e diventa folle. Ora, se tutto quello che un utente deve ricordare è la sua password principale e se le password vengono memorizzate in modo sicuro, possono avere password univoche per ciascun sito che sono sicure.

I gestori di password possono funzionare solo se sanno che cos'è l'input. Un campo denominato "x1" non significa nulla per un gestore di password e non acquisisce o inserisce dati in esso. Un campo tuttavia denominato "password" verrà contrassegnato.

    
risposta data 23.07.2017 - 14:53
fonte
1

Stai assumendo un sacco di cose sui produttori di router: principalmente, che sono buoni nel migliore dei casi: pratiche di sicurezza. Caso in questione: il mio router (un linkysys) non ha un nome nel campo della password, perché trasforma il modulo in una richiesta ajax che passa la password tramite l'autenticazione BASIC. Non lo fa su HTTPS (una scelta terribile) e tenta anche di disattivare l'autofill sul campo della password (un altro terribile scelta di sicurezza ). (Ora ricordo perché ho comprato un router compatibile con il firmware open source: è ora di scoprirlo ...). Quindi, davvero: non dare per scontato che i produttori di router abbiano idea di cosa stanno facendo quando si tratta di sicurezza. modifica avevo precedentemente affermato che la password sul mio router era crittografata sul lato client prima dell'invio. Mi resi conto che la sicurezza era così grave che non c'era modo di farlo. Quindi ho ricontrollato. Non era crittografato. Erano solo base64 che codificavano la combinazione nome utente / password per semplificare il trasporto.

Come citato da @ISMSDEV, il tuo suggerimento è solo la sicurezza attraverso l'oscurità. Come regola generale, non è il metodo migliore per garantire nulla. La sicurezza attraverso l'oscurità può scoraggiare attacchi automatici più semplici, quindi non è pazzo provarlo, purché la tua applicazione sia altrimenti sicura. Certamente non vorrai preoccuparti di questo come tuo unico metodo di sicurezza (che ovviamente non è quello che stai suggerendo).

Tuttavia, tutte le cose nel software implicano un'analisi costi-benefici. L'introduzione di metodi di sicurezza ad hoc ha la stessa probabilità di introdurre più bug (e più punti per le vulnerabilità) di qualsiasi altra cosa. Più sicurezza è sempre buona, ma è necessario assicurarsi che ogni misura di sicurezza abbia un vantaggio reale. Aggiungere più codice da mantenere con un vantaggio marginale probabilmente danneggerà la sicurezza a lungo termine.

Presumibilmente, la maggior parte dei produttori di router non ritiene che una tale funzione di sicurezza valga la pena. Quindi, ancora una volta, non considerano nemmeno la sicurezza di base la pena. spallucce

    
risposta data 24.07.2017 - 05:24
fonte

Leggi altre domande sui tag