Howdy,
I'm not a customer so feel free to de-prioritize this issue. I also am not as deeply familiar with identity management and cybersecurity as I'd like to be, so I apologize if any of my remarks come from a place of ignorance.
Recently, one of our users logged in using an email address rather than a username. The fact that the login succeeded was rather unexpected, and led us to find #7136 and https://issues.redhat.com/browse/RHEL-1654. We disabled email logins by setting ldap_user_email to a nonexistent attribute as directed to avoid further confusion. However, this default behavior still strikes me as a bit weird, and I'm not sure I fully understand the rationale for why it has been implemented. 7867749 seems to indicate that this was done because emails can be used as a unique identifier, but I don't really understand the merit of doing so other than that they resemble Kerberos UPNs. I recognize that there may be more context that can't be made publicly available, but if there are any hints about this architectural decision I'd be curious to understand it in further detail.
Off the top of my head, there are a few arguments for why using emails for logins might not be a good idea:
- Many organizations make email addresses public on their website. If email addresses are valid login names, an enumeration attack might become easier since email addresses are widely shared (whereas there isn't really a huge behavioral incentive to publicly share an internal username, which might potentially differ from the local-part/username portion of an email address).
- Often an email account will be integrated with AD/LDAP and use the same credentials for login as a POSIX account. Phishing attacks specifically target users via email, and if a phisher is able to gain access to an email account, they would also have credentials for a POSIX account / credentials that could be used to SSH into a host.
- In general, a many-to-one mapping of usernames to accounts might make it so that there's a greater set of usernames that could be used by a bad actor. A bad actor would only need to know one username/password combination, and in theory having many more usernames with the same password would give the bad actor more opportunities to log in (i.e., it would increase attack surface).
I'm not entirely sure how much merit these arguments have, but they popped into my head during my lunch break and I figured I'd float them here. If they do resonate with you, however, here's what I might suggest:
- Implementing a configuration option that allows you to select which attribute(s) can be used as identifiers, as suggested in the original commit from 2016.
- Making it so that by default the attribute(s) used as an identifier are conventional / in line with most people's expectations (i.e., UPNs and/or normal usernames/cns). To address the many-to-one issue you might make it so that a single attribute is used by default.
Thanks for taking the time to read this. Overall, I'm not sure if this is an insanely pressing issue, but the default behavior certainly did elicit a, "Huh?" from me.
--John
Howdy,
I'm not a customer so feel free to de-prioritize this issue. I also am not as deeply familiar with identity management and cybersecurity as I'd like to be, so I apologize if any of my remarks come from a place of ignorance.
Recently, one of our users logged in using an email address rather than a username. The fact that the login succeeded was rather unexpected, and led us to find #7136 and https://issues.redhat.com/browse/RHEL-1654. We disabled email logins by setting
ldap_user_emailto a nonexistent attribute as directed to avoid further confusion. However, this default behavior still strikes me as a bit weird, and I'm not sure I fully understand the rationale for why it has been implemented. 7867749 seems to indicate that this was done because emails can be used as a unique identifier, but I don't really understand the merit of doing so other than that they resemble Kerberos UPNs. I recognize that there may be more context that can't be made publicly available, but if there are any hints about this architectural decision I'd be curious to understand it in further detail.Off the top of my head, there are a few arguments for why using emails for logins might not be a good idea:
I'm not entirely sure how much merit these arguments have, but they popped into my head during my lunch break and I figured I'd float them here. If they do resonate with you, however, here's what I might suggest:
Thanks for taking the time to read this. Overall, I'm not sure if this is an insanely pressing issue, but the default behavior certainly did elicit a, "Huh?" from me.
--John