Ciao! Domanda sempre molto terra terra: ma secondo voi, poste le seg. condizioni: - applicazione semplicissima rest - 1 solo utente, e per sempre - Nome utente e pw del cliente li decido io a monte - possibilmente no plugin Qual'è il modo + veloce e sicuro per gestire il login/out? Dove li salvo nome utente e password? Che tipo di misure di sicurezza prendo? :)
on 2010-01-11 11:46
on 2010-01-11 11:57
Se c'è un utente o 10 o 100.000+ la gestione della sicurezza è sempre la stessa. Simone Federici ----------------------------------- Architect 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-11 12:16
2010/1/11 Luca Reghellin <email@reghellin.com>
>
Se sei sicuro che l'utente sia uno, o qualcosa del genere, potresti fare
a
meno del tutto di preoccupartene dentro rails, e usare invece
l'autenticazione http del web server... ti semplifichi la vita!
Ciao
on 2010-01-11 12:17
On 11/01/2010 11:46, Luca Reghellin wrote: > > :) > per user e password, se proprio sei certo che si tratta di un solo utente e non vuoi *scomodare* una tabella sul database, puoi sempre usare un file, magari al suo interno la password la codifichi a monte con MD5, un po' come /etc/shadow sui *nix ;-) per tutto il resto, la prassi è quella di un db. non la considererei una *best practice*, ma se è quello che vuoi ottenere, una strada potrebbe essere questa :) ciao, A.
on 2010-01-11 12:28
se vuoi puoi anche fare la stessa cosa direttamente da rails usando authenticate_or_request_with_http_basic 2010/1/11 Andrea Pavoni <apeacox@gmail.com>:
on 2010-01-11 12:41
con la basic authentication non c'è possibilita di logout, ossia se non chiudi il browser rimane loggato, a parte questo piccolo problema è una scelta ottima Simone Federici ----------------------------------- Architect 2010/1/11 Luca De Marinis <loop@interact.it>
on 2010-01-11 13:33
Ah dai questa cosa non la sapevo. Ma con la basic authentication, la sicurezza della password come viene getita? Cioé, è sicura la cosa? Scusate le domande sceme, ma il fatto è che pur essendo un buon (credo) programmatore javascript/actionscript, al server-side mi sto avvicinando ora. Simone Federici wrote: > con la basic authentication > non c'� possibilita di logout, ossia se non chiudi il browser rimane > loggato, > a parte questo piccolo problema � una scelta ottima > > Simone Federici > ----------------------------------- > Architect > > > > 2010/1/11 Luca De Marinis <loop@interact.it>
on 2010-01-11 14:18
la basic authentication è gestita dal browser l'autenticazione passa codificata nell'header della request la codifica è base64, e ovviamente esiste una decodifica... non stiamo parlando di criptatura quindi non menzionerei la sicurezza quando si parla di basicautentication. non è sicura, o meglio se il tuo cliente passa da un proxy o c'è un attacco man in the middle, chi è in mezzo ha la possibilità di loggarsi con il tuo account senza nessuna fatica. se invece c'è SSL, reperire la password che passa codificata è molto più difficile. rimane però il problema del logout Simone Federici ----------------------------------- Architect 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-11 14:49
Firefox ha un'estensione chiamata web developer toolbar. Installa per l'appunto una toolbar con un menu Miscellaneous, Clear Private Data..., HTTP Authentication che cancella le credenziali di autenticazione HTTP senza dover chiudere il browser. Comodo per chi sviluppa. A parte questo, trattandosi di un'applicazione per un solo utente le fasi di login e di logout possono essere facilmente controllate per cui anche chiudere il browser potrebbe essere accettabile. L'unico vero problema è l'invio in chiaro della password, cosa che fanno anche i soliti form di autenticazione web a meno che i dati non viaggino su https. Di nuovo, trattandosi di un'applicazione mono utente potresti generarti il tuo certificato per l'HTTPS e installarlo sul server e sul client. In questo modo fai SSL senza pagare Verisign & Co. Paolo Simone Federici wrote: > la basic authentication è gestita dal browser l'autenticazione passa > codificata nell'header della request > la codifica è base64, e ovviamente esiste una decodifica... non stiamo > parlando di criptatura quindi > non menzionerei la sicurezza quando si parla di basicautentication. > > non è sicura, o meglio se il tuo cliente passa da un proxy o c'è un > attacco > man in the middle, chi è in mezzo ha la possibilità di loggarsi con il > tuo > account senza nessuna fatica. > > se invece c'è SSL, reperire la password che passa codificata è molto più > difficile. > rimane però il problema del logout > > > Simone Federici > ----------------------------------- > Architect > > > > 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-11 14:52
:) Grazie dell'ampia spiegazione! Ma tipo, lasciando stare per un momento la transazione e la basicauth: user e pass, non posso salvarli come costanti nel controller dell'admin (sempre per via del fatto che l'utente lo decido io ed è unico)? Li intanto sono al sicuro giusto? Poi ovviamente devo assicurarmi che non vengano pescate dalla request. Luca Simone Federici wrote: > la basic authentication è gestita dal browser l'autenticazione passa > codificata nell'header della request > la codifica è base64, e ovviamente esiste una decodifica... non stiamo > parlando di criptatura quindi > non menzionerei la sicurezza quando si parla di basicautentication. > > non è sicura, o meglio se il tuo cliente passa da un proxy o c'è un > attacco > man in the middle, chi è in mezzo ha la possibilità di loggarsi con il > tuo > account senza nessuna fatica. > > se invece c'è SSL, reperire la password che passa codificata è molto più > difficile. > rimane però il problema del logout > > > Simone Federici > ----------------------------------- > Architect > > > > 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-11 15:12
puoi fare quello che credi metterle in un file, metterle Hard Coded dentro il Controller, quello che vuoi. io però le metterei alla classica maniera sul DB. ciao S Simone Federici ----------------------------------- Architect 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-14 13:53
Un'ultima domanda veramente da asini, così ti rendi conto di come son messo sul piano server-side... :) : in linea teorica, il codice dei controller, dei models e in generale i file .rb non sono accessibili a possibili attacchi giusto? Cioé, nessuno è in grado di vedere materialmente le parti in ruby, o sbaglio? In generale, quali sono le aree di norma 'nativamente' quasi o completamente immuni da potenziali attacchi diciamo 'convenzionali'? Simone Federici wrote: > puoi fare quello che credi > metterle in un file, metterle Hard Coded dentro il Controller, > quello che vuoi. > > io per� le metterei alla classica maniera sul DB. > > ciao > S > > Simone Federici > ----------------------------------- > Architect > > > > 2010/1/11 Luca Reghellin <email@reghellin.com>
on 2010-01-14 13:55
Leggi questa :-D http://guides.rubyonrails.org/security.html 2010/1/14 Luca Reghellin <email@reghellin.com>
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.