Domanda:
Come posso sapere che gli sviluppatori saranno etici e non registreranno la mia password in chiaro
poush
2015-06-07 10:03:38 UTC
view on stackexchange narkive permalink

Non sto chiedendo perché si dovrebbe fare l'hashing. Invece, voglio sapere come impedire che gli sviluppatori registrino le password degli utenti per violare gli altri account dei loro utenti, in particolare la loro posta elettronica.

Non potrebbero memorizzare le password dei loro utenti in testo normale senza che gli utenti lo sappiano?

Esiste un modo per un utente di rilevare / impedire ciò?

Non puoi, ecco perché è importante utilizzare password diverse su siti diversi. Almeno, quando la sicurezza è importante per te (forum casuali o siti di e-commerce potrebbero non avere importanza). Se fai fatica a ricordare tutte quelle password, usa un gestore di password.
@paj28 Questo è * uno dei motivi * è importante. Ce ne sono altri.
Un sito che fa questo è Mint.com. Non so se memorizzano le mie password bancarie in testo normale, ma devono almeno essere in grado di ricostruire le mie password in testo normale perché la maggior parte delle banche non dispone di API autenticate adeguate per accedere ai propri dati. Detto questo, uso ancora Mint nonostante questo grave difetto di sicurezza. L'usabilità del sito web / applicazione Android della mia banca è così terribile che ho praticamente rinunciato a una buona sicurezza a favore dell'uso effettivo.
Anche se non c'è il rischio che questo dia falsi positivi, sicuramente darà molti falsi falsi: chiedi ai siti web la tua password, se te la restituiscono in chiaro invece di forzare una nuova password, puoi dire con certezza che è stata memorizzata in chiaro. Ovviamente potrebbero memorizzarlo come testo in chiaro ma costringerti a crearne uno nuovo. È più probabile che trovi uno sviluppatore ingenuo che sinistro.
Perché non esiste ancora un modo standardizzato per eseguire l'autenticazione con chiave pubblica? (Chiedere al browser di generare una coppia di chiavi e inviare solo la chiave pubblica al server, quindi salvare la chiave privata in locale, facoltativamente con una password)
A meno che tu non possa esaminare completamente l'hardware e il software del sito nel momento in cui inserisci la password, non puoi esserne "sicuro".
Non dimenticare che non si tratta * solo * di password: uno dei motivi per cui odio le "domande per la reimpostazione della password" è che sei più o meno costretto a utilizzare le stesse su tutti i siti web (che hanno le stesse domande - molto comuni). Ovviamente, le password sono la cosa più abusata * automaticamente *, ma ci sono altre informazioni che possono essere utilizzate anche contro di te (come "gli ultimi 4 numeri della tua carta di credito" ecc.) - ognuna di esse innocua da sola, ma insieme ... E sarei più diffidente nei confronti degli sviluppatori ingenui, piuttosto che del tutto malizioso. Almeno fintanto che non visiti molti siti Web `.ru`: D
Non lo sai mai. Io stesso ho creato un sistema interno che memorizza la password ogni volta che un utente si autentica nel sistema. Funziona bene per un po 'finché non mi sento pigro e lo rimuovo dal sistema.
@Luaan ha davvero un buon punto - questo è il motivo per cui uso risposte fasulle a queste domande anche sui siti più importanti (qualsiasi cosa finanziaria) ... Posso sempre andare in banca se assolutamente necessario per dimostrare la mia identità.
@user1801810 Uso lunghe stringhe casuali come risposte e le conservo in un luogo relativamente sicuro. Se perdo sia la posizione sicura che la password, beh, sì, ci sono modi più diretti per essere verificato. È solo un'altra cosa a cui prestare attenzione :( E lo chiamano * miglioramento * della sicurezza ...
Non puoi sapere se si comporteranno in modo etico (e competente) con i tuoi dati, ma a volte puoi scoprire quando non lo fanno. Nel caso della memorizzazione delle password in testo normale, se compaiono in [** Plain Text Offenders **] (http://plaintextoffenders.com/) allora è una grande bandiera rossa fare attenzione a ciò che gli dai.
@StephanBranczyk Vorrei aggiungere che avendo lavorato per diversi istituti bancari nei loro diversi dipartimenti di "sicurezza", farete sicuramente bene a non fidarvi di loro nel mantenere la vostra password in modo sicuro, non reversibile e criptato.
@immibis TLS consente di fornire al server certificati client che possono essere utilizzati per scopi di autenticazione, ma la generazione è costosa (sia in termini di tempo che di entropia), generalmente è un problema spostarsi tra i dispositivi e l'interfaccia utente è normalmente incoerente tra le implementazioni (e talvolta le modifiche tra le versioni). Escludendo le limitazioni imposte dal sito Web come la lunghezza massima della password (che non dovrebbe essere necessaria se si esegue l'hashing corretto della password, ad esempio) le password possono essere rese arbitrariamente complesse. I certificati client TLS presentano anche alcuni problemi pratici durante l'uso.
Anche se puoi fidarti perfettamente di loro per comportarsi eticamente, non puoi fidarti di loro per non commettere mai errori. Tutti commettono errori e qualcuno potrebbe commettere uno dei propri errori durante la codifica della modalità di memorizzazione della password.
"Revisioni del codice" ....
Non puoi, ho siti web che ho codificato anche prima di entrare all'università e sì, memorizzano ancora password in testo normale ..: / Gli sviluppatori sono pigri, se il framework non lo supporta in modo nativo, c'è un altorischio che non abbiano implementato l'hashing.Usa gestori di password!
Cinque risposte:
AviD
2015-06-07 14:24:28 UTC
view on stackexchange narkive permalink

