Is there a best practice around credential storage?
Coy Hile
coy.hile at coyhile.com
Fri Dec 20 13:54:49 CET 2019
> On Dec 20, 2019, at 7:37 AM, Alan DeKok <aland at deployingradius.com> wrote:
>
> On Dec 19, 2019, at 5:42 PM, Coy Hile <coy.hile at coyhile.com> wrote:
>>
>> Seeing the comments that come up often about how to make various authentication methods work with password scheme X (for various values of authentication method and scheme) as well as the matrix here: http://deployingradius.com/documents/protocols/compatibility.html I'm left with a question.
>>
>> 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.
>
> "Best practices" are doing what works, and staying in business.
>
> Where you have a choice about authentication methods, storing crypt'd passwords is best. Where you don't have a choice about authentication methods, it's best to do whatever you can to keep your business running.
>
> The issue for me is less password storage methods than naive users who believe checklists, or who want things to work in magical ways. This usually ends up in the following conversations:
>
> Q: How do I configure my systems securely? My security people say I have to store crypt'd passwords for security, AND that the users must configure PEAP/MS-CHAPv2, so that passwords aren't sent in clear-text over the wire.
>
> A: Your "security" people are stupid, and don't understand security. Passwords are *never* sent in clear-text over the wire. You *cannot* do MS-CHAPv2 with crypt'd passwords.
>
> Or this:
>
> Q: I want to be secure, but using crypt'd passwords AND PEAP-MSCHAPv2. I know the documentation says it's impossible, but I really REALLY want to do it. How do I do it?
> A: You can't. It's impossible.
> Q: But I really really really really honestly really REALLY want to do it. Is there any way?
> A: It's impossible. Stop asking.
> Q: Why are you people so mean?
>
> <sigh>
>
> If what you want is in conflict with reality, then learn to live with reality. Only a child asks for a candy bar, and then throws a tantrum when told they can't have one.
>
>
> Most people see "best practice" lists that are intended for use with web applications, and then try to apply them to RADIUS. They do this with limited understanding of the protocols involved. Instead, they're blindly applying a checklist, without thinking about it. That process of "not thinking" is deeply flawed from a security standpoint.
>
> TBH, my recommendations are this:
>
> * use EAP-TLS with client certificates everywhere you can. This avoids the whole password issue
>
> * otherwise, store crypt'd passwords in the DB. The risk of a DB compromise is non-zero. And if the passwords are crypt'd, the risk is less.
>
> Crypt'd passwords means that the clients MUST use TTLS + PAP. Yes, there are "clear text" passwords hidden inside of TLS. It's fine. It's no worse than web applications sending clear-text passwords over an HTTPS connection.
>
> * a last resort is PEAP / MS-CHAPv2. This means that passwords MUST be stored in clear-text in the DB. (Or NT-hash, which in 2019 is effectively clear-text).
>
> These recommendations are simple to explain, and simple to understand. When people give bad advice about these topics, all it shows is incompetence on their part.
>
> Alan DeKok.
Thank you for the in-depth answer, Alan. I should note that my use case is not remote users as in a VPN or Wifi scenario, but rather authentication and authorization of users’ access to network equipment itself. So, I think I’m pretty much stuck with PAP as an authentication method. However, another goal is to build a system that can be extended later for other end-user use cases if they arise.
So, in this case, I think Crypt passwords it is.
--
Coy Hile
coy.hile at coyhile.com
More information about the Freeradius-Users
mailing list