PHP - crittografare il nome utente e la password dell'altro sito

Question

Sto programmando un sito PHP che consente agli utenti di registrarsi e gli utenti registrati e non registrati possono inserire i rispettivi nomi utente e password (ad esempio smith8h4ft - j9hsbnuio) per il sito della scuola.

Poi, il mio script PHP invia alcuni $_POST variabili, download e analizza la pagina marchi, rendendo un array di nome: marksDB = Array("subject" => Array("A", "B", "A", "C"), ...), e lo scrive riformattato.

La mia domanda è: Come dovrei mantenere il nome utente e le password al sicuro?

Per gli utenti non registrati, attualmente dimentico nome utente e password e inserisco marksDB in $_SESSION. Quando l'utente è inattivo per es. 30 minuti, contrassegniDB è cancellato. Quanto sono sicuri questi dati in $_SESSION? E che dire degli utenti che accedono, visualizzano la pagina una volta e non la visualizzano mai più, quindi lo script non cancella gli indicatoriDB dalla sessione? La sessione viene cancellata automaticamente (gc.maxlifetime)?

E per quanto riguarda gli utenti registrati? Voglio avere tutto al sicuro, ma non voglio infastidire l'utente con richieste di password ogni 30 minuti di inattività. È sicuro crittografare credenziali come descritto in here, ma senza la terza password impostata dall'utente? Oppure devo chiedere all'utente la sua password ogni volta?

EDIT:

Grazie per le risposte veloci,
@Justin ᚅᚔᚈᚄᚒᚔ: dubito che abbiano alcune API, ma li posso chiedere, solo per caso
@Abid Hussain: Grazie per i link molto utili . (Grazie anche per le risposte).
Lancerò via le credenziali degli utenti e ho solo analizzato lo markDB, che probabilmente getterò anch'io (dopo il logout o l'inattività) - è economico recuperare nuovamente i segni quando necessario.

Answer 1

Se il sito della scuola non espone un'API per questo (ad esempio, using OAuth like the StackExchange sites do), le opzioni sono limitate.

In generale, non è mai una buona idea mantenere le credenziali in chiaro in un utente più a lungo di quanto sia assolutamente necessario.Ci sono implicazioni di sicurezza per ogni possibile modo in cui puoi immaginare di provare a farlo (session hijacking, chiavi rubate, decifrazione, ecc.).

Un approccio migliore potrebbe essere quello di rendere il processo di download dei segni strettamente avviato dall'utente. Dare loro un pulsante che dice "recupera i miei voti", e passare attraverso il processo di autenticazione lì, scaricare i marchi e buttare via le loro credenziali. Ogni volta che si "sincronizzano", devono essere autenticati. A meno che i segni non cambino su base periodica frequente, non ci dovrebbe essere alcun motivo per cui non è possibile scaricare tutte le informazioni necessarie in una sola volta e quindi memorizzarle in modo sicuro sul server per un utilizzo successivo.

Answer 2

Il file di sessione è lato server quindi dovrebbe essere invisibile ai client. Ma possono ancora ingannare il tuo programma usando un'altra sessione se conoscono l'ID della sessione.

Per gli utenti registrati è possibile memorizzare la password in un DB o un file dopo aver criptato con una chiave che solo tu conosci (forse uno nuovo generato in modo casuale e memorizzata per ogni utente)

Answer 3

file di sessione verranno eliminati dal garbage collector dopo un certo periodo di tempo, ma una buona regola empirica per la memorizzazione in _SESSION è solo i dati del negozio che verrebbero visualizzati sullo schermo, ovvero la password probabilmente non è qualcosa che si desidera archiviare nella sessione. I file di sessione possono essere letti dal server ed è possibile che alcuni utenti malintenzionati possano dirottare la sessione e vedere cose che non dovrebbero vedere o addirittura vedere in qualche modo un var_dump($_SESSION).

Se si desidera consentire agli utenti registrati sessioni più lunghe, è possibile avere aggiornamenti periodici delle pagine con JS (non necessariamente aggiornando la pagina .. sarà sufficiente una richiesta asincrona) o addirittura aumentare il tempo di sessione con ini_set se consentito. Non è necessariamente più sicuro chiedere le password ripetutamente .. dipende da quanto è vulnerabile la password quando stai chiedendo.

Un'altra soluzione consiste nell'avere il famigerato cookie "Ricordami" che consente agli utenti di accedere.

Le password non sono per la decifratura. Criptare per segretezza. Hash per l'autenticazione.

Answer 4

Tutto nella sessione è lato server, quindi non è accessibile da altri. Tuttavia, le sessioni possono essere "dirottate" come spiegato here.

È possibile aumentare la durata della sessione nel PHP.ini o utilizzare chiamate AJAX periodiche sullo sfondo per mantenere attiva la sessione. Le sessioni vengono cancellate quando sono scadute dal server.

La crittografia di una password in modo che possa essere decifrata è solitamente disapprovata a meno che non ci sia alternativa. Con la crittografia, non solo tu, ma anche chiunque altro abbia accesso al tuo database e/o al codice sorgente può recuperare le password.

Answer 5

See URL

http://phpsec.org/projects/guide/4.html

http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/

http://talks.php.net/show/phpworks2004-php-session-security

http://segfaultlabs.com/files/pdf/php-session-security.pdf

safest way to create sessions in php

Leggi anche

Le sessioni sono significativamente più sicure, ad esempio, dei cookie. Ma è ancora possibile rubare una sessione e quindi l'hacker avrà accesso a tutto ciò che è in quella sessione. Alcuni modi per evitarlo sono IP Checking (che funziona piuttosto bene, ma è molto basso fi e quindi non affidabile da solo), e usa un nonce. In genere con un nonce, si dispone di un "token" per pagina in modo che ogni pagina controlli che il nonce dell'ultima pagina corrisponda a ciò che ha memorizzato.

In entrambi i controlli di sicurezza, c'è una perdita di usabilità. Se si esegue il controllo IP e l'utente si trova dietro un firewall intranet (o qualsiasi altra situazione che lo causa) che non mantiene un IP stabile per quell'utente, dovrà eseguire nuovamente l'autenticazione ogni volta che perde il proprio IP. Con un nonce, si ottiene sempre la situazione "Facendo clic indietro causerà la rottura di questa pagina".

Ma con un cookie, un hacker può rubare la sessione semplicemente utilizzando tecniche XSS piuttosto semplici. Se si memorizza l'ID sessione dell'utente come cookie, anche questo è vulnerabile. Quindi, anche se la sessione è solo penetrabile a qualcuno che può fare un hack a livello di server (che richiede metodi molto più sofisticati e di solito una certa quantità di privilegi, se il tuo server è sicuro), hai ancora bisogno di un ulteriore livello di verifica su ogni richiesta di script. Non dovresti usare i cookie e AJAX insieme, poiché questo rende un po 'più facile andare in città se quel cookie viene rubato, poiché le tue richieste di ajax potrebbero non ottenere i controlli di sicurezza su ogni richiesta. Ad esempio, se la pagina utilizza un nonce, ma la pagina non viene mai ricaricata, lo script può verificare solo la corrispondenza. E se il cookie è in possesso del metodo di autenticazione, ora posso andare in città a fare la mia cattiveria usando il cookie rubato e il buco AJAX.