?

Log in

 
 
19 May 2017 @ 01:43 pm
Security vs Usability tradeoff  
When developing a user-facing application, prioritization of security versus usability - requires delicate balancing.

Here are some examples:

1) When postjobfree emails to a user account recovery link, we want to make that the link is usable, and allow user to use that link for a day (24 hours).
In some scenarios such account recovery link could be usable for the user even after 24 hours. But such a long window for taking over an account based on a single link would be making postjobfree.com account less secure (what if an attacker get an access to an old "account recovery" link?).

2) When user opens that account recovery link, PostJobFree allows user to set a new password, and it also autologins user to that account.
But what if user opens the same link for the second time: should PostJobFree allow user to change account password and autologin again or not?
From security perspective it is safer to expire such a link immediately after user opened the link.
From usability perspective it is better to allow that link to work for the second time, because user may accidentally open that "account recovery" link twice. Or an antivirus program may pre-open email link before user opens it.
In order to balance these security and usability demands, we decided to allow account recovery link to work for 1 hour after it was already used (unused account recovery link can be used for up to 24 hours).

3) What if user changed password on his account: should we allow old account recovery links to work or not?



Here is a typical "security" scenario:
User account owner found that an attacker (or a former employee) has an access to the account. So the account owner changes the password and expects that the attacker would not have an access to the account anymore. But if the attacker still has an old account recovery link - he can still autologin.
So, from security perspective, we should immediately expire all "account recovery" links that were sent before password change.
However there is an important "usability" scenario too:
- User posts a job, which creates a new account for the user.
- PostJobFree emails "confirm email" link to the user:
===============
From: PostJobFree <noreply@postjobfree.com>
To: testuser@gmail.com
Subject: Confirm your PostJobFree registration

===============

("Confirm email" link functions similar to "account recovery" link).
- While waiting for that "confirm email" link to arrive in the email inbox, user sets up a password on that new account (as a part of a new account setup process).
- Then user opens "confirm email" link.
If, according to security demands, "password change" in the previous step expired such "confirm email" link, then an important piece of usability is lost: user cannot immediately confirm that email is functioning, and has to request another "confirm email" link.
So, how do we balance these contradictory demands between security and usability in this case?
The best approach seems to be to prioritize usability in cases when user sets up a new account, but prioritize security when user changes password on already established account.
So if user changed password while going through initial account setup wizard - then keep previously sent links functioning. But if user already had password set, and now decided to change the password again - then expire all past "account recovery", "confirm email" and "change email" links immediately.
Such granular balancing between security and usability allows to deliver good security to the users who care about security of their account (users who change their account passwords manually -- such users are a minority), but still deliver a good usability to the vast majority of users who setup their password only if they are nudged by the account setup wizard.

Originally posted at: http://dennisgorelik.dreamwidth.org/131858.html
 
 
 
Leonid Smetaninleonid_smetanin on May 20th, 2017 01:02 am (UTC)
Я думаю, что password recovery link должен протухать через десять минут или сразу после смены пароля. Я с трудом могу себе представить сценарий, где юзер запросил смену пароля и пошёл обедать, точнее я могу себе представить такой сценарий, но он чреват гигантской секьюрити дырой, т.е. линком может воспользоваться кто-то другой.
Сколько раз по нему кликали не важно, важно общее время и факт смены пароля.
3. Не давать установить пароль до клика на линк верификации емейла
Dennis Gorelikdennisgorelik on May 20th, 2017 05:46 pm (UTC)
> Я с трудом могу себе представить сценарий, где юзер запросил смену пароля и пошёл обедать

А сценарий, когда email задерживается на часик-другой, потому что спамоловка на принимающем почту сервере тормозит - ты представить можешь?

> 3. Не давать установить пароль до клика на линк верификации емейла

Почему нет?
:-O
Leonid Smetaninleonid_smetanin on May 21st, 2017 12:26 am (UTC)
> спамоловка на принимающем почту сервере тормозит - ты представить можешь?

на несколько часов? Нет, не могу представить. ЛЮБЫЕ компьютерные задержки это микросекунды, ну, хорошо, минуты, но не часы.
Зато я очень хорошо могу представить себе сценарий, где человек запросил смену пароля и не получил его через минуту, что он делает? Он запрашивает ещё раз, а не ждёт два часа.

3. Не давать установить пароль до клика на линк верификации емейла
Почему нет?

потому что в этом случае я могу зарегистрировать аккаунт на левый емейл.
Dennis Gorelikdennisgorelik on May 21st, 2017 02:06 am (UTC)
> ЛЮБЫЕ компьютерные задержки это микросекунды, ну, хорошо, минуты, но не часы.

Это в нормально работающих системах.
Далеко не все системы работают нормально, а если и работают нормально, то не всегда.
В результате существенная доля (несколько процентов) наших пользователей получает email c задержкой. И, соответственно, не могут линк из этого email использовать немедленно.

> человек запросил смену пароля и не получил его через минуту, что он делает?

Обычный человек, а не компьютерный гик, типа тебя?
Обычно, ждёт. Или, вообще забывает.
Хотя многие - запрашивают ещё разок.
Ущерба от этого почти нет.

> потому что в этом случае я могу зарегистрировать аккаунт на левый емейл.

От того, что ты создал свой пароль - PostJobFree тебе никаких дополнительных прав не даст (кроме того, что ты сможешь этот пароль использовать для того, чтобы залогиниться).
А вот если ты подтвердишь email - ты получишь дополнительные возможности.

У меня раньше были похожие на твои взгляды на то, каким должен быть пароль.
Например, "account recovery" email жил только один час.
Впрочем, даже когда я начинал создавать postjobfree.com (10 лет назад) - уже тогда я ожидал от пользователей быть менее компетентными.
С тех пор мы добавили некоторые фичи, которые упрощают работу с username/password.

И оказалось, что аккаунты пользователей никто не взламывает. Это просто никому не нужно.