Database Password

16/08/2016 09:54:53

La cosa strana in questa percentuale è che, di base, gdrcd ha la criptazione di default. Quindi tutti i gestori che creano un gdr online con quell'open source hanno la possibilità di criptare le password e soprattutto ce l'hanno impostata di default, quindi non possono "scordarsi" di metterla, ma se la tolgono lo fanno volontariamente...

quota

16/08/2016 10:52:44 e modificato da blancks il 16/08/2016 10:56:38

Di fatti, probabilmente avranno usato qualcosa di precedente a gdrcd 5.1, ad esempio l'extreme, e deve essere stato veramente sfortunato l'autore del topic ad incappare in ben due land simili.

Tutti i gestori delle land che si ostinano ad aprire basandosi su quel codice obsoleto (extreme o altri dello stesso periodo) spesso non ne hanno semplicemente idea e lasciano la password in chiaro.

C'è anche la possibilità che si trattasse di codice proprietario però, semplicemente perché la maggior parte di quelli che ho visto in giro fallisce nei più basilari controlli di sicurezza.

---

quota

16/08/2016 13:51:33

mi sorge però un dubbio: per quale motivo una persona dovrebbe mettersi a fare brute force su una password per un PBC quando ci sono sistemi molto più semplici o, meglio, obiettivi più interessanti?

davvero un cracker pensate abbia voglia di mettersi a perdere ore ed ore di calcolo al 100% di CPU per la password su una land di 20 persone?


fate prima, in un qualsiasi discorso via skype, a domandare "com'era il nome del tuo cane?" e via, mail fregata.

---

quota

16/08/2016 14:40:05

Dipende da tanti fattori.
Se si tratta di un attacco mirato, una delle opzioni per un attaccante è quella di sfruttare la pigrizia dell'utente (che di solito usa la stessa password per una considerevole quantità di servizi online) e provare a violare i siti web che usano meccaniche di sicurezza più deboli rispetto ai servizi di punta.

Non serve neanche fare il bruteforce, in una vecchia land tramite injection riuscivo a visualizzare tutti i dati presenti nel database facendomeli scrivere in un messaggio privato ad esempio, a quel modo si può recuperare l'hash ed elabolarlo interamente su una macchina dedicata. In quel caso era md5, ti sorprenderesti a vedere tra rainbow tables, hash collision e bruteforce quanto poco tempo ci voglia a scoprire la password di quell'utente.

E' chiaro, la sicurezza deve essere sempre adeguata al contesto, non puoi investire in determinate cose come fanno gli obiettivi "più interessanti".

Ma consideriamo sempre che qui si sta parlando di usare un algoritmo di hashing robusto e di consigliare all'utente di cambiare password una volta ogni sei mesi, non si parla di mandare l'uomo su marte.

---

quota

16/08/2016 14:45:35 e modificato da dyrr il 16/08/2016 14:49:52

La questione non è tanto perche qualcuno dovrebbe mettersi a fare una cosa del genere, perchè se arrivi alla password anche solo hashata vuol dire che sei dentro il database in qualche modo vuoi sqlinjection, vuoi perchè hai la pass del database in qualche modo e puoi farci tutto quello che vuoi.

il problema è che se hai le password salvate in chiaro e qualcuno accede al database il disagioc he puoi creare alle persone può essere grande.

Questo perchè, anche se sulla carta è una pratica sbagliatissima, solitamente le persone non usano una pass diversa per account diversi, e spesos nemmeno gruppi di pass diversi in base al tipo di account (una pass per i gdr, una per che ne so i forum, una diversa per ogni account importante: home banking, paypal, ecc) ma spesso usano anche una sola pass.

E se ti fregano il database e poi in qualche modo con la pas sin chiaro fanno danni a quell'utente non puoi rispondergli "colpa tua che non hai pass diverse" perchè l'obbligo di legge impone a te gestore del database di adottare le misure di sicurezza minime necessarie.

quota

16/08/2016 15:20:40

si certo, il mio dubbio era sul perchè impegnarsi oltre il necessario per la protezione quando quella di base basta (criptazione).

tenere le password in chiaro è da criminali ma ricordiamoci che fino a pochi anni fa era per tutti così...


come suggerito da Blancks (ed era un po quello che volevo far trasparire) è che magari si perde tempo ad avere tecniche elaborate per le password e poi lasciano i background in HTML con JScript attivato, senza nemmeno doversi impegnare con SQL injection

---

quota