we already have logic in Canvas::Security to
protect us against brute force, and AuthLogic
is just checking the updated_at to see if they can
attempt to login again if failed_login attempts is
over 50
fixes CNVS-22681
test plan
- update a pseudonyms failed_login_count to > 50
- p = Pseudonym.last
- p.failed_login_count = 54
- p.save!
- attempt to login
- it should work
Change-Id: I72ebf54306c4fe6bd46d172d31b8f732555107a7
Reviewed-on: https://gerrit.instructure.com/61595
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
authlogic expects a timestamp in the place where we use
a uuid for SessionPersistenceToken
test plan:
* boot up server in Rails 3 mode
* try to login with "Remember Me" checked
Change-Id: Ic184e80be65b5d5a9be3edd16538949e36569c92
Reviewed-on: https://gerrit.instructure.com/27733
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
* disable i18nema until we're on rails 3.2
* fix how we access session_options
* fix how we access the basic auth header
* fix attachment_fu callbacks
test plan: none of these fixes should affect rails 2
Change-Id: I7f9b6f18c04d51284ec3e5e9fdd39fb93539c91b
Reviewed-on: https://gerrit.instructure.com/21728
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
fixes#7676
test plan:
* get a site admin password wrong 11 times in a row from the same
computer
* it should error with "too many login attempts" for the next 5
minutes
Change-Id: I7e63e3ecf76f1a7a638d8a43110e787ed08af795
Reviewed-on: https://gerrit.instructure.com/11828
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
closes#6382
Previously, the "stay logged in" cookie just used the authlogic default
implementation, which is the pseudonym persistence_token. This is a
problem, because that persistence_token only ever changes when the
pseudonym password changes, so it's the same everywhere; so if that
cookie is stolen, it's valid for a very long time.
This switches us to one-time-use tokens that expire as soon as the token
logs the user in once. Each user agent also gets a different
one-time-use token.
Change-Id: I4f20cd7759fd74590e82ed55797552e342243d49
testplan:
* Check that no token is set at all when "stay logged in" isn't
selected.
* Check "stay logged in", and verify:
* That you don't have to login again after restarting your browser,
but your _normandy_session got reset.
* That if you save and try to replay using the same
pseudonym_credentials, they don't work the second time.
* That a second browser will get a different pseudonym_credentials
value, and using one token doesn't affect the other.
* That once the token is used, a new one is generated and set in
your cookies. Verify this new token works as well.
* That logging out removes the pseudonym_credentials cookie in your
browser. And also that manually restoring this cookie still
doesn't log you in, since it was removed server-side as well.
* Change your password, and verify that the existing "stay logged in"
tokens no longer work.
* Delete your pseudonym, and verify the same.
Reviewed-on: https://gerrit.instructure.com/7093
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
refs #6382
testplan:
* Login without selecting "stay logged in", and verify that no
pseudonym_credentials cookie is set, not even a session cookie.
* Verify the same when logging in via SSO.
Change-Id: I3bbb4f1057d2876541772b868f03f13df947c96a
Reviewed-on: https://gerrit.instructure.com/7092
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
closes#5880
We track failed attempts for both (pseudonym) and (pseudonym, ip) in
Redis, the latter with a lower threshold. If either threshold is
exceeded, the user can't attempt to login for a given time period
(default 5 minutes). This protects against brute force auth attacks.
We've hooked into Authlogic for this, so it should apply to everywhere a
user is logged in -- login screen, API basic auth, Respondus API, etc.
It doesn't apply to SSO auth, where the SSO authority is assumed to have
existing protection of its own.
I refactored the Respondus SOAP API to use Authlogic in a more standard
manner, to make this work.
Change-Id: I569823f83c5c2855526464da270426275eb857cd
Reviewed-on: https://gerrit.instructure.com/6428
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
allowing api_key to replace authenticity_token for normal cookie
sessions would open us up to a CSRF attack, by allowing a malicious user
to use the api_key without explicitly having the user credentials.
fixes#5162
Change-Id: Ia2604a6930d660dd04a8783fc983a3fe381ff48d
Reviewed-on: https://gerrit.instructure.com/5028
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Landon Wilkins