Tag: password

  • Specificare una password

    cavolo

    La password deve essere almeno di 8 caratteri.

    cavolo bollito

    La password deve contenere almeno un carattere numerico.

    1 cavolo bollito

    La password non può contenere spazi.

    50cazzodicavolivolliti

    La password deve contenere almeno un carattere alfabetico maiuscolo.

    50DANNATIcazzodibolliti

    La password non può contenere più di un carattere maiuscolo consecutivo.

    50CazzoDiCavoliBollitiInfilatiSuPerIlTuoCulo,SeNonMiFaiAccedereSubito

    La password non può contenere segni di interpunzione.

    AdessoMiStoIncazzando50CazzoDiCavoliBolliti
    InfilatiSuPerIlTuoCuloSeNonMiFaiAccedereSubito

    La password è già stata utilizzata.

  • Generatore di password via command line

    Ogni tanto serve generare un po’ di password casuali, questo è un metodo rapido e, si spera, efficace.

    Tutto quello che serve è un *NIX e un /dev/urandom con una ragionevole entropia, magari aiutato da un software come haveged.

    Questa è l’invocazione per richiamare 1024 byte di password casuali (deve essere scritta su una riga sola, vado a capo per praticità):

    strings /dev/urandom |
    tr -c -d '\!-~' |
    dd bs=1 count=1k 2>/dev/null |
    sed -r 's/(.{12})/\1\n/g' ;
    echo

    Quello che fa questa command line è prendere da /dev/urandom solamente i gruppi di byte che corrispondono a caratteri stampabili (prima riga), filtrarli secondo un range ASCII (seconda riga), fermarsi a 1024 caratteri (terza riga), visualizzarli su righe di 12 caratteri l’una (quarta riga) e andare a capo dopo l’ultima password (ultima riga).

    Il range sulla seconda riga è uno dei più ampi possibile nel set ASCII stampabile perché lascia fuori solamente lo spazio e può essere modificato a piacere, ad esempio se si vogliono solamente lettere minuscole e numeri la seconda riga diventa

    tr -c -d 'a-z0-9' |

    Sulla quarta riga si può variare il numero 12 per avere password di lunghezze differenti o sostituire \n con \t per avere le password incolonnate separate da tab.

  • Le diecimila password peggiori

    Mark Burnett ha raccolto nel tempo varie password che sono state pubblicate per buchi nella sicurezza.

    Adesso ha deciso di pubblicare le 10.000 password più utilizzate, quindi le 10.000 password da non utilizzare mai.

    Le password sono in un file di testo, che può essere importato in un archivio di black-list per evitare che gli utenti scelgano password troppo facili da indovinare.

    (altro…)
  • Userei una password complessa, ma…

    CartaSISono anni che si sprecano litri di inchiostro e gigabyte di storage per spiegare l’importanza di una password non banale. Alla fine i suggerimenti sono sempre gli stessi, ma non sempre è possibile metterli in pratica.

    Una password come ad esempio siamogeek.com potrebbe essere rifiutata da molti siti che impongono che le password siano formate solamente da lettere o cifre. Il sito dei Servizi Interbancari è uno di questi, qui sopra si vede l’errore che mi è apparso questa mattina; non dirò quale carattere speciale avevo messo nella password, ma posso assicurare che quel carattere speciale è noto ai bambini che frequentano i primi anni delle scuole elementari. Ci sono moltissimi siti che presentano un comportamento analogo.

    La maggior parte dei siti utilizza (o dovrebbe utilizzare) una codifica che permette di avere nella stessa frase  caratteri di qualsiasi alfabeto della Terra (e non), passato e presente. Nonostante ciò, c’è ancora chi obbliga a scrivere le password con un insieme di caratteri così limitato che avrebbe fatto ridere anche i programmatori di 30 anni fa.

    Forse qualcuno teme che un utente metta come password ;DROP DATABASE;--

    O probabilmente tutti i layer Java[Script] che si frappongono tra l’utente e il database sottostante sono scritti o integrati così male che solo un apice nella password farebbe crollare tutto. Però il sito ha una bella grafica, eh! Sarà contento il Baiocchi [NSFW]

    (altro…)

  • Poi non date la colpa al malware

    Spesso c’è la tendenza ad incolpare il malware per ogni tipo di danno causato ai sistemi informativi o per ogni tipo di furto di informazioni.

    Se non si può parlare di colpa di chi scrive il software, certo il programmatore è in molti casi correo colposo (quando non è doloso, ma è un altro paio di maniche) di intrusioni illecite o furti di informazioni.

    (altro…)
  • Si trova proprio di tutto

    Abbiamo trattato varie volte il problema dei motori di ricerca che indicizzano più di quello che ci si aspetta.

    Con la formula corretta si possono trovare varie cose: chiavi private, log di trasferimenti FTP, chiavi o configurazioni dei VPN, telecamere

    Aggiungiamo questa messe di informazioni un esempio di come sia possibile cercare dei fogli di Excel il cui none finisce con la parola email:

    filetype:xls inurl:"email.xls"

    Il risultato è interessante e potrebbe essere una delle tante possibili risposte alla domanda “Ma da dove diavolo hanno preso la mia mail?!”

    Mutatis mutandis, si potrebbero cercare documenti che contengono altre parole nel nome.

    Chi ha detto “password”?

    inurl:elmah.axd "powered by elmah" password

  • 1234, 1111, 0000 … 9629, 8093, 8068

    Non ci vuole un genio del calcolo combinatorio per capire che 10 simboli combinati a blocchi di 4 danno 10.000 combinazioni diverse.

    Data Genetics in un articolo del suo blog ha condotto un’analisi si 3,4 milioni di password a 4 cifre: alcuni risultati sono ovvi, altri interessanti.

    Per estensione si potrebbe presumere di applicare questa analisi ai PIN a 4 cifre, come quello del cellulare o della carta di credito chip and pin, due contesti in cui il PIN a 4 cifre è assegnato stocasticamente, ma può essere modificato dall’utente.

    (altro…)
  • Autenticazione a due fattori per Dropbox

    Dopo i recenti episodi di hackeraggio che hanno coinvolto Dropbox, il sito ha aggiunto la possibilità di attivare l’autenticazione a due fattori.

    Il primo fattore resta la password e il secondo può essere o un messaggio che si riceve via SMS oppure un’applicazione supportata (Google AuthenticatorAmazon AWS MFAAuthenticator for Windows Phone 7).

    L’autenticazione a due fattori è un notevole passo avanti nella sicurezza, in quanto chi volesse accedere in maniera fraudolenta al vostro account di Dropbox dovrebbe conoscere la password e avere in mano il vostro cellulare.

    Vediamo come attivare l’autenticazione a due fattori.

    (altro…)

  • Reset della password

    Per vari motivi ho cercato in giro alcune linee guida su come scrivere una buona procedura di reset della password di un account via posta elettronica, ne riassumo qui alcune, in ordine sparso.

    Non modificare i dati fino alla conferma dell’utente. A meno di necessità specifiche o casi particolari, i dati di autenticazione non devono essere modificati fino all’avvenuta conferma da parte dell’utente, al fine di impedire che buontemponi blocchino l’accesso all’utente semplicemente chiedendo un reset della password.

    Usare CAPTCHA. La pagina di richiesta del reset della password dovrebbe contenere un CAPTCHA per evitare che i sistemi automatici possano attaccare facilmente il sistema oppure possano provocare disagi a più utenti.

    Utilizzare una buona fonte di entropia. L’URL per il reset della password inviato via mail deve contenere una parte casuale, che non deve essere legata al timestamp o ad altri valori deterministici. È bene utilizzare sempre il generatore di numeri casuali disponibile sul sistema (/dev/urandom per *NIX) anziché una funzione di libreria del linguaggio.

    Limite di tempo. L’URL utilizzabile per il reset della password deve avere una scadenza oltre la quale non è più valido.

    Spiegare bene. Sia la pagina di reset della password sia le mail che vengono inviare all’utente devono essere ben chiare e spiegare bene la modalità di reset. In particolare, la mail deve indicare in maniera precisa il nome del sito di cui si sta reimpostando la password, il termine ultimo di validità e le azioni da intraprendere se chi riceve la mail non ha chiesto il reset della password.

    Confermare. Una volta terminata (o cancellata) l’operazione, è bene inviare una seconda mail di conferma all’utente.

    Monitorare. Una funziona amministrativa dovrebbe segnalare gli account di cui viene richiesta spesso la reimpostazione della password. Inoltre è bene impedire un numero non-umano di richieste di reset della password nell’unità di tempo, come, ad esempio, 500 richieste all’ora.

    HTTPS. Se possibile, utilizzare HTTPS con un certificato valido per il form di richiesta di reset e per l’URL di sblocco.

    Cookie. Non devono essere utilizzati i cookie per identificare l’utente ed eventuali cookie di sessione o di identificazione devono essere cancellati nel momento in cui la password viene reimpostata.

    Riservatezza. Se nel form di richiesta password si richiede direttamente la mail (da evitare, se possibile), quando viene inserita una mail sconosciuta, il programma deve comportarsi allo stesso modo in cui si comporterebbe se la mail fosse di un utente registrato, al fine di impedire ad un eventuale curioso o attaccante di capire se una mail corrisponde ad utente effettivamente registrato.

    Va da sé che queste sono linee guida che si applicano a siti normali, per ambienti che richiedono una sicurezza maggiore devono essere messe in campo procedure completamente diverse.

  • Buco di sicurezza in MySQL/MariaDB

    È stato scoperto un pericoloso baco in MySQL/MariaDB che potrebbe permettere l’accesso come root ad un database server.

    La vulnerabilità non funziona su tutte le installazioni di MySQL (inclusa CentOS) e dipende da come è stato compilato il server.

    Il problema risiede nella routine di autenticazione di un utente. Quando viene aperta una connessione a MySQL/MariaDB viene generato un token calcolando un SHA della password fornita e di una stringa casuale; il token viene quindi confrontato con l’SHA calcolato con il valore corretto. Per un errore di cast potrebbe succedere che le due stringhe vengano considerate uguali anche se non lo sono e anche se memcmp() ritorna un valore diverso da zero; se si verifica questo caso, MySQL/MariaDB pensa che la password sia corretta e permette l’accesso. La probabilità che questo accada è di 1/256.

    (altro…)