Il login su ogni pagina richiede SSL su tutte le pagine

Tecnicamente, solo la destinazione del modulo deve essere una pagina protetta da SSL per la trasmissione da crittografare. Ho visto questo fatto in un precedente lavoro in cui avevamo un modulo di accesso nell'intestazione.

TUTTAVIA

In questo modo stai perdendo la chiarezza che stavamo dicendo agli utenti di cercare. Agli utenti viene richiesto di guardare nella barra degli indirizzi per verificare se il sito Web utilizza una connessione crittografata per le proprie informazioni. Se la pagina non viene consegnata tramite SSL, gli utenti potrebbero erroneamente ritenere che il loro modulo (nome utente e password) non sia crittografato.

Inoltre, come sottolineato da Craig in seguito, se la pagina che invii da non è crittografata, non puoi affermare che la pagina non sia stata intercettata e alterata. Quella forma familiare che conosci è sempre stata inviata a un URL HTTPS potrebbe essere stata intercettata e alterata prima del rendering.

La soluzione migliore è semplicemente offrire SSL su tutte le pagine se si desidera avere il modulo di accesso nell'intestazione. SSL è relativamente economico da implementare per quanto riguarda le risorse del server e offre agli utenti la sicurezza extra che meritano.

Per essere sicuro, il modulo deve essere ospitato su una pagina consegnata via SSL. Senza SSL, l'utente finale non ha modo di sapere che i dati del modulo saranno consegnati dove si aspettano che vengano consegnati - l'azione del modulo potrebbe essere stata manomessa da un utente malintenzionato durante il download della pagina, oppure potrebbero stai guardando una versione falsa del tuo sito prodotta da un server a cui sono stati reindirizzati tramite un attacco di dirottamento DNS o simili.

Detto questo, anche se non sono un esperto di conformità PCI, ho avuto l'impressione che le norme PCI si applichino solo alla trasmissione dei dati dei titolari di carta e che pertanto devono essere protetti solo i moduli relativi ai pagamenti. A meno che non si mantengano i dettagli di pagamento degli utenti in modo permanente e si consenta loro di generare transazioni aggiuntive senza confermare che detengono la carta, i moduli di accesso non dovrebbero essere richiesti per essere conformi PCI.

Sezione 6.3 (a) del Questionario di autovalutazione D ( link ) dice

6.3 (a) I processi di sviluppo software sono basati sull'industria standard e / o best practice?

Direi che la crittografia delle informazioni di accesso è basata sulle migliori pratiche, e non farlo definitivamente non lo è. BTW ricorda che non puoi forzare un utente a inviare dati usando SSL - è impossibile. Chiunque può inviare tutto ciò che desidera, tocca a te come trattarlo.

(A proposito di un solo getcha comune che non protegge in modo corretto da XSS, se si utilizza ASP.NET MVC, verificare la chiamata alla funzione @ Html.AntiForgeryToken () e ovviamente non consentire l'iniezione SQL (o comando di iniezione) ma lo sapevi già:)

Inoltre, la sezione 8.4 dice:

"8.4 (a) Tutte le password sono rese illeggibili durante la trasmissione e la memorizzazione su tutti i componenti del sistema usando la crittografia avanzata?

Si noti che la sezione 8 in realtà parla dell'assegnazione di ID univoci a ogni persona con accesso al computer, ma si potrebbe sostenere che è quasi indicativo di dover crittografare in modo sicuro le password quando si accede al proprio sito Web.

Quindi, a seconda del tuo livello di valutazione (potresti essere A, B, C o D) dovrai crittografare le informazioni di accesso per la conformità PCI.

Oh, e solo perché un'altra società che afferma di essere conforme allo standard PCI fa qualcosa di strano, non significa che tu possa farlo anche tu - sicuramente non è una buona guida da seguire. Forse hanno una dispensa speciale o hanno un'altra misura di compensazione. (IMHO, stai attento a chi ti dice cosa è conforme e cosa no, devi procurarti un QSA - Qualified Security Assessor che può darti una risposta).