Is there a best practice around credential storage?
Hi all, 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. -- Coy Hile coy.hile@coyhile.com
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 mainling WiFi and VPN. This password has do be different than the main account password, can only be (re)set using the main account password and is stored in a different attribute in LDAP, which freeradius then reads and puts into the Cleartext-Password attribute. Grüße, Sven.
On Dec 20, 2019, at 6:43 AM, Sven Hartge <sven@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 mainling WiFi and VPN.
This password has do be different than the main account password, can only be (re)set using the main account password and is stored in a different attribute in LDAP, which freeradius then reads and puts into the Cleartext-Password attribute.
Requiring a separate password for such things is already something I expected and will require. Are there concerns that whomever manages the directory can read that plaintext attribute (whether it be in the directory or a database? Or, honestly, that any actors who gain access to the RADIUS server can thus read the same? I’m trying to anticipate questions I’d certainly be asked by reviewers who balk at that. Being able to point and say “It’s widely considered best practice.” could help. -- Coy Hile coy.hile@coyhile.com
On Dec 20, 2019, at 7:06 AM, Coy Hile <coy.hile@coyhile.com> wrote:
Requiring a separate password for such things is already something I expected and will require. Are there concerns that whomever manages the directory can read that plaintext attribute (whether it be in the directory or a database?
Yes.
Or, honestly, that any actors who gain access to the RADIUS server can thus read the same?
Yes.
I’m trying to anticipate questions I’d certainly be asked by reviewers who balk at that. Being able to point and say “It’s widely considered best practice.” could help.
Usually it's not about best practices. It's about what's *possible*. It's best to say "your requirements are impossible to implement". If you can't say that, say "we're following best practices". Use client certs if you can. e.g. enterprise. Otherwise TTLS + PAP. Unless you can't re-configure the clients, and then use PEAP/MS-CHAPv2, but only because you have no control over the clients. Using multiple passwords doesn't really help. If the DB is compromised, then *all* passwords are compromised. Alan DeKok.
On 20.12.19 13:53, Alan DeKok wrote:
Using multiple passwords doesn't really help. If the DB is compromised, then *all* passwords are compromised.
Unless you store the password for freeradius in a different database/LDAP server/$whatever from the main password. This is what I do. The LDAP servers for the network password are separate from the main authentication servers and the RADIUS servers can only interact with their special LDAP servers. Should the RADIUS servers somehow get compromised, the attacked can only read the lower-value network password from there and not everything else. Grüße, Sven.
On Dec 20, 2019, at 8:39 AM, Sven Hartge <sven@svenhartge.de> wrote:
On 20.12.19 13:53, Alan DeKok wrote:
Using multiple passwords doesn't really help. If the DB is compromised, then *all* passwords are compromised.
Unless you store the password for freeradius in a different database/LDAP server/$whatever from the main password.
This is what I do. The LDAP servers for the network password are separate from the main authentication servers and the RADIUS servers can only interact with their special LDAP servers.
Should the RADIUS servers somehow get compromised, the attacked can only read the lower-value network password from there and not everything else.
That works. I'm just too lazy to do that. :) Alan DeKok.
On Dec 20, 2019, at 6:43 AM, Sven Hartge <sven@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 mainling 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. Alan DeKok.
On 20.12.19 13:41, Alan DeKok wrote:
On Dec 20, 2019, at 6:43 AM, Sven Hartge <sven@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.
On Dec 19, 2019, at 5:42 PM, Coy Hile <coy.hile@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.
On Dec 20, 2019, at 7:37 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 19, 2019, at 5:42 PM, Coy Hile <coy.hile@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@coyhile.com
participants (3)
-
Alan DeKok -
Coy Hile -
Sven Hartge