1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 16:22:43 +01:00
phorge-phorge/src/applications/settings/panel/PhabricatorPasswordSettingsPanel.php

218 lines
6.7 KiB
PHP
Raw Normal View History

<?php
final class PhabricatorPasswordSettingsPanel extends PhabricatorSettingsPanel {
public function getPanelKey() {
return 'password';
}
public function getPanelName() {
return pht('Password');
}
public function getPanelGroupKey() {
return PhabricatorSettingsAuthenticationPanelGroup::PANELGROUPKEY;
}
public function isEnabled() {
// There's no sense in showing a change password panel if this install
// doesn't support password authentication.
if (!PhabricatorPasswordAuthProvider::getPasswordProvider()) {
return false;
}
return true;
}
public function processRequest(AphrontRequest $request) {
$user = $request->getUser();
$token = id(new PhabricatorAuthSessionEngine())->requireHighSecuritySession(
$user,
$request,
'/settings/');
$min_len = PhabricatorEnv::getEnvConfig('account.minimum-password-length');
$min_len = (int)$min_len;
// NOTE: To change your password, you need to prove you own the account,
// either by providing the old password or by carrying a token to
// the workflow from a password reset email.
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
$key = $request->getStr('key');
$password_type = PhabricatorAuthPasswordResetTemporaryTokenType::TOKENTYPE;
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
$token = null;
if ($key) {
$token = id(new PhabricatorAuthTemporaryTokenQuery())
->setViewer($user)
->withTokenResources(array($user->getPHID()))
->withTokenTypes(array($password_type))
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
->withTokenCodes(array(PhabricatorHash::digest($key)))
->withExpired(false)
->executeOne();
}
$e_old = true;
$e_new = true;
$e_conf = true;
$errors = array();
if ($request->isFormPost()) {
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
if (!$token) {
$envelope = new PhutilOpaqueEnvelope($request->getStr('old_pw'));
if (!$user->comparePassword($envelope)) {
$errors[] = pht('The old password you entered is incorrect.');
$e_old = pht('Invalid');
}
}
$pass = $request->getStr('new_pw');
$conf = $request->getStr('conf_pw');
if (strlen($pass) < $min_len) {
$errors[] = pht('Your new password is too short.');
$e_new = pht('Too Short');
} else if ($pass !== $conf) {
$errors[] = pht('New password and confirmation do not match.');
$e_conf = pht('Invalid');
} else if (PhabricatorCommonPasswords::isCommonPassword($pass)) {
$e_new = pht('Very Weak');
$e_conf = pht('Very Weak');
$errors[] = pht(
'Your new password is very weak: it is one of the most common '.
'passwords in use. Choose a stronger password.');
}
if (!$errors) {
// This write is unguarded because the CSRF token has already
// been checked in the call to $request->isFormPost() and
// the CSRF token depends on the password hash, so when it
// is changed here the CSRF token check will fail.
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
$envelope = new PhutilOpaqueEnvelope($pass);
id(new PhabricatorUserEditor())
->setActor($user)
->changePassword($user, $envelope);
unset($unguarded);
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
if ($token) {
// Destroy the token.
$token->delete();
// If this is a password set/reset, kick the user to the home page
// after we update their account.
$next = '/';
} else {
$next = $this->getPanelURI('?saved=true');
}
2014-08-04 21:04:35 +02:00
id(new PhabricatorAuthSessionEngine())->terminateLoginSessions(
$user,
$request->getCookie(PhabricatorCookies::COOKIE_SESSION));
return id(new AphrontRedirectResponse())->setURI($next);
}
}
$hash_envelope = new PhutilOpaqueEnvelope($user->getPasswordHash());
if (strlen($hash_envelope->openEnvelope())) {
try {
$can_upgrade = PhabricatorPasswordHasher::canUpgradeHash(
$hash_envelope);
} catch (PhabricatorPasswordHasherUnavailableException $ex) {
$can_upgrade = false;
// Only show this stuff if we aren't on the reset workflow. We can
// do resets regardless of the old hasher's availability.
if (!$token) {
$errors[] = pht(
'Your password is currently hashed using an algorithm which is '.
'no longer available on this install.');
$errors[] = pht(
'Because the algorithm implementation is missing, your password '.
'can not be used or updated.');
$errors[] = pht(
'To set a new password, request a password reset link from the '.
'login screen and then follow the instructions.');
}
}
if ($can_upgrade) {
$errors[] = pht(
'The strength of your stored password hash can be upgraded. '.
'To upgrade, either: log out and log in using your password; or '.
'change your password.');
}
}
$len_caption = null;
if ($min_len) {
$len_caption = pht('Minimum password length: %d characters.', $min_len);
}
$form = new AphrontFormView();
$form
->setUser($user)
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
->addHiddenInput('key', $key);
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
if (!$token) {
$form->appendChild(
id(new AphrontFormPasswordControl())
->setLabel(pht('Old Password'))
->setError($e_old)
->setName('old_pw'));
}
$form
->appendChild(
id(new AphrontFormPasswordControl())
->setDisableAutocomplete(true)
->setLabel(pht('New Password'))
->setError($e_new)
->setName('new_pw'));
$form
->appendChild(
id(new AphrontFormPasswordControl())
->setDisableAutocomplete(true)
->setLabel(pht('Confirm Password'))
->setCaption($len_caption)
->setError($e_conf)
->setName('conf_pw'));
$form
->appendChild(
id(new AphrontFormSubmitControl())
->setValue(pht('Change Password')));
$form->appendChild(
id(new AphrontFormStaticControl())
->setLabel(pht('Current Algorithm'))
->setValue(PhabricatorPasswordHasher::getCurrentAlgorithmName(
new PhutilOpaqueEnvelope($user->getPasswordHash()))));
$form->appendChild(
id(new AphrontFormStaticControl())
->setLabel(pht('Best Available Algorithm'))
->setValue(PhabricatorPasswordHasher::getBestAlgorithmName()));
2014-08-04 21:04:35 +02:00
$form->appendRemarkupInstructions(
pht(
'NOTE: Changing your password will terminate any other outstanding '.
'login sessions.'));
$form_box = id(new PHUIObjectBoxView())
->setHeaderText(pht('Change Password'))
->setFormSaved($request->getStr('saved'))
->setFormErrors($errors)
->setForm($form);
return array(
$form_box,
);
}
2014-08-04 21:04:35 +02:00
}