Is there a best practice around credential storage?

[Sven Hartge]

On 20.12.19 13:41, Alan DeKok wrote:
> On Dec 20, 2019, at 6:43 AM, Sven Hartge <sven at svenhartge.de> wrote:
>> On 19.12.19 23:42, Coy Hile wrote:

>>> Is it really industry standard that people store users' passwords in
>>> cleartext? It seems to be a requirement, but it is something that gives
>>> me pause, as to do so contravenes what are otherwise best practices.
>>
>> We (my employer) uses a different password for everything related to
>> network access, meaning mainliy WiFi and VPN.
> 
>   That works, but it pushes the complexity of password management onto the users.  And users are dumb.
> 
>   i.e. *I* don't want to punish myself by having different passwords for different services.  I can't remember them, it's a PITA to manage, and I have better things to do with my time.
> 
>   Since it's not worth my time, then I believe that other people shouldn't do it, either.
> 
>   For me, I just use client certificates everywhere.  It's supported for EAP, and for all reasonable VPNs.

I'd *love* to use client certificates.

But: being a University, which is basically a 20,000 user BYOD
operation, this is more or less unfeasible and a support nightmare. I
tried this once with a voluntary test group of users and even the more
IT-inclined ones struggled really hard to make this work, no matter how
concise and detailed our instructions where. (The OS vendors changing
the UX for that use-case seemingly every 6 months does not help here.)

I have to support a very wide range of devices and OS versions, so my
lowest common denominator is PEAP-MSCHAPv2, at least for the time being.

So a separate password in a separate LDAP server infrastructure it is
for me, for the foreseeable future.

Grüße,
Sven.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20191220/595878f3/attachment-0001.sig>