Ovviamente potrebbero, ma potrebbero anche semplicemente inviare un'email a se stessi ogni volta che cambi la password.

Ora, a seconda del tipo di sistema, ci sono molti regolamenti, controlli, revisioni e processi che potrebbero essere rilevanti per garantire che gli sviluppatori non lo facciano o molti altri tipi di attività dannose . Tuttavia, tu, come consumatore, di solito non hai molte informazioni su nulla di tutto ciò, tranne quando va storto, ad esempio se ti inviano un'email con la tua password originale quando chiedi di reimpostarla.

Ma qui stai facendo la domanda sbagliata.
Sì, è importante che i sistemi che utilizzi siano sviluppati in modo sicuro, ma ciò non rimuoverà mai l'elemento di fiducia implicita che avrai sempre nel sistema stesso e, in questo contesto, gli sviluppatori sono equivalenti al sistema stesso.

La vera domanda che dovresti porre - e in effetti sembra che tu lo stia sottintendendo - è come proteggere i tuoi altri account, su altri sistemi, da uno sviluppatore dannoso o sistema .
La risposta è semplice, davvero: usa una password diversa per ogni sistema.

Consentitemi di ripeterlo, per enfasi:

NON RIUTILIZZARE MAI PASSWORD SU SISTEMI DIVERSI.

Crea una password univoca (forte, casuale, ecc.) per ogni sito e non inserire mai la tua password per SiteA su SiteB.
Perché, come hai notato intuitivamente, se SiteB ha la tua password per SiteA in qualsiasi forma, quindi quella password non è più protetta da SiteB.

Solo per divertimento, ecco un xkcd su questo:

XKCD Password Reuse

Un'ultima nota, se stai iniziando a preoccuparti "Come diavolo faccio a ricordare una password complessa indipendentemente per ogni sito diverso ?? !!?" - dai un'occhiata a questa domanda qui sulle passphrase e controlla anche i gestori di password (ad esempio Password Safe, Keepass, LastPass, 1Pass, ecc.).

