peternied
commented
1 year ago While I agree one time passwords could be very useful for many scenarios around securing OpenSearch, I don't think its viable as a replacement for super user credentials or bootstrap accounts because of how those accounts are used in practice. When a cluster is started up for the first time, there is no external services that OpenSearch is authenticated against. so how do you get the OTP to the user that is going to use it if those external services are misconfigured or unavailable?
I think in the context of manage services where there are more guarantees about the environment and configuration OTP could be valuable. Maybe the existing authentication interfaces could be used for OTP type providers, or maybe we could expand on them to support the scenario.
Maybe if you were to restate the problem in terms of what isn't working for OpenSearch customer scenarios it would be clearer why to prioritize this area, what do you think?
stephen-crawford
This issue is a request for comment on the idea of implementing one-time passwords for OpenSearch Security. One-time passwords (OTP) are a commonly used mechanism for providing additional security to web applications. You read more about them here: https://en.wikipedia.org/wiki/One-time_password.
As part of the researching alternatives to the default credentials
admin:admin, I looked into what it would take for OpenSearch to implement its own OTP mechanism. This mechanism would be offered by the Security Plugin as an additional feature for users with the added benefits of:The most notable benefit of OTP support is the last listed. By supporting hash-based one-time passwords (HOTP), we can guarantee that only a single user is able to login as the admin. HOTP act similar to time-base OTP but instead of using an expiration window, use a incrementing counter which denotes the specific token generated for login at any time. That is, HOTP has a counter where every time a new OTP is generated, the counter increases and the only OTP which is valid is the one whose encoding not only matches the OTP expected but has the correct counter value. Using HOTP, we can then confirm that the OTP provided is only the most recent one generated, and also invalidate its use by incrementing a second counter.
For a simplified example, imagine we have two counters inside the security plugin where it is creating the HOTP:
Now when the admin requests an OTP, we go through the process of generating the OTP with the secret and the current value of the tokens_issued counter. After creating the token, we increment the counter:
Then when the admin gets the token and attempts to use it to login, we validate the token both based on the secret, but also on the issued counter associated with its encoding. If the token_issued counter is not 1 greater than the token_logins, we reject the request. After a successful login we increment the login counter:
This process can be repeated.
Looking at this setup, we can see how HOTP provides a guarantee that a OTP can only be used to login a single time with the cluster. That means that unlike a time-base OTP, we do not need to worry about a token being used by multiple parties to access the admin account. Instead, we have a guarantee that a HOTP is only usable a single time, and assuming that the admin is the person receiving the OTP, that the user logging in is in fact the admin user.
This in turn allows us to treat the admin user as a special user even without using the admin certificate. Normally, we need to make use of the admin certificate, because we have no way of determining whether a user logging into the cluster with the admin account is actually the administrator. The admin account not only has a widely known default credential but lacks any measures which would provide authenticity to a login. We don't really know whether a user logging in with admin account is the true cluster administrator whom should be granted the control offered by the admin certificate. Instead, we have to rely on the admin certificate to act as a verification method that signals to the cluster that the admin user is truly the admin of the cluster.
With this implementation of HOTP we circumvent this issue. Assuming that the cluster operator is the intended "true admin," we know that the person who set up the HOTP will be the intended admin. The details of setting up the HOTP system can be specified later but will generally require providing something like the users email or connection to a MFA provider such as DUO. Regardless, because they launch the cluster with this configuration, we can then be certain that--ignoring cases where their email or MFA app is compromised--we always have a way to reach them, and them alone.
Then using the HOTP we pass them, they are able to access the cluster act as the admin. Because, the HOTP is only good for a single login, we also do not need to worry about attempts to use the password a second time and impersonate the admin. Instead, an attempt at impersonating the admin would require the fraudulent admin to get access to the HOTP and make use of it to login before the true administrator. This responsibility should be left to the administrator since we have no way of enforcing proper use practices.
Ultimately, we a HOTP system, we can be sure that the admin user is really the cluster operator/the person we would expect to have the admin certificate. This would let us provide a setting where actions normally requiring the admin certificate can be permitted on the basis of HOTP use with the admin account. This is particularly valuable for cases where users want to complete operations requiring the admin cert but either operate behind an SSL terminator or do not wish to have SSL enabled.
A diagram of the synchronicity of the nodes in a cluster can be found here: https://github.com/OpenSearch-Security/OpenSearch-Security/issues/3#issuecomment-1695904740.