PCI - Disable Plain text authentication
Hi Everyone,
Getting this issue with PCI for: Remote Mail Service Accepting Unencrypted Credentials Detected (IMAP) basically:
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE STARTTLS LOGINDISABLED] Dovecot ready.
vidence: ~$ telnet xxx.xxx.xx.xxx. 143 Trying xxx.xxx.xx.xxx... Connected to xxx.xxx.xx.xxx.. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE NAMESPACE LITERAL+ STARTTLS LOGINDISABLED] Dovecot ready. A LOGIN USER PASS * BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. A NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
We have require clients to connect via tls switched on in exim confirguration and also explained to pci vendor that we dont send cc details at all via email and its only for standard communication.
They are adamant that this nees to be fixed and so far nothing i have read:
-
Go to WHM, Mailserver Configuration and change "Allow Plaintext Authentication (from remote clients)" from Yes to No. You might, however, make your other clients unhappy. 0 -
Go to WHM, Mailserver Configuration and change "Allow Plaintext Authentication (from remote clients)" from Yes to No. You might, however, make your other clients unhappy.
thats already set to 'no' but PCI still complaining... specifically on port 1430 -
OK, then simply block port 143, as POP/SSL will be on 993. Again, this may make all the rest of your customers upset. 0 -
Have you talked to a human that is running this PCI scan? The evidence provided shows that your server doesn't accept plain text logins - an upgrade to a TLS connection is required before [font="courier new">LOGIN can be understood by the server. Now... that doesn't stop a stupid client from connecting to your IMAP service and trying to log in, exposing their password in plain text. If the connecting client is worth anything it would realize that the capabilities listed by your IMAP service does not list plaintext login. If a client still wants to send the password information in plaintext, then that's on the client. Not the server's fault. 0 -
OK, then simply block port 143, as POP/SSL will be on 993. Again, this may make all the rest of your customers upset.
Thank for the info. Yup thats the last resort which I hope it wont come to as I hope one of the @cpanel team can shed some light or insight...Have you talked to a human that is running this PCI scan? The evidence provided shows that your server doesn't accept plain text logins - an upgrade to a TLS connection is required before LOGIN can be understood by the server. Now... that doesn't stop a stupid client from connecting to your IMAP service and trying to log in, exposing their password in plain text. If the connecting client is worth anything it would realize that the capabilities listed by your IMAP service does not list plaintext login. If a client still wants to send the password information in plaintext, then that's on the client. Not the server's fault.
100% agree with you. Thing is no human to talk to which is ridiculous. A few failures many which have been accepted as false positive but a couple which seem to be responded by same person which failed and and very hard 'we dont accept' that answers. Like you say its not the servers fault if you want to send your passwords!0 -
@cPRex can you shed any light or a fix? 0 -
Not really - if the scan is automated, it's best to speak with someone at the scanning company about the false-positives. 0
Please sign in to leave a comment.
Comments
7 comments