TLS abbastanza sicuro? Hai bisogno di rotolamento hash in una domanda di pagamento PA-DSS?

Question

Sono un ingegnere del software e sto attualmente lavorando su un'altra applicazione di pagamento (il mio 3 ° uno) che deve andare sotto la conformità PCI standard PA-DSS. Sto ri-esame della documentazione PA-DSS e mi chiedo se in passato ho oberati di lavoro sulla sicurezza dell'applicazione, quando avrei potuto passa con TLS e user / pass. Quindi, le mie domande sono, in sede di attuazione di un PA-DSS applicazione sicura:

1. per l'autenticazione e la comunicazione di sicurezza è sufficiente avere TLS + user / pass?

2. Quale parte (s) dei giustifica standard di PA-DSS la necessità di attuare un messaggio di hashing e rotolando hash tra metodi Web le chiamate? TLS implementa messaggi affidabili, ma non hash colline e chiamanti persistenti tra i messaggi. Sarà l'attuazione di un hash rotolamento fa alcuna differenza (dal punto di stand PA-DSS)?

3. Se un negozi di applicazioni di elaborazione dei pagamenti informazioni PII e serve diverse aziende (il che significa che la società A e la società B possono avere conti in tale applicazione), non v'è alcun requisito specifico che indica le informazioni PII non può essere memorizzato nella stessa DB, ma in passato, PA-QSA ha insistito in questo essere un problema. La domanda è: È questo veramente necessario? Non riesco a pensare Authorize.NET, una società con migliaia di clienti e processori hanno diversi database per memorizzare le carte di credito elaborati tramite ciascuna delle sue aziende clienti.

Grazie in anticipo!

---

Aggiornamento # 1:

• Si assuma tutte le pagine web e servizi, sia in DMZ e Secure Zone avrà HTTPS per tutti i canali di comunicazione, pagine e servizi.

• Il 3 #, la questione non è circa la posizione o la sicurezza dello stoccaggio di informazioni sensibili. La domanda è più orientata a mettere in discussione la capacità di condividere le informazioni sensibili da diverse fonti (client, come AT & T e Verizon per esempio) nello stesso database.

Answer 1

Ci sono alcuni problemi qui.

1) Uso di TLS per solo l'username password + è ancora una vulnerabilità. La sua violazione di un OWASP a9 e la sua banale per dirottare qualsiasi account sul tuo sistema che utilizza un attacco stile firehseep.

So che il PA-DSS 2.0 non fa incarnano tutta la parte superiore OWASP 10, ma requisito 12.1 va notato:

12.1 i clienti Istruire per crittografare tutti i non-console con accesso amministrativo crittografia forte, utilizzando tecnologie quali SSH, VPN, o SSL / TLS per la gestione basata su Web e altri non-console di amministrazione l'accesso.

che includa un'interfaccia http amministrativa.

2) Il PA-DSS recommendeds utilizzando sicurezza reale livello di trasporto come ad esempio: VPN, e TLS / SSL. Non credo ci sia un requisito per hash rotolamento, e ad essere onesti non si tratta di un progetto molto sicuro. Tale traffico ha bisogno di una protezione completa del livello di trasporto.

3) Non dimenticare requisito 9:

9. dati del titolare non devono mai essere memorizzati su un server connesso a Internet