Come si codificano le password nei moduli Web senza javascript?

Non è che non abbia accesso a javascript, ovviamente. Nella maggior parte dei miei corsi di CS Web Development, ci viene insegnato un po 'sulla convalida sul lato server, e non appena viene introdotto javascript, la convalida sul lato server viene lanciata fuori dalla finestra.Come si codificano le password nei moduli Web senza javascript?

Scelgo di non fare affidamento su javascript, poiché il lato client non è mai un luogo sicuro. Ho preso l'abitudine di scrivere sia il codice client che lato server per queste cose. Tuttavia, per un'applicazione web che sto scrivendo che ha AJAX opzionale, non voglio che la password venga inviata in chiaro sul cavo se qualcuno ha disattivato JavaScript.

Mi rendo conto che potrei chiedere una situazione di catch-22, quindi lasciatemelo chiedere: come sappiamo che le password dei nostri utenti saranno sicure (abbastanza) dagli utenti malintenzionati sulla stessa rete quando tutto ciò su cui possiamo fare affidamento è lo scripting lato server. In base a questa prima richiesta dalla pagina di accesso, esiste un modo per fare in modo che il browser crittografi un campo dati?

fonte

2010-02-24 sdellysse

+1 per la paranoia ragionevole per i vostri clienti ... =) –

Sì concordato. Non fidarti MAI dei dati dal browser. Un utente può cambiarlo a volontà. Ridefinisci il javascript o disattivalo completamente. O semplicemente pubblica i dati da una pagina sul proprio sito alla tua. I controlli di Javascript sono ESCLUSIVAMENTE per fornire all'utente un'interfaccia utente più fluida, salvando un viaggio sul server per contrassegnare i dati non validi. È comunque necessario ripetere tutti i controlli nuovamente sul server. – Cheekysoft

SSL Risolve questo problema. Per la cronaca, le password non dovrebbero mai essere "crittografate" o "codificate", ciò implica che esiste un metodo di "decodifica" o "decrittografia" che è una chiara violazione se CWE-257. Le password devono essere sottoposte a hash, SHA-256 è un'ottima scelta, ma non è pensata per la trasmissione, ma solo per la memorizzazione. Quando si transitano i segreti c'è una lunga lista di cose che possono andare storte, SSL è di gran lunga la scelta migliore per risolvere questi problemi.

Se l'utente malintenzionato può rilevare il traffico, sarà in grado di vedere l'id della sessione e utilizzarlo immediatamente, quindi è un punto controverso. Devi comunque usare SSL per proteggere la sessione autenticata.

fonte

2010-02-24 02:57:16 rook

Quindi quello che sto ottenendo è questo: se un utente deve essere loggato in un sito, e non vuoi che nessuno origliasse, usa SSL per ogni pagina, comprese quelle dopo il login? Com'è possibile che questo sito sia http: // e non https: //? Cattiva pratica? O mi manca un altro concetto? – sdellysse

Il tuo diritto, nulla impedisce a un utente malintenzionato di sequestrare una sessione di stackoverflow sniffando il traffico. Potresti stare sorseggiando un chi caldo in un bar usando la rete wireless aperta e farti sequestrare la sessione. La maggior parte degli sviluppatori non lo capisce, ma se guardi un qualsiasi portale bancario online come bankofamerica.com, proteggono tutte le sessioni autenticate con ssl. – rook

Le probabilità che qualcuno annusi il tuo login qui sono al massimo, e se usi un OpenID per il login, quel sito è responsabile per l'autenticazione (nel mio caso fatto tramite HTTP Digest, che è hash). Per aggiungere l'improbabilità di qualcuno che annusa la tua sessione StackOverflow, la maggior parte delle persone che hanno quelle capacità non si preoccuperebbero comunque dello stackoverflow o della depurazione del tuo account. –

La soluzione facile è SSL.

fonte

2010-02-24 01:49:16

È inoltre possibile utilizzare Digest HTTP Authentication.

fonte

2010-02-24 03:00:36

HTTP Digest non consente un accesso basato su modulo. –

Ho cercato questo come un matto. Ho fatto una domanda qui, ma penso di aver frainteso la risposta.Quindi potrei semplicemente smettere di cercare e abbandonare una qualsiasi delle mie prove di crittografia e andare per SSL? – Jigzat

Penso che tu stia mescolando un paio di concetti. Il browser non crittografa i singoli campi. Lo scripting lato client, lo scripting lato server e AJAX non sono mezzi per difendersi dalle intercettazioni.

Come altri hanno già detto, SSL è la tecnologia che crittografa i dati. L'intera richiesta e risposta, inclusi i campi e gli script, sono contenuti nella sessione SSL.

fonte

2010-02-24 03:24:31

È vero, stavo mescolando le cose sbagliate. Dopo aver letto queste risposte, ha perfettamente senso che SSL crittografa tutto, altrimenti non sarebbe di grande utilità. Penso che mi mancasse la foresta per gli alberi. – sdellysse

Come si codificano le password nei moduli Web senza javascript?

risposta

Problemi correlati