Newsgroup: it.lavoro.professioni.webmaster
Titolo: Funzionalità resta connesso, come salvare la password?

Salve a tutti.
Nuovo dubbio, vorrei realizzare la funzionalità resta connesso per un 
sito con login.
Presumo di dover utilizzare un cookie per il mio sito, e di salvare nel 
cookie il nome utente e la password.
Il dubbio consiste nel come salvare la password. In chiaro ovviamente è 
pazzia, quindi ho pensato di salvare nel cookie il nome utente e l'hash 
(lo stesso che mantengo nel database per l'accesso) della password.
E' una modalità giusta, oppure questo mi espone a problemi di sicurezza 
che al momento non mi sovvengono?


Salva l'md5 di username.md5('password').sale_segreto_latoServer.ipRemoto
Così hai tutti gli strumenti per verificare se l'utente era loggato sul 
serio
Dopodiché considera che hanno bucato il PSN alla Sony, dimostrazione 
ulteriore che l'unico pc inviolabile è un pc senza connessione alla rete 
e spento
M
-- 
I fatti mi cosano

pazzia
Ma è proprio così che verrà salvata :-D
Se usi un "cookie" che non scade, tale che con quel cookie si può entrare
senza bisogno di reimmettere la password (se la reimmetti, allora non hai
una funzione di "resta connesso"!), quello che avrai fatto veramente è di
salvare una password alternativa in chiaro sul computer.
Solo che quella password tu la chiami "cookie".
Se vuoi un "resta connesso" con un po' di sicurezza, fai come eBay (o, se
non erro, Amazon): mandi DUE cookie. Uno che scade con la sessione ed uno
che non scade con la sessione.
Nel primo metti l'autorizzazione, nel secondo solo nome e cognome (o solo
il nome).
Così arrivi sulla pagina e compare - "Ciao Black Shard! (se non sei Black
Shard, clicca qui)". Oppure la tua pagina di eBay.
Ma appena vai a fare qualcosa di "succoso", ZAC devi mettere la password.
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!


Uhmm... interessante il discorso di ebay, ci penserò sopra. Forse però è 
un po' eccessivo per quello che devo fare, anche se sicuramente è una 
cosa buona.
Il discorso della password è che salvando lo stesso hash della password 
che ho stoccato nel database non mando in giro la password dell'utente.
E' vero che la password è sotto altra forma, però non può essere 
utilizzata per niente che non sia questa forma di accesso automatico.
Certo, se un attaccante copia il cookie del malcapitato in teoria può 
accedere comunque :/ Alchè non basterebbe nemmeno la misura restrittiva 
proposto da Motosauro

 che al momento non mi sovvengono?
Salva un ID utente, possibilmente composito (meglio un alfanumerico con 
parti random che un semplice intero progressivo), in locale, poi con 
quell'ID recuperi un oggetto in sessione contenente i dati utente.
Se l'oggetto in sessione non esiste, l'utente non è loggato.
Volendo ci sono metodi più sicuri ma credo siano decisamente 
sovradimensionati ;-)

 Ma appena vai a fare qualcosa di "succoso", ZAC devi mettere la password.
Ogni suggerimento di sicurezza mi interessa molto. Ma questa tecnica mi 
pare un po' una stupidata.
A quale fine implementare un login automatico che non è un login 
automatico? Se serve solo a mostrare un nome, ma non permette alcuna 
funzione riservata agli iscritti, a cosa serve? A dare una falsa 
percezione all'utente?
Posto che non sono interessato a dare alcuna falsa percezione ai miei 
utenti, c'è qualche altra utilità?

 (lo stesso che mantengo nel database per l'accesso) della password.
La coppia nome utente/password è un dato più riservato della possibilità 
di login. Perché con il login entri, ma la password potrebbe rivelare 
informazioni ulteriori sull'utente e permettere l'accesso ad altri siti 
dove l'utente è registrato con la stessa password o con password simile.
Io comunque il "resta connesso" l'ho implementato così:
Cookie contenente nome utente in chiaro e una stringa alfanumerica 
casuale lunga 16 caratteri estratta al momento della richiesta di 
restare connesso e salvata su database.
Alla visita cerco il cookie con nome utente e stringa, se presente 
comparo su database e se trovo l'utente lo loggo.
Questa tecnica permette, qualora li si volessero implementare, una serie 
di sistemi di sicurezza aggiuntivi, esempio:
- cancellazione su database della stringa in caso di login tradizionale 
con utente e password
- cancellazione su database della stringa in caso di logout
Queste operazioni renderebbero non più validi tutti i cookie di login 
automatico precedentemente emessi, cosa utile qualora si sospetti o si 
abbia subìto la sottrazione del cookie di login automatico.
Considerata la diffusione di reti wifi pubbliche, accesso ad internet 
gravemente insicuro, potrebbe valere la pena farci un pensiero per 
sistemi importanti/frequentati/legati a soldi o dati sensibili.
Anche se per questi casi va valutato se il "resta connesso" è davvero 
importante o è più che altro un buco di sicurezza.

 Salva l'md5 di username.md5('password').sale_segreto_latoServer.ipRemoto
Questa la metto tra le perversioni crittografiche :)
-- 
  Daniele Orlandi					つづく

 Salva l'md5 di username.md5('password').sale_segreto_latoServer.ipRemoto
Ip remoto? Quindi quando l'utente si collega il giorno dopo con la sua 
ADSL a IP dinamico non viene più riconosciuto?
Ah però, che bel sistema. :)

utenti, c'è qualche altra utilità?
Sostanzialmente, no.
Sembra[citation needed] che moltissimi utenti ogni tanto sfoglino il loro
sito preferito, ma senza compiere azioni significative - per esempio, uno
va su Amazon e vede le Recommendations.
Per fare questa operazione, la gente trova seccante[POV] loggarsi. Pero',
vuole anche la "percezione" di essere loggata - insomma, la botte piena e
la moglie ubriaca.
La soluzione adottata da entità come Amazon od eBay è quella di fornire i
servizi che "non richiedono sicurezza" (poi, possiamo parlarne: se uno va
sulla mia pagina di Amazon, e vedesse fra i suggerimenti le ultime uscite
in fatto di BDSM, magari mi imbarazzerebbe) senza autenticazione, ovvero,
con un cookie che e' una autenticazione debole.
Per pagare, pero', si richiede di loggarsi in modo "forte" con password e
tutto.
Puoi considerare le funzioni come divise in tre zone e non due: "Guest" e
"User", ma anche una "DMZ" che sta nel mezzo.



Potrebbe anche avere un senso: con NGI ho avuto lo stesso IP per 45gg 
una volta e se si volesse fare un sistema a maglie strette la cosa non 
guasterebbe
tanto per dire Facebook mi dicono costringa al re-login se vede sessioni 
da ip diversi
del resto usabilità=sicurezza^-1
Ad ogni modo si potrebbe mettere lo user agent al posto dell'ip


 servizi che "non richiedono sicurezza"
Vero, ed è davvero fastidioso.

 con un cookie che e' una autenticazione debole.
E' una tecnica intelligente e utile dove serve. Certo è, per fortuna, 
qualcosa di diverso e più serio che mostrare solo un nome e cognome.