Re: [ovirt-users] oVirt 3.5 and FreeIpa
----- Original Message -----
From: "Jorick Astrego" <j.astrego(a)netbulae.eu>
To: users(a)ovirt.org
Sent: Thursday, January 22, 2015 2:30:30 PM
Subject: Re: [ovirt-users] oVirt 3.5 and FreeIpa
>>>>
>>>> Just a couple of addtions, please hash the password with SSHA (I really
>>>> hate
>>>> plain text admin passwords...)
>>>> I tried putting an {SSHA} encoded password in " vars.password
=" , but
>>>> it
>>>> fails to authenticate while plain text works fine.
>>> I am unsure I understand.
>>> using hash to store password hint at server side makes sense.
>>> but using hash to store password at client side does not makes sens, this
>>> means that if I get the server database I can authenticate to any user
>>> without knowing his password.
>>>
>>> Also, please note that the user you specify within configuration should
>>> not
>>> have any special privilege but to query public objects within ldap.
>> I don't like storing plain text in textfiles, so I try to avoid it. Even
>> if it is a read only user there are no "public" objects that I like
to
>> expose to anyone. I can query groups, group members, e-mail addresses,
>> krbPasswordExpiration, krbLastPwdChange etc. with this user.
>>
>> So that's why I try to have the bind user password hashed in the
>> properties file.
> as I wrote above, storing hash instead of password does not enhance
> security.
> it is the same as if you just set the user's password to the hash.
Ah yes, silly me. You are absolutely
right. It has been such a long
habit... But it does help when people intercept the traffic.
No it is not... exactly the opposite... if the hash is sent it is actually weaker than
password, as it has lower diversity.
If you wish you can enable digest-MD5 and use SASL, but still you must store the plain
password at client side.
Does the
ldap plugin send it hashed to the ldap server?
I think FreeIPA supports salted sha512 but I'm not entirely sure.
You'll probably say that I need to enable TLS, but there have been many
weaknesses in ssl and MITM issues. So more is always better in a
security perspective.
Using plain protocol will always be weaker than using TLS, even if you use digest-MD5,
kerberos or any other challenge-response mechanism.
As the password must be kept at client side no mater what protocol you use, using TLS and
simple bind is the minimum you can have.
I believe that TLS + simple bind is sufficient for most usages for a user that has no
special access to information.
From my experience enabling SASL does have its issues, but you may
want to check it out if you do not trust TLS, but even if you use SASL, better to use it
over TLS.
Alon