Sensitive Data: Mitigate against password guessing attacks

[pdurbin]

http://policy.security.harvard.edu/sb2-password-guessing says the following as of 2016-06-01:

Password guessing

SB2: Servers or applications must implement a mechanism that inhibits password guessing attacks on user accounts if the server or application does its own authentication.

How to Comply

Block excessive logins

Block user from logging in for a period of time after no more than 10 successive invalid login attempts.

Dataverse does do its own authentication in the case of local/builtin accounts so we need to meet this requirement to be able to host level 3 data as defined at http://policy.security.harvard.edu/level-3

When Shibboleth accounts are used, we're trusting that the Identity Provider (IdP) is mitigating against password guessing attacks.

We should decide what "block user from logging in for a period of time" means. My initial thought would that this would be disabling the account for an hour or whatever (configurable) but this is not yet supported (#2419) and from reading https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks I'm realizing that there's the potential for abuse. An attacker who knows your username or email address for your local/builtin account would be able to lock you out of your account temporarily simply by guessing random passwords 10 times. That OWASP page suggests blocking the IP of the attacker, which may be problematic if many users are behind one IP address. It also suggests a CAPTCHA but I don't think that would meet the "block user" requirement. Their suggestion to introduce a delay against the IP of the attacker reminds me strongly of IQSS/dataverse-pm#23 which is about adding rate limiting to the API.

[pdurbin]

I posted a link to this issue to https://groups.google.com/d/msg/dataverse-dev/hxnA_Wumo_M/J41aNceCBAAJ and http://irclog.iq.harvard.edu/dataverse/2016-06-08#i_36462 and http://irclog.perlgeek.de/crimsonfu/2016-06-09 for discussion and I like the idea from @pameyer and @bpeisenbraun of what seems to be called "exponential backoff". The screenshot below is from https://devcentral.f5.com/articles/implementing-the-exponential-backoff-algorithm-to-thwart-dictionary-attacks and shows how the lockout time increases with each subsequent failed login attempt:

If we happened to be using Ruby and Rack, we could take advantage of the exponential backoff feature of rack-attack: https://github.com/kickstarter/rack-attack/wiki/Advanced-Configuration#exponential-backoff

I suppose the thing we would be locking out is an IP address. I'm actually not sure that we need to implement account disabling in #2419 first. The requirement is to block a user from logging in, which is different from disabling an account.

[pdurbin]

Obviously, we'd like to avoid the scenario at https://twitter.com/esttorhe/status/743623557352022020 in the screenshot below:

[pdurbin]

This morning @djbrooke and I met to discuss this issue. I presented two approaches:

• Approach 1: Lock account. After 10 (or fewer, configurable) successive invalid logins, lock the account (User account cannot be disabled/deactivated #2419) for a period of time (configurable).
• Approach 2: Block IP. After 10 (or fewer, configurable) successive invalid logins, block the IP address for a period of time (configurable).

@djbrooke indicated that I should go ahead work on #2419 so that locking an account is possible and then implement Approach 1: Lock account. So this issue is dependent on that one.

As I indicated above, locking the account was my initial thought anyway (perhaps because of how the requirement is written) and @landreev seems to agree with this approach. Yesterday I wrote to abdc-security and a friend reacted with, "you are overthinking your password lockout problem... N bad passwords in Y interval locks out the account for 24 hours."

I've been discussing Approach 2 (Block IP) with @whorka and he was gracious enough to show me the code at https://accounts.hmdc.harvard.edu which uses this approach but again, we'll focus on account locking instead (Approach 1).

[michbarsinai]

Important heads-up. Thanks, Phil!

My comments:

1. Disabling account is very different from blocking a login. For example, if someone tries to guess user X's password, while user X is logged in from another device or is using the API via a script, X's legitimate usage would be stopped. Moreover - if someone has a password and tries to guess the username, this would go under the radar of account disabling.
2. Blocking an IP would probably not work either, especially with our target audience, as institutions tend to use a few IP addresses for outside access.
3. Also - blocking and tracking done on the server-side add overhead to the server, sometime for each HTTP request.

So - I assume it's best not to allow people to automatically guess password, which is what CAPTCHA does. We could use reCAPTCHA (or similar project, as reCAPTCHA was acquired by Google) to help digitize books while we're at it. So maybe present a CAPTCHA after 3 failed tries from same IP address in a 3-4 minute period. That's still added some burden on the server, but we could use an in-memory asynchronous map, and not have to go to the DB again. Also - this would effect only the login screen.

[pdurbin]

@michbarsinai thanks for your thoughts on all this. I'm not sure a CAPTCHA fulfills the requirement of "Block user from logging in for a period of time after no more than 10 successive invalid login attempts."

As I mentioned at #3153 (comment) I'm focusing on locking the account for now. Here's a screenshot to get @mheppler @eaquigley and @mcrosas thinking about what the UI/UX should be:

I'm also adding logic in EjbDataverseEngine to prevent Commands from being executed when an account is locked. Once I have something worth demo'ing I'll push a war file to a test server.

[michbarsinai]

But any disaffected student could lock his professor out this way... maybe the rule needs updating or refinement.

What does Harvard's SHIB/HarvardKey servers do?

On 29 Jun 2016, at 23:10, Philip Durbin notifications@github.com wrote:

@michbarsinai https://github.com/michbarsinai thanks for your thoughts on all this. I'm not sure a CAPTCHA fulfills the requirement of "Block user from logging in for a period of time after no more than 10 successive invalid login attempts."

As I mentioned at #3153 (comment) #3153 (comment) I'm focusing on locking the account for now. Here's a screenshot to get @mheppler https://github.com/mheppler @eaquigley https://github.com/eaquigley and @mcrosas https://github.com/mcrosas thinking about what the UI/UX should be:

https://cloud.githubusercontent.com/assets/21006/16467071/ad76d914-3e13-11e6-919d-cfcca0ed2d98.png
I'm also adding logic in EjbDataverseEngine to prevent Commands from being executed when an account is locked. Once I have something worth demo'ing I'll push a war file to a test server.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3153 (comment), or mute the thread https://github.com/notifications/unsubscribe/AB2UJJraDbV5Sqi56CH0G-NB8NDyM5zPks5qQtEdgaJpZM4Iri3k.

[djbrooke]

Notes from 7/7 meeting:

• 10 tries before an account is locked
• We need better error message visibility (it was unclear that the account lock message was triggered as it looked so similar to the "wrong password" message)
• The lockout period should be configurable
• Open question - does the superuser have the ability to unlock an account?