{"id":35,"date":"2010-02-23T10:16:09","date_gmt":"2010-02-23T09:16:09","guid":{"rendered":"https:\/\/alistapart.com\/it\/article\/il-problema-delle-password\/"},"modified":"2010-02-23T10:16:09","modified_gmt":"2010-02-23T09:16:09","slug":"il-problema-delle-password","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/il-problema-delle-password\/","title":{"rendered":"Il problema delle password"},"content":{"rendered":"
\n

\"password\"La recente rubrica<\/a> del ricercatore esperto di usabilit\u00e0 Jakob Nielsen promuove un cambio fondamentale nella progettazione del campo password nel web. Egli ritiene che sia giunto il momento di mostrare le password in chiaro mentre l’utente le scrive, abbandonando l’approccio tradizionale consistente nel mostrare una serie di asterischi o pallini al posto della password stessa.<\/p>\n

La controversa proposta di Nielsen dimostra il principio secondo il quale la maggior parte delle decisioni progettuali sul web richiedono dei compromessi. Gli obiettivi degli utenti e gli obiettivi di business non si intersecano sempre. Questioni di sicurezza, usabilit\u00e0 ed estetica competono spesso tra loro. Dobbiamo darci delle priorit\u00e0 e bilanciare questi interessi per raggiungere i migliori risultati in qualunque situazione.<\/p>\n

Le problematiche di sicurezza sono pi\u00f9 difficili da gestire perch\u00e9 sono una seccatura. Tutto ci\u00f2 che vorremmo \u00e8 far s\u00ec che le persone raggiungano il fantastico tool che abbiamo sviluppato: invece dobbiamo costruire barriere tra l’utente e l’applicazione. Gli utenti devono dar prova della loro identit\u00e0. Non possiamo accettare nessun dato da essi, a meno che questi non siano stati scrupolosamente puliti.<\/p>\n

Sfortunatamente questa \u00e8 la realt\u00e0. Una buona parte del traffico web \u00e8 davvero maligno e i dati sensibili vengono rubati. Tipicamente, per accedere ad un’applicazione, chiediamo all’utente uno username (spesso un indirizzo email) ed una password ad esso collegata. Lo username identifica la persona, mentre la password prova che la persona che sta inserendo lo username \u00e8 proprio quella persona che ha creato l’account. Questa \u00e8 la teoria, basata su due assunzioni:<\/p>\n

    \n
  1. una password non sar\u00e0 mai visibile al di fuori della testa della persona che l’ha creata,<\/li>\n
  2. sia lo username sia la password possono essere richiamate dalla memoria al bisogno.<\/li>\n<\/ol>\n

    Questo approccio mette un carico cognitivo significativo sulle persone che usano i siti web che richiedono l’autenticazione. In generale, ce la caviamo molto bene, ma \u00e8 facile vedere le debolezze di questo sistema. Le password facili da ricordare sono anche facili da indovinare. Quando le persone sono costrette a scegliere password forti, molto probabilmente le scriveranno o se le dimenticheranno. La risposta tipica a questo problema \u00e8 un meccaniscmo di reset, che naturalmente mina la solidit\u00e0 dell’intero sistema. Non importa quando la mia password sia criptata con il pi\u00f9 forte codice conosciuto all’uomo: pu\u00f2 semplicemente essere resettata da chiunque sappia quale scuola superiore io abbia frequentato.<\/p>\n

    Questa \u00e8 una delle ragioni per cui Nielsen suggerisce di abbandonare il password masking: le persone si sentono frustrate e spesso resettano una password che non hanno effettivamente dimenticato, ma semplicemente sbagliato a digitare. Dare un feedback chiaro, senza lettere oscurate, ridurrebbe gli errori, aumentando la user experience e diminuendo il bisogno di alternative insicure.<\/p>\n

    Tuttavia, apportare un cambiamento cos\u00ec radicale ad una fondamentale interazione con l’utente potrebbe presentare dei seri problemi. Considerate una situazione in cui una password debba essere inserita di fronte ad un folto gruppo di persone, ad esempio mentre si sta usando un proiettore durante una conferenza. E molti anni di esperienza web hanno creato delle aspettative su come dovrebbero funzionare gli elementi di una form. Le persone hanno capito che il password masking \u00e8 stato inventato per la loro sicurezza. Non riuscire a soddisfare queste aspettative pu\u00f2 minare la fiducia e noi non possiamo permetterci di perdere la fiducia degli utenti.<\/p>\n

    C’\u00e8 una via di mezzo, un modo per fornire un feedback e ridurre gli errori nelle password che non sacrifichi la user experience? Almeno due schemi di progettazione affrontano questa questione nelle applicazioni offline e, con un po’ di JavaScript, possiamo portarli sul web.<\/p>\n<\/div>\n

    \n

    Ora lo vedi, ora non lo vedi<\/h2>\n

    La soluzione pi\u00f9 semplice \u00e8 quella di mascherare la password di default e contemporaneamente dare la possibilit\u00e0 agli utenti di cambiare la modalit\u00e0 del campo a testo in chiaro. Perfino Nielsen incidentalmente menziona questa opzione. Questo approccio permette ad una persona di avere la conferma che la password sia stata inserita correttamente, ma pone anche il controllo fermamente nelle mani dell’utente. Questo meccanismo di cambio modalit\u00e0 si incontra spesso nel pannello preference del WiFi, ma \u00e8 raramente implementata altrove. (Nota: almeno un blog ha propugnato una simile tecnica<\/a> mentre stavo scrivendo questo articolo.)<\/p>\n

    Dovrebbe essere semplice scrivere un controllo che cambi da password a text l’attributo type di un elemento di input HTML. Sfortunatamente per\u00f2 non lo \u00e8. Internet Explorer non permette a JavaScript l’impostazione di questo particolare attributo, quindi dobbiamo essere un po’ pi\u00f9 creativi. Le due funzioni seguenti dovrebbero fare al caso nostro:<\/p>\n

    (Le righe che vanno a capo sono segnate con \u00bb ,ndr.<\/em>)<\/p>\n

    window.onload = function() {
      if(document.getElementsByTagName) {
        var inputs = document.getElementsByTagName('input');
        for(var i in inputs) {
          var input = inputs[i];
          if(input.type == 'password') {
            toggle_control = document.createElement('label');
            toggle_control.innerHTML = \"<input type=\\\"checkbox\\ \u00bb
            \" \"+ \"onclick=\\\"toggle_password('\"+ input.id+\"',this \u00bb
            .checked) \\\" \/>\"+\" Show password\";
            input.parentNode.insertBefore(toggle_control, input \u00bb

            .nextSibling);
          }
        }
      }
    }

    function toggle_password(element_id, show_text) {
      if(document.getElementById) {
        var password_input = document.getElementById(element_id);
        var new_input      = document.createElement('input');
        with(new_input) {
          id        = password_input.id;
          name      = password_input.name;
          value     = password_input.value;
          size      = password_input.size;
          className = password_input.className;
          type      = show_text ? 'text' : 'password';
        }
        password_input.parentNode.replaceChild(new_input, \u00bb
        password_input);
      }
    }<\/code><\/pre>\n
    La prima funziona fa una scansione del documento per cercare tutti gli elementi input e mette da parte quelli con type password. Si tenga presente che questo codice ha il solo scopo di dimostrare il concetto e che il processo potrebbe essere migliorato usando un framework JavaScript come Prototype<\/a>.<\/p>\n
    Dopo ogni input, la funzione inserisce un checkbox con un label che permette di cambiare il campo da testo oscurato e testo in chiaro. La seconda funzione controlla il comportamento stesso del cambio: quando l’utente clicca sul controllo per il cambio, la funzione crea un nuovo elemento input e lo scambia con quello esistente, passando il valore e le altre propriet\u00e0 da un elemento input all’altro.<\/p>\n
    Un approccio alternativo \u00e8 quello di creare il testo di input una sola volta e di scambiare le propriet\u00e0 di display per mostrare o nascondere il campo appropriato. Uno svantaggio di questo metodo, tuttavia \u00e8 che l’id dell’elemento deve essere unico. Dal momento che il testo di input parallelo avr\u00e0 il suo proprio id, non erediter\u00e0 alcuna regola CSS che faceva riferimento all’elemento originale mediante l’ID.<\/p>\n
    Guardate l’esempio uno<\/a> per vedere questa tecnica in azione. Questa soluzione \u00e8 facile da implementare e segue il principio del progressive enhancement<\/a>: in mancanza di JavaScript, i campi password manterrano il loro solito comportamento. Il controllo per lo scambio d\u00e0 il potere all’utente di poter scegliere tra il mostrare una password o il nasconderla in circostanze particolari. Il principale svantaggio \u00e8 che potrebbe ancora minare il concetto di un utente del campo password come “black box” (scatola nera). Siamo cos\u00ec totalmente abituati a pensare alle nostre password come ad un segreto che il solo offrire l’opzione di mostrarla in chiaro potrebbe sconvolgerci.<\/p>\n<\/div>\n
    \n
    Seconda alternativa<\/h2>\n
    Gli errori di battitura sono particolarmente comuni sui dispositivi touchscreen come gli iPhone, dove le dita non possono sentire al tatto i confini di un tasto. Prevedendo che l’inserimento di password senza un feedback visivo potrebbe causare dei problemi, Apple ha adottato un approccio interessante: l’ultima lettera inserita nel campo rimane visibile per un paio di secondi prima di trasformarsi in un pallino. Ci\u00f2 crea la possibilit\u00e0 di trovare gli errori senza mostrare l’intera password tutta insieme.<\/p>\n
    Possiamo riprodurre questo oscuramento progressivo della password con HTML e JavaScript, sebbene ci vorr\u00e0 un po’ pi\u00f9 di codice che per il precedente esempio. Considerate quanto segue:<\/p>\n
    window.onload = function() {
      if(document.getElementsByTagName) {
        var inputs = document.getElementsByTagName('input');
        var password_inputs = Array();
        for(var i in inputs) {
          if(inputs[i].type == 'password') {
            password_inputs.push(inputs[i]);
          }
        }
        for(var i in password_inputs) {
          var input = inputs[i];
        
          var masking_element = document.createElement('input');
          with(masking_element) {
            style.position = 'absolute';
            id             = input.name + '_mask';
            type           = 'text';
            size           = input.size;
            className      = input.className;
          }
          masking_element.onfocus = function(){this.nextSibling \u00bb
          .focus()};
          input.parentNode.insertBefore(masking_element, input);
          
          input.onchange = function() {
            
            if(this.timer){
              clearTimeout(this.timer);
            }
            
            var mask_character = \"\\u2022\";
            var last_character = this.value.charAt(this \u00bb
            .value.length-1);
            
            var masked_text    = this.previousSibling.value;
            var password_text  = this.value;
            
            if(masked_text.length < password_text.length) {
              this.previousSibling.value = password_text.substr(0,
                password_text.length-1).replace(\/.\/g,
                mask_character)+last_character;
            } else {
              this.previousSibling.value = password_text \u00bb

              .replace(\/.\/g,mask_character);
            }
            this.timer = setTimeout(\"with(document.getElement \u00bb
            ById('\"+masking_element.id+\"')){value=value \u00bb
            .replace(\/.\/g,'\"+mask_character+\"')}\",2000);
          
          }
          input.onkeyup = input.onchange;
          input.onchange();

        }
      }
    }<\/code><\/pre>\n
    Questa volta, abbiamo creato un secondo text input che si mette direttamente sopra ogni password input (gli avvertimenti sull’ereditariet\u00e0 dei CSS dell’esempio precedente si applicano a questo). Manipolando il suo valore al mutare del campo originale, possiamo controllare quello che l’utente vede. Analizziamo ogni step dello script.<\/p>\n
    window.onload = function() {
      if(document.getElementsByTagName) {
        var inputs = document.getElementsByTagName('input');
        var password_inputs = Array();
        for(var i in inputs) {
          if(inputs[i].type == 'password') {
            password_inputs.push(inputs[i]);
          }
        }
        for(var i in password_inputs) {
          var input = inputs[i];
          ...
        }
      }
    }<\/code><\/pre>\n
    Ancora una volta, il nostro primo task fa una scansione della pagina cercando i password input cos\u00ec che noi si possa poi modificare il loro comportamento. Tuttavia, c’\u00e8 una differenza sostanziale tra questa funzione e quella del primo esempio: in Internet Explorer, document.getElementsByTagName()<\/code> non ritorna una semplice lista di elementi che vanno bene nel momento in cui lo script parte, ma ritorna un riferimento alla collezione di elementi che vanno bene. Se creiamo un nuovo elemento input mentre facciamo il loop sui risultati, aumenteremmo la dimensione di tale collezione ad ogni passo, ed il loop continuerebbe all’infinito. Questo fa bloccare istantaneamente Internet Explorer (e senza grazia!). Quindi, abbiamo bisogno di copiare i risultati iniziali della funzione in un array e fare un loop su questo.<\/p>\n
    var masking_element = document.createElement('input');
    with(masking_element) {
      style.position = 'absolute';
      id             = input.name + '_mask';
      type           = 'text';
      size           = input.size;
      className      = input.className;
    }
    masking_element.onfocus = function(){this.nextSibling.focus()};
    input.parentNode.insertBefore(masking_element, input);<\/code><\/pre>\n
    Con il nuovo input inserito direttamente prima di quello esistente, mettere la sua position<\/code> ad absolute<\/code> dovrebbe piazzarlo direttamente sopra. Dovrebbe funzionare nella maggior parte dei layout, ma ci possono essere delle eccezioni dove dei CSS aggiuntivi sono richiesti per posizionarlo correttamente. Ovviamente, ora che stiamo comprendo l’input con un altro elemento, abbiamo anche bisogno di essere sicuri che cliccando sulla maschera si attivi l’input. l’aggiunta di un handler onfocus<\/code> sistema questo aspetto. Dobbiamo mettere questo handler all’esterno della dichiarazione with<\/code> affinch\u00e9 funzioni correttamente in Firefox 2.<\/p>\n
    input.onchange = function() {
      ...  
    }
    input.onkeyup = input.onchange;<\/code><\/pre>\n
    Con il nuovo elemento al suo posto, costruiremo una funzione che mostri il testo della password progressivamente nascosto. Abbiamo bisogno che questo testo risponda ai cambiamenti nel contesto del campo password. Solitamente, questo implica che un utente sta scrivendo con una tastiera, ma potrebbe benissimo non essere cos\u00ec. Qualcuno potrebbe copiare il testo nel campo usando un menu contestuale, per esempio. Attaccare il nostro codice sia all’evento change<\/code> sia all’evento keyup<\/code> dovrebbe coprire tutte le situazioni.<\/p>\n
    var mask_character = \"\\u2022\";
    var last_character = this.value.charAt(this.value.length-1);<\/code><\/pre>\n
    Possiamo designare qualunque carattere ci piaccia per mascherare le password. Tradizionalmente, la maggior parte dei sistemi usa asterischi o pallini, cos\u00ec in questo esempio abbiamo definito l’entit\u00e0 Unicode 2022, ossia il carattere del punto elenco come carattere che nasconder\u00e0 la password. Sulla seconda linea, identifichiamo l’ultimo carattere dell’attuale valore della password, cos\u00ec da poterlo rendere in chiaro.<\/p>\n
    var masked_text    = this.previousSibling.value;
    var password_text  = this.value;

    if(masked_text.length < password_text.length) {
      this.previousSibling.value = password_text.substr(0,
      password_text.length-1).replace(\/.\/g, \u00bb
      mask_character)+last_character;
    } else {
      this.previousSibling.value = password_text.replace(\/.\/g,
                                     mask_character);
    }<\/code><\/pre>\n
    Adesso possiamo prendere il valore del campo password, rimpiazzare ogni carattere con un bullet (carattere punto elenco) tranne l’ultimo e mettere quel testo nel campo che stiamo usando come maschera. Comunque, possiamo farlo solo mentre una persona sta inserendo i caratteri procedendo in avanti. In altre parole, se l’utente schiaccia il tasto backspace (delete) non riveliamo un’altra volta il carattere precedente. Una volta nascosto, il carattere dovrebbe rimanere nascosto. Cos\u00ec, prima di fare la sostituzione del carattere, dobbiamo controllare per verificare che il valore della password non sia pi\u00f9 lungo del testo oscurato. La sostituzione stessa pu\u00f2 essere fatta usando una semplice espressione regolare. L’espressione \/.\/<\/code> eguaglia ciascun carattere del campo password. Aggiungendo al lettera g<\/code> alla fine, (\/.\/g<\/code>) viene fatta una scansione dell’intera stringa di testo invece che fermarsi al primo che eguaglia.<\/p>\n
    this.timer = setTimeout(\"with(document.getElementById('\"+
      masking_element.id+\"')){value=value.replace(\/.\/g,'\"+
      mask_character+\"')}\",2000);<\/code><\/pre>\n
    Dopo un ritardo di due secondi, vogliamo che l’intera password sia oscurata. Tuttavia, i nostri utenti probabilmente non si fermeranno per due secondi dopo aver inserito ogni singola lettera. Pertanto vogliamo che il comportamento auspicato abbia effetto solo quando il campo password non \u00e8 cambiato affatto per tale intervallo di tempo. Ogni volta che chiamiamo la funzione setTimeout<\/code> in JavaScript, ci ritorna come risultato un ID che possiamo usare per referenziare quel particolare timer.<\/p>\n
    if(this.timer){
      clearTimeout(this.timer);
    }<\/code><\/pre>\n
    Memorizzando l’ID del timer in una variabile ed aggiungendo il codice di cui sopra all’inizio della nostra funzione, possiamo cancellare il countdown fintanto che osserviamo che il campo sta cambiando.<\/p>\n
    input.onchange();<\/code><\/pre>\n
    L’ultimo step consiste nel far girare la funzione che abbiamo appena definito. Questo assicura che la maschera mostrer\u00e0 il testo corretto se il campo password era stato riempito in anticipo prima che la pagina si caricasse.<\/p>\n
    Per vedere l’intero script in azione, guardate l’esempio due<\/a>. E’ stato testato in Internet Explorer 6-8, Firefox, Safari e Chrome. Ribadisco che in assenza di JavaScript questa tecnica degrada bene: il campo password semplicemente funzioner\u00e0 in maniera normale.<\/p>\n<\/div>\n
    \n
    Procedete con cautela<\/h2>\n
    Quando si ha a che fare con un’area cos\u00ec importante dell’esperienza web, dobbiamo prestare molta attenzione perch\u00e9 abbiamo a che fare con aspettative molto radicate. Il metodo username\/password usato per mettere in sicurezza le applicazioni web non \u00e8 perfetto, ma ci sono poche buone alternative ed \u00e8 diventato un approccio standard. Possiamo affrontare meglio le preoccupazioni riguardanti l’usabilit\u00e0 dei campi password testando dei cambi incrementali per estendere il comportamento di default, senza compromettere le basi dell’esperienza e non perdere la fiducia degli utenti.<\/p>\n<\/div>\n
    \n
    Pubblicato in: Browsers<\/a> e Scripting<\/a>.<\/p>\n<\/div>\n
    \n