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
Extension to require 2FA #101
Comments
If someone does get hold of a password, the worst they can do is log-in as sysadmin and add graffiti, make private datasets public or delete stuff. However if this is noticed, with ssh access you can revoke the problem account, and look at the revisions to see what needs fixing up. I'm not convinced 2FA is a priority. |
Oh, i'd say "nice to have, eventually" for this. |
@davidread looking at the revisions and reverting to an earlier version of touched things isn't all that easy right now, is it? |
For a few things its easy to fix them manually by editing normally in the GUI. For a lot of changes, or to remove all evidence of the changes, you're right - a script would take several hours to run up. Personally I'd rather we had a Django module or remote service to sort out registration and log-in. It is tremendously complicated - we've tackled secure password hashing, captcha, password resets and invitations already, and on the horizon is 2FA, session timeouts, blocking multiple bad logins from a single IP address or account and who knows what else. Registration/login a key security feature, for which we really shouldn't be rolling our own. |
Especially for instances where the installation is CKAN + something-else. I guess there's nothing stopping the federated login being implemented as an extension? Personally I'd love to see support for CAS (http://en.wikipedia.org/wiki/Central_Authentication_Service) for when CKAN is just part of a larger suite of tools rather than standalone. |
#100 has made me wonder if it would be useful for CKAN logins to support 2FA (Two Factor Authentication).
In an ideal world this would be customizable for which types of user should be forced to use this (sysadmins, orgadmins, org editors, all registered users).
The text was updated successfully, but these errors were encountered: