LDAP authentication method sends user password in plaintext fromat
I previously had used HASH authentication methods for local users. And I have tested, it does not send password in plaintext format during authentication. So all good.
But now I need to configure LDAP authentication method also. I have done so. So LDAP authentication indeed works.
But now I was just making sure, that passwords were not sent in plaintext format.
For that I did start packet capturing on ethernet interface:
tshark -i eth0 host 10.51.2.66 and port 5433 -w /tmp/outfile.log -c 12
In another session from another host, I tried authentication:
[[email protected] ~]$ vsql -h 10.51.2.66 -U ldap_user -w 'wrongSecretPass'
vsql: FATAL 3846: LDAP authentication failed for user "ldap_user"
I deliberately used wrong password, but regarding testing, it does not matter is it correct pass or not. The problem is that I was able to read this password in plaintext format by capturing network packets.
After I got this error, the packets were captured from the first session:
Capturing on 'eth0'
For the next step, I read this outfile with tcpdump command:
tcpdump -qns 0 -A -r /tmp/outfile.log | grep "wrongSecretPass"
reading from file /tmp/outfile.log, link-type EN10MB (Ethernet)
What must be done to make sure, that passwords are not sent in plaintext format..?
Have you tried LDAP over TLS? This shd help: https://www.vertica.com/docs/10.1.x/HTML/Content/Authoring/Security/ClientAuth/UsingLDAPOverSSLAndTLS.htm?zoom_highlight=ldap
I forgot to mention. But I am using ldaps already, these are the two LDAP authentication methods:
So these are parameters for both (this should mean I am already using LDAP over TLS):
With both (LDAP1 and LDAP2) authentication methods, I can clearly capture password in plaintext format.
Did you enable TLS on your Vertica cluster?
Hmm, not yet, I guess.
I only did change this to "vertica" and restarted database.
But what this LDAP over TLS do differently to LDAP without TLS, if not encrypt passwords..?
In addition to that, hash authentication works fine (regarding password hash-ing) without TLS on vertica cluster.
Let me try to explain the differences between the two types of authentication.
With HASH authentication , the Vertica client (in this case vsql) does the authentication and knows how to hash the clear text password before sending it to Vertica. In addition, if you enabled TLS on Vertica cluster, the whole communication with Vertica could be encrypted.
With LDAP(S) authentication, the Vertica client doesn't do the authentication per se -the Server does- and the client doesn't know anything about hashing requirements for LDAP(S). If you enabled TLS on the Vertica cluster, the whole communication with Vertica could be encrypted; and that's probably the best way to address your security concerns.
some more info:
the password shd be sent un-transformed on to LDAP.
Authentication using LDAP - Linux Documentation Project
6.2. Authentication using LDAP. To access the LDAP service, the LDAP client first must authenticate itself to the service. That is, it must tell the LDAP server who is going to be accessing the data so that the server can decide what the client is allowed to see and do.
Ok, I did set SSLCertificate and SSLPrivateKey parameters:
And also I set:
Now it looks like this:
And when I authenticate with LDAPS, then I don't see plaintext password when I capture network packets. So this is solved.
But few more question arises.
This client.crt is probably going to expire at some time in future. How do I monitor these expiry date-s..? Is there some system views where these dates are shown etc..?
@raulk89 In vertica, there is a system table which stores the expiry date of the certificates. Please use the query
select * from certificates;
I have configured TLS in my cluster
But this certificates view is empty:
Oh, ok, I need to CREATE these certs to vertica before.
In production I understood, it is preferred that I use our corporate CA in contrast to generating self signed CA, as it is stated here:
So I did:
This last command gives me error:
Any hint, why is that happening..?
This sounds like a limitation of the corporate CA which is not set to allow signing certificates. Maybe your IT/Security team can create a certificate for you to import in Vertica?
What CA parameter you are referring for that ..?
Seems to me Certificate signing is enabled or not..?
Your IT/Security Team can probably troubleshoot this further but the Basic Constraints settings also control wether a CA can be used for signing cetificates.
It should be fine for signing.
How is vertica going to execute this request, does it uses some OS utility (openssl perhaps) for that or not..?
If so, is there an option to log this OS command, so I can see what is actually executed with this command
If you want to troubleshoot further, can you open a support ticket?