un'alternativa ad avere una password separata per ogni sito è avere una manciata di password che usi e passare da una a seconda del livello di sicurezza di un sito a quanto ti fidi di esso. I.E. una password per la tua posta elettronica (che controlla la reimpostazione della password), una per i tuoi istituti bancari e un'altra per tutti i siti Web scadenti (forum / siti di giochi, siti che ti obbligano a creare un account, ecc.). proprio come hai un'e-mail di spam (o dovresti), dovresti avere una password spam.
Invece dei gestori di password ** ** consiglierei un generatore di password **. Creerà password univoche dall'indirizzo del sito Web con hash + la tua password principale. Questo non solo ti eviterà di ricordare le password, ma anche di inventarle!
L'uso continuo di generatori di password come tu descrivi è problematico @Agent_L. Non si adattano molto bene alle modifiche alla password principale o alle password del sito. Se qualcuno è in grado di utilizzare un gestore di password, probabilmente dovrebbe farlo.
n00b - quindi se ottengo la tua password da un attacco a una banca che perde informazioni, posso ottenere tutti i tuoi conti bancari? Hmmm - non è il tuo miglior piano!
@PwdRsch Come tutto, è una questione di sicurezza contro usabilità e come ogni volta si tratta di scegliere lo strumento giusto per una determinata attività. Certo, per la casella di posta principale e la banca ci sono password univoche che non dovrebbero essere archiviate da nessuna parte ma ricordate. Ma la maggior parte di noi ha dozzine di account la cui sicurezza non significa quasi nulla. I generatori sono perfetti per questo, poiché gli inconvenienti che hai appena descritto non si materializzano mai.
@agent_l ogni gestore di password che ho esaminato include un generatore di password per quando hai bisogno di una nuova password. Dubito che qualcuno crei effettivamente le proprie password se utilizza un manager.
I generatori sembrano interessanti, ma se generi sempre le tue password usando lo stesso seed + sitename e non salvi mai il risultato, come resetti la password su un sito che è stato compromesso? No, i gestori di password sono la strada da percorrere. Ognuno dei miei account, non importa quanto vitale o banale, ha una password casuale di 16 caratteri univoca ad esso associata.
@Mikkel 16 caratteri? Questa è la scuola elementare ;-) Se non hai bisogno di ricordartelo comunque, alzalo! 26 caratteri, 32, facile ... (Anche se è discutibile quanti vantaggi aggiuntivi otterresti dopo, ad esempio 26 caratteri ...)
@Agent_L, come ha detto sgroves, tutti i gestori di password decenti includono la generazione di password (che fa parte della gestione, non è solo "ricordare"). Non ero esplicito, ma questo è sempre dato per scontato quando parliamo di gestori di password.
@sgroves, AviD, Mikkel - nessuno di voi ha affrontato il mio punto principale: le password importanti sono troppo importanti per essere salvate in un manager. Le password banali sono troppo banali per essere salvate in un gestore. Questo è il punto: non mi interessa se la mia password Stack è stata compromessa - c'è troppo poco che posso perdere per preoccuparmene. Non utilizzo i gestori per salvare la password della mia workstation: è troppo importante per essere salvata ovunque (inoltre, non posso utilizzare un gestore per l'accesso a Windows). Comunque, questa discussione è grossolanamente offtopica in quanto anche la risposta non è in tema.
@Agent_L ma ho affrontato questo. Le password importanti devono essere forti, davvero forti, troppo forti per essere ricordate. D'altra parte, CI SONO situazioni in cui è necessario ricordare effettivamente la password, ed è qui che entrano in gioco le passphrase, come ho menzionato nella mia risposta.
"Ma qui stai facendo la domanda sbagliata." No, stai rispondendo alla domanda sbagliata. Il primo e il secondo paragrafo sono ok, il resto è solo gonfio.
@ChristianStrempfer perché pensi che sia la domanda sbagliata? L'OP era chiaro che era preoccupato che gli sviluppatori utilizzassero la sua password per accedere al suo account di posta elettronica. Ho chiarito perché "come impedire che gli sviluppatori registrino le password degli utenti" è la soluzione sbagliata, e oltre al punto. Era chiaro che questo è un caso di problema XY; L'ho concentrato sulla causa principale e gli ho indicato soluzioni reali per il suo vero problema.
@agent_l quali password sono troppo importanti per salvare in un gestore? forse qualcosa per lavoro, ma potresti usare un account separato per quello. Conserverò felicemente tutte le password in un gestore, però ... è tutto memorizzato localmente.
@AviD: Non è chiaramente un problema XY per me. L'OP è consapevole che conoscendo la semplice password, potrebbe essere usato per "hackerare" un altro sito. È una domanda breve al punto.
@AviD: Non fraintendermi. Non è un problema menzionare i pericoli del riutilizzo della password, ma costituisce il 90% dell'altezza delle risposte sullo schermo, mentre dovrebbe essere solo una nota a margine.
@ChristianStrempfer l'OP sta basando la sua valutazione del rischio della minaccia "sviluppatore non etico che non ha hashing la password", sul presupposto del riutilizzo della password. A me, questo sembrava essere il nucleo di esso, quindi perché ho detto che è un problema XY, IMO. Questo è il motivo per cui ho concentrato la maggior parte della risposta sulla risposta al problema del riutilizzo della password.
Grizzled
2015-06-07 15:48:17 UTC
view on stackexchange narkive permalink

