Come funzionano i sistemi di login? [chiuso]

Questa domanda ha alcune supposizioni errate, cercherò di chiarirle prima:

I sali non vengono utilizzati come input per la crittografia ma come input per funzioni unidirezionali come gli hash.

Alcuni siti possono archiviare database di password, ovvero il modo in cui possono essere violati e le password degli utenti rubate, ma NON dovresti farlo. La pratica generale è di memorizzare gli hash delle password (e dei sali, vedi sopra) e quando un utente prova ad accedere, hash la password fornita e confronta gli hash.

[Google fa tutto rapidamente. Non so se mappano / riducono per l'autenticazione ma hanno un sacco di persone intelligenti che lavorano su di esso, forse questa dovrebbe essere una domanda separata.]

Gli hash salati vengono quindi memorizzati da qualche parte sul server. In termini di sicurezza, non credo che faccia alcuna differenza se li si archivia in un file, in un database relazionale o in un database NOSQL. Per velocizzare la "scala web", probabilmente vorrete dare un'occhiata ai database NOSQL e memorizzare nella cache i dati piuttosto che usare l'IO su disco.

Ci sono molti modi, ma quello di base è chiamato challenge-response.

Qui è dove la password dell'utente non viene mai inviata al server, ma viene invece crittografata (usando un algoritmo hash). L'hash viene inviato al server, di solito su un canale crittografato e salvato per dopo.

Quando l'utente vuole accedere, invia una richiesta di accesso, il server quindi crittografa un messaggio di qualche tipo (la sfida) e genera anche la risposta corretta (cioè crittografa la sfida usando l'hash memorizzato). La sfida viene inviata al client che calcola quale dovrebbe essere la risposta (prendendo la password dell'utente e rigenerando l'hash dalla password). Il client invia questa risposta crittografata al server che la confronta con la risposta corretta pre-calcolata. Se corrispondono, il client deve avere la password corretta per generare la risposta corretta e tu gli permetti l'accesso.

La parte buona è che la password non viene mai inviata al server, tranne durante la fase iniziale di creazione dell'account, e anche se è stata inviata come hash.

Le password sono crittografate in modo ripetibile a senso unico. Vengono quindi memorizzati in un file, database o qualsiasi cosa come [utente] - > [password crittografata].

Quando l'utente effettua il login, inseriscono un nome utente e una password. Il sito Web o l'applicazione possono recuperare la password crittografata memorizzata che corrisponde a tale nome utente prima che l'utente inserisca anche la propria password, (tramite ajax o altri metodi asincroni non appena passano i campi dal campo nome utente al campo password). Ciò consente di risparmiare tempo, ma l'applicazione deve ancora crittografare la stringa di password immessa dall'utente in modo che possa essere confrontata con la versione crittografata archiviata.

In generale, le grandi società non memorizzano gli utenti in un database. Hanno un sistema di gestione delle identità con la seguente struttura (sicuramente può variare da azienda a società, ma penso che questo possa darti un'idea):

1. Directory persona protetta (openLDAP, Active Directory, Oracle Identity Manager, ...)

   They store here everything related to persons, name, mail, username, password (encrypted), etc... (there are many schemes to use). It's used for autentication only. Not accesible from the outside.

2. Sistema di autorizzazione (ad esempio Kerberos)

   Once you've logged in correctly, you need a system that give you access to the resource you're allowed to, this is done generating a session-ticket (valid only for a period of time). This ticket tells your application if you have access to which parts of it (The common way to organize this is with groups -> roles -> application permissions).

3. Sistema Single Sign-On.

   Once you've logged in and you've got your ticket that grants you access to several resources within an organization, you can store it locally in your machine (for example with a Cookie) so that you don't have to give your username/password again and again when try to access other resource you've access to with the ticket (if your ticket expiry time have not expired yet).

Ovviamente questo può essere complicato quanto vuoi e puoi sviluppare queste soluzioni ad-hoc per la tua azienda / progetto, ma questa è l'idea generale dietro.

Quando sviluppi una webapp, ad esempio, l'approccio migliore è quello di sviluppare un livello di provider di autenticazione che possa gestire questo tipo di sistemi di accesso / autorizzazione e il più semplice nome utente / password in un database.