-
Notifications
You must be signed in to change notification settings - Fork 462
Remove old password hashing #3360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove old password hashing #3360
Conversation
Remove checks and code related to the old password hashing mechanism in Accumulo. This will discontinue warnings about users passwords that are still out of date. Instead, those outdated passwords will simply become invalid. If the user authenticated to Accumulo at any time prior to upgrading, their password will have been converted. So this only affects accounts that were never used with 2.1 at all. As mitigation, such users will be able to have their password reset by the root user. If the root user never authenticated (and neither had another admin user) while on 2.1 (very very unlikely), an administrator can reset the entire user database through the normal init step to reset security.
This completes the work started in #1798 to improve our password security. |
Would it be worth adding a utility that could check that passwords were correct format - something that an admin could run either before, or post-upgrade that would flag accounts that have issues? That would eliminate surprises, the utility could be targeted for 2.1.x so that it would be there before they might jump to 3.0+ If not desired for 2.1, even having in in 3.0 would allow a post-upgrade check - this would permit an affirmative check instead of just needing to wait for a problem to be reported. The utility could be a separate issue / PR. |
That utility is 2.1 itself. 2.1 has been logging warnings about any accounts in this situation already.
I don't think it's worth adding any such utility. That's why I wrote as much as I did in the commit message. This basically only affects infrequently used accounts, and only if the repeated warnings were ignored while running 2.1, and is no different than a "forgot my password" situation, which I think is a completely acceptable outcome for inactive or infrequently used accounts. It would be very unusual if the problem was reported back to us as a problem. As I stated above, there's plenty of workarounds to mitigate the impact for this. Specifically, the "hey admin, I forgot my password, can you reset it for me?" workaround. We can also call it out in the release notes to add extra emphasis, but the point was to remove code we don't need... not to replace it with more code to be removed later. |
I'm fine with 2.1 is the tool. It seems unlikely to occur, but I guess I was thinking that if a group went from a very old version and upgraded to something modern, then external users "might" see an issue if they needed to run / do something that they do not do regularly. So, rather that the admin need to be reactive, they could be pro-active before the "old-account" became suddenly a "crisis" to the end-user. |
Even if upgrading from a very old version, they still have to upgrade to 2.1 first, at which point they'll see the warnings before they proceed to the next upgrade. But even if there's a worse case scenario, and they don't stop to authenticate any users... they still have a solution to reset the password for the root user, and re-set up additional users and permissions. It may be inconvenient in this extreme case, but it's far from a "crisis". And, this extreme case is very unlikely to happen. At a minimum, the vast vast majority of users are going to at least authenticate the root user once before upgrading. |
Remove checks and code related to the old password hashing mechanism in Accumulo. This will discontinue warnings about users passwords that are still out of date. Instead, those outdated passwords will simply become invalid. If the user authenticated to Accumulo at any time prior to upgrading, their password will have been converted. So this only affects accounts that were never used with 2.1 at all. As mitigation, such users will be able to have their password reset by the root user. If the root user never authenticated (and neither had another admin user) while on 2.1 (very very unlikely), an administrator can reset the entire user database through the normal init step to reset security.