Non puoi sapere che qualcuno si comporterà in modo etico o saggio, quindi:

  1. Non riutilizzare mai le password tra i siti.
  2. Decidi quante informazioni condividere.
  3. Trattieni le informazioni che non sono richieste e sospetto che qualsiasi sito web che richieda più informazioni di quelle necessarie per darti un particolare servizio.

Temo che alcuni sviluppatori non siano Non è abbastanza lungimirante per comprendere le implicazioni di una fuga di informazioni per i propri utenti, quindi proteggiti piuttosto che fare affidamento sugli altri.

+1 "o saggiamente", perché per me c'è poca differenza pratica tra un programmatore che ruba intenzionalmente la mia password, e un amministratore di sistema che aggiorna l'installazione di Linux, il server viene rootato e qualche hacker ruba la mia password. Semmai preferirei * leggermente * che fosse il programmatore, dato che l'azienda coinvolta ha almeno un indirizzo da dare alla polizia.
... ha un indirizzo da dare alla polizia: sono un libero professionista che lavora dall'Asia e quasi nessuno chiede il mio indirizzo. Ma gli sviluppatori e gli amministratori di sistema hanno una grande fiducia nella catena.
fotijr
2015-06-08 18:22:12 UTC
view on stackexchange narkive permalink

Come altri hanno detto, non puoi sapere completamente cosa stanno facendo gli sviluppatori con i tuoi dati una volta che li hai consegnati. Può darti un po 'di fiducia nell'esaminare come funziona il sito per vedere se seguono le migliori pratiche di sicurezza sui pezzi del sistema visibili a te.

  • Usano HTTPS su pagine con informazioni sensibili (incluso il login)?
  • Evitano di trasmettere la passphrase ovunque, inclusa la posta elettronica (nemmeno a te)?
  • Consentono l'autenticazione a due fattori?

La selezione di queste caselle non garantisce che non stiano facendo qualcosa di losco altrove, ma ti dà un'idea migliore di come gli sviluppatori hanno configurato il sito.

Come accennato, evitare il riutilizzo della password è la pratica di sicurezza più importante che puoi seguire per proteggerti.

Aggiungerei una casella aggiuntiva per controllare: "Limitano inutilmente i caratteri che puoi utilizzare nella tua password?" Una password con hash corretto è difficile da distinguere dai dati binari casuali, quindi tutto ciò che memorizza un hash di questo tipo deve essere in grado di tenere conto di qualsiasi sequenza possibile (ad esempio, codificando in esadecimale l'hash per l'archiviazione e quindi decodificandolo quando devi confrontare qualcosa con l'hash). Se il sito limita i caratteri che puoi utilizzare nella tua password, potrebbe essere perché qualcuno non la memorizza correttamente.
@TheSpooniest: Il codice richiesto per mappare stringhe ASCII in sequenze di byte in modo tale che le stringhe che si confrontano uguali producano sempre la stessa sequenza di byte è banale. Il codice richiesto per fare lo stesso con tutte le possibili stringhe Unicode è estremamente complicato e ha molti strani casi d'angolo, specialmente se si considerano le possibilità di caratteri misti da sinistra a destra e da destra a sinistra. Si potrebbero consentire molti caratteri non ASCII senza difficoltà, ma è più facile fornire un piccolo elenco di caratteri consentiti piuttosto che spiegare quali caratteri sono e non sono consentiti.
@supercat: Questo vale solo se stai tentando di mostrare le password agli utenti, e spero davvero che tu non lo stia facendo. In caso contrario, scegli semplicemente una codifica da utilizzare internamente, codifica la password di conseguenza, eseguila tramite l'algoritmo di hashing e Base64 o codifica esadecimale. Dopodiché, è solo una questione di assicurarsi che i campi della password utilizzino quella codifica o che sia possibile rilevare la codifica che usano se per qualche motivo devono usarne una diversa.
@TheSpooniest: Con ASCII, si può benissimo garantire che se qualcuno digita "Fred123" come password, ogni carattere ASCII genererà un codepoint; se qualcuno digita una password con segni diacritici o una combinazione di caratteri da destra a sinistra o da sinistra a destra, la sequenza esatta dei punti di codice ricevuti potrebbe essere diversa su browser diversi. Se qualcuno digita un accento di combinazione seguito da una lettera e la combinazione si trova nelle tabelle di alcuni browser ma non in altri, alcuni browser potrebbero riportarlo come un carattere e altri come due. Se si memorizzasse il testo normale, sarebbe possibile ...
... per dire accetta qualsiasi password la cui forma normalizzata corrisponde alla forma normalizzata di ciò che è nel database, e non devi preoccuparti della possibilità che una tabella di normalizzazione errata possa far sì che il database memorizzi un hash che non corrisponderà correttamente a nessuno- password normalizzate dopo la correzione della tabella.
Andrew Smith
2015-06-07 13:14:35 UTC
view on stackexchange narkive permalink

Un modo per sapere se sono in grado di ottenere la tua password è se il sistema di password dimenticate è in grado di inviarti via email la tua vecchia password. Se ti costringe a generarne o impostarne uno nuovo, è comunque possibile che siano stati memorizzati in testo normale / crittografia a 2 vie.

L'altro modo in cui potresti capirlo è registrarti per un account hotmail gratuito e registrandoti ad alcuni siti (attendibili) con la stessa password, vedi se succede qualcosa.

A parte questo, non puoi davvero dirlo.

Agent_L
2015-06-08 22:25:48 UTC
view on stackexchange narkive permalink

L'unico modo in cui un sito web può provare che NON sta memorizzando la tua password in chiaro è di non riceverla mai in chiaro. Ciò può essere ottenuto solo tramite script di hashing lato client. A meno che tu non possa analizzare il codice del sito web e / o rilevare il traffico, devi presumere che l'amministratore abbia piena conoscenza della tua password in testo normale.

Vedi questa domanda di un amministratore che voleva dai ai suoi utenti la tranquillità che cerchi. ha molte risposte interessanti, anche se la maggior parte di esse si concentra sulla sicurezza invece che sulla prova di non memorizzare testo in chiaro.

@cHao: questo è stato discusso nella domanda http://security.stackexchange.com/questions/23006/client-side-password-hashing e l'OP è giunto alla conclusione che il modo migliore per fare le cose era l'hash su entrambi i lati del cliente al server.L'hash lato server risolve il problema di riproduzione della password menzionato e l'hash lato client impedisce al sito Web di determinare il tipo di tipi di password utilizzati dall'utente (password utente simili tra i siti e / o tra le modifiche della password).
@MarkRipley: Sembra una buona idea.Purtroppo non ricordo esattamente a quale commento stai rispondendo, perché sembra che non esista più.: P Ma guardando la risposta, posso reimmaginare quello che avrei detto ...
@cHao AFAIK ti sei imbattuto in un problema completamente diverso di un attacco di replay, proprio come la risposta collegata.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...