**User Login Trouble

When a user signs in with new or hidden devices, or if browsing history/cookies were deleted, users will be prompted to enter BOTH password and security question answers OR another 2SV option pending on their account settings. All users will also receive the email shown below. This applies anytime devices or browsing history has been hidden. This cannot be changed by AS.

If login is high risk:

• all users will get the "high risk login" email above
• some users will also get presented with security question after they enter password, others will get a 2SV preference they have set up
• it will be based on "user preference" first option
• if user didn’t set preferences, then they'll get whichever option they've enrolled in that's most secure first; authenticator app code OR mobile app prompt OR text message code

1. If they enter the correct password during high risk login, click on "forgot my security answer" and do not have other 2SV options set up
2. OR, as the last "self-serve" option in a 2SV flow before being presented with "Contact Us"

If false info spotted, (e.g. phone number 555-555-5555) walk user through updating info.

If a customer mentions anything that could potentially be related to an account takeover (someone not them taking control of their account) , please go straight to:  **Account Takeover ATO Hijacked Accounts Some examples could be the following (if this isn’t a concern / mentioned, continue with this map):

• My account is hacked OR Someone hacked my account
• Unable to access account (or email) and I didn’t make any changes to it
• Tried to reset password, but received an error that email is not associated with account

IMPORTANT: If a situation just doesn’t feel right, it’s highly encouraged to ping #ask-account-security channel to take a deeper look! We would much rather have a report that turns out to be nothing than to overlook a possible ATO account.

If the user has no access to that email or states the email is compromised:

1. In the event they do not have access to their email on the account, agent send 7 AS questions and if they fail, forward to AS Tier 1. If they pass, request TL/SA to change the email on the account and reset access. If agent has any concerns/doubts about the answers to the questions, forward to AS Tier 1.
2. In the event that the user states the email is compromised, lock out account and forward to Account Security Tier 1 so we can check for ATO on account. A compromised email suggests high likelihood of additional compromise.

If a “We see you need help...” ticket, see the proper drop-down process below.

If this is a "Request for upwork login due to GSSO failed" ticket, see the proper drop-down process below.

If a “User has exhausted all self-serve options for resetting their password” ticket, see the proper drop-down process below.

Process Map

If sending a case to AS, please also add info to this form here:

1. What phone number do you have on file with us? (can accept phone number with missing area code / country code, as long as main phone number is shared)
2. What address do you have on file with us?
3. Approximately what month and year did you join Upwork? (Only 3 months prior or after the actual date is acceptable)
4. In what country were you located when you signed up?
5. What are the first six digits of any credit card you have used on Upwork? (N/A is an acceptable answer if the customer has not added a UPM)
6. Provide the date that an Upwork transaction took place, per your bank statement. (Only 3 months prior or after the actual date is acceptable. Also, N/A is an acceptable answer if the customer has not added a UPM)
7. What is the date your PayPal account was added to Upwork? (Customers can see this info directly in their PayPal account. Also, N/A is an acceptable answer if the customer has not added a UPM)

If the customer does NOT answer 4/7 AS questions correctly, check if the customer has met ALL the 1-6 requirements below.

If they meet all below, continue to help the customer.

If they do NOT meet all below, follow the “Transfer to AS Tier 1” flow in the CS process map above.

1. Should be contacting CS from the email registered on their profile OR chatting in from their account OR calling in from their phone numbr on file; compare the email address used to create a ticket and the OBO email address
2. Should not have country changes on OBO User Actions (If Login/SQA were attempted from a country which is not the usual country of access for the user)
3. Should not have any active hourly jobs; check the OBO Contractor box/Client assignments lines (paused contracts are considered inactive)
4. Should not have available funds; check OBO Accounting Entity box, it should show “Balance as of today: $0.00”
5. Should not have hiring, staffing, or admin permissions for any agency or client company; go to OBO Identity box, hover mouse to wrench icon and click “Companies”, then look for hiring, staffing, or admin permissions. If it’s the client company owner, as they own the account, this is ok. This bullet is specific for those simply with permissions to the CL company and don’t actually own the account.
6. Should not have any history of ATO; see CSS Notes from AS Team to verify, sample ATO note below:

   

Important: If the customer has not met ALL of the requirements for “low-risk handling”, follow the “Transfer to AS Tier 1” steps within the CS Process map.

Remove Security Question

Set Temporary Password

Users can access the external Help Page Forgot Password or Security Question and go to the “What should I do if I forgot my password and my security question?” section to fill up a form to recover their account.

The form above  can be accessed from this external page.

Once submitted, the system automatically creates a ticket with a subject of “Forget my password and security question” that contains the answers to the actual verification questions.

In these situations, as the user can actively find this form within the Help Article, it’s important we check out the User Actions in OBO. We want to check for 2 things specifically:

1. Check if the user was able to successfully log in to their account; as we have multiple self service flows now, these tickets are very rare, so it’s possible they may have figured out a way to log in after submitting this ticket
2. Check for “dormancy” or “new device” as if we see that, that’ll change what action needs to be taken to help get them into their account

Based on 1 and 2 above, follow the CS Agent Process map for “Forgot Password AND Security Question Answer”.

In a situation where a user enters their correct password, but then prompted with their security question and they don’t know the answer, they’ll go through a self-service flow to help them create a new security question answer (SQA) without the need to reach out to CS for help.

If the customer fails to self-serve (aren’t receiving the emails, keep missing the hour mark, etc. and eventually exhaust their 4 attempts), they’ll be prompted with a “Contact Us” button where an automated ticket will be generated to CS - this is where those “User exceeded Security Question reset self-help attempts” emails come in! You’ll follow the map in these cases (more on that below).

What the user experience looks like -

If the SQA answer they type in is incorrect, they’ll see an “Incorrect answer. Please try again” message:

They can click “Forgot your answer?”:

If the customer fails to self-serve per the above flow (aren’t receiving the emails, keep missing the hour mark, etc. and eventually exhaust their 4 attempts), they’ll see a “Contact Us” button where the customer will receive an email that has the 7 security questions that the customer has to answer. A ticket will be sent to the CS queue only when the customer responds to that email. 

Here’s an example of the ticket with the autoresponder containing the 7 AS questions:

In a situation where a user doesn’t remember their password, they’ll go through a self-service flow to help them create a new password without the need to reach out to CS for help.

If the customer fails to self-serve (eventually exhaust their 3 attempts), they’ll be prompted with a “Contact Us” button where an automated ticket will be generated to CS - this is where those “User has exceeded authentication attempts for Forgotten Password” emails come in! You’ll follow the map in these cases (more on that below)

What the user experience looks like -

They click “Forgot password?”:

If they are unable to complete the specific security measure on their screen, they are able to click “Try another method” which will take them to their next activated security measure in their list.

Following the example from above, this customer clicked “Try another method” as they didn’t have their phone on hand to do the authenticator app. So, now they’re being challenged by their next in line, security question answer:

1. Ask 7 AS questions and if they answer 4/7 questions, continue with steps (if they do not pass, follow “No, user could NOT answer 4 questions correctly” path in the “CS Agent Process” dropdown above. If they PASS, continue with step 2.)
2. Request a TL/SA to reset all 2nd attempt verification factors in OBO AND initiate a temporary password AND remove security question answer
3. Explain to help get them back into their account, we reset their current security verification options and emailed them a temporary password. They can check their email to access the temporary password, then when they’re in their account, they can go to Settings > Password & Security to reset any of the verification methods they’d like on their account

What it looks like in User Actions in OBO:

In a situation where a customer has trouble logging in to their account or getting into the secure sections of their account (e.g. credit card info), they’ll go through a self-service flow to help them access their account/their Settings without the need to reach out to CS for help.

If the customer has trouble self-serving, they’ll be prompted with a form to fill out where a ticket will be generated to CS - this is where those “We see you need help…” tickets come in! 

What the user experience looks like - 

The customer may see 1 of 4 forms depending on what flow they were stuck in when trying to self-serve. 

1. Trying to reset their security question answer

2. Trying to log in to their account (knew their password, but not the SQA or 2SV they were prompted with)

3. Trying to access a high risk area in their Settings

4. Trying to reset their password  

What we see - 

Depending on which form the customer filled in, we’ll see 1 of 4 tickets that are all similar and all handled the same way, but just have slightly different subject lines. They all start with “We see you need help…”:

1. We see you need help resetting your security question
2. We see you need help logging into your account
3. We see you need help accessing your settings
4. We see you need help updating your password

The tickets will look like this with answers to the 7 AS questions available:

CS Handling Process:

Check User Actions! 

You’re checking to see if the customer was able to get into their account successfully OR were actually able to successfully access their Settings after they clicked they filled in their form, as this does happen occasionally. 

If they DID get into their account successfully / access their Settings (based on User Actions) after submitting the form - they should be okay! Please reply in the ticket that you can see that they were having some trouble logging in to their account / areas of their account, but it looks like they were able to successfully log in. If they do need any help, though, they can reply to the email.

If they did NOT get in their account successfully / access their Settings (based on User Actions), follow these steps - 

1. Verify the answers to the 7 AS questions they provided and if they answer 4/7 questions correctly, continue with steps (if they do not pass, follow “No, user could NOT answer 4 questions correctly” path in the “CS Agent Process” dropdown above. If they PASS, continue with step 2.)
2. Request a TL/SA to reset all 2nd attempt verification factors AND remove security question answer AND initiate a temporary password. IMPORTANT: if the customer checks ‘NO’ they do not want a temporary password, be sure to share that info with the TL/SA so they know not to reset that
3. Explain..

a. If we DID reset password: To help get them back into their account, we reset their current security verification options and emailed them a temporary password. They can check their email to access the temporary password, then when they’re in their account, they can go to Settings > Password & Security to reset any of the verification methods they’d like on their account.

b. If we did NOT reset password: To help get them back into their account, we reset their current security verification options. They can log in to their account, then go to Settings > Password & Security to reset any of the verification methods they’d like on their account.

4. Be sure to check under “Additional questions” to see if the customer needed help with anything else!

If they have no access to their email on file - In this situation, they would have filled in the “Contact Email” field. As long as they answered 4/7 AS questions correctly, a TL/SA can also change the email on the account and then have the temp password sent there. If there are ANY concerns/doubts about the answers to the 7 AS questions or they don’t answer them correctly, forward to AS Tier 1 for review.

FOR TL/SA SUPPORT ONLY -  For these cases, please reset everything: 

• reset all 2nd attempt verification factors AND 
• remove security question answer AND
• initiate a temporary password (please skip this one if the customer marks ‘NO’ to a temp. password in their ticket

Also, if a customer answers the “Contact Email” field, that means they no longer have access to their email address on their account and need that updated, as well.

Internal Info: We have a third party that checks for compromised credentials. If they come across something that looks to match Upwork credentials, they share with us. Upwork will take that info to do a comparison to see if there's an account that matches what the third party provided us with. To secure that account, we force a password reset update the next time the user enters their password.

There are two points of time where we ask for passwords:

1. when logging in, AND

2. when trying to make a change to sensitive info in their account e.g. updating credit card info

When this experience was first launched, due to a quick implementation, the user experience wasn't 100%. We received feedback that customers were getting stuck in a reset password loop. Looking into this further, we found we didn't have a "check" in place for when users were updating that password to confirm that:

1. they're not just entering another compromised password that would be on that third party's list, AND
2. they're not just reentering their same password we asked them to change in the first place

What's NEW!

Part of what we're introducing (to help customers get out of that loop and improve their overall experience) is a "check" to prevent users from using the same password AND from using another compromised password. It'll now force them directly into a reset password flow when that happens. We're also sending them two emails to finalize the password reset as well as to explain in more detail what this is about.

If the compromised password match is made after they enter in their password (either during Log In or when trying to access sensitive info in their account):

1. We log them out and redirect them back to log in

2. They'll enter their password and then see an error message that the password needs to be updated

3. Once they click "Update", they'll be forced into a reset password flow where they have to add a new password (they'll see this error message anytime they enter the password they used before or another compromised password)

4. After entering a new password, they'll click "send email"

5. This generates 2 important emails; 1. an email that provides more details into why they were being asked to reset their password (see here) and 2. an email that will actually initiate the resetting/updating of the password they just created (see here) - they must do this to finalize the change!

6. When clicking on "update password" in their email, they'll be directed to a flow which asks them for their 2nd level of security (this is pending what they have setup in their account e.g. security question answer, mobile prompt, etc.) and then they're all set!

CS can tell if a customer is/was impacted by this due to a CSS note being added to their account. These customers do have to change their password and there is not an "opt out" option in these cases.

In the rare occasion where GSSO needs to be disconnected from a closed Upwork account, the account needs to be reinstated, GSSO disconnected, and then the account can be closed again.

For the GSSO cases where we can see the user doesn't actually need help as they figured out how to sign in before we got to the ticket (this can be verified via user actions, see screenshot below), we don't have to reset anything and can just let the user know we can see they have successfully logged in, but if they still need help, let us know.

CS Agent Process Steps:

1. If they answer 4/7 AS questions, continue with steps (if they do not pass, follow “No, user could NOT answer 4 questions correctly” path in the “CS Agent Process” dropdown above. If they PASS, continue with step 2.)
2. Check via User Actions that GSSO is definitely enabled:
3. Also, within User Actions, check to ensure that the user was definitely not able to log in since this ticket came in (reason for this is because we’ll be disabling GSSO, so this is super important)
4. IF steps 1 to 3 are cleared and they ARE GSSO enabled, passed the 4/7 AS questions, and, have not successfully logged in since this ticket came through, request a TL/SA to disable GSSO AND create a temp. password
5. Once the TL/SA confirms this is completed, explain they should now have an email with a temp. password to allow them to sign in to their account with their username/temp. password. Once signed in, they can go to Settings > Connected Services > click ‘Sign in with Google’ to reset the GSSO, if they’d like to. They can also check out Password & Security to change their password and set up any two-step verification options.

Resources:

• Help Center article
• Deck

Our mobile app users want an authentication experience that is secure, seamless & mobile forward. To deliver this, we’re focusing on two objectives:

1. Provide mobile app users with a secure alternative to password
2. Deliver the sort of experience that mobile users expect

Key callouts & points to understand:

• Instead of authenticating by entering a password, enrolled Mobile App users will be able to authenticate using the same biometric “key” (their face or fingerprint) that they use to unlock their mobile device.
• On initial release this feature will only be available for mobile app authentication, but we have plans to introduce this feature for desktop devices later on.
• The only step on the “confirm that it’s you” path this will replace is password entry. If circumstances require a second verification (via text message, mobile app prompt, etc.), this will continue to happen.
• If users are enrolled in SSO for sign-in, SSO will not be replaced by biometric authentication “automatically”.  As usual, users will still have to “disconnect” SSO for sign-in first. Regardless, these users will be able to use biometric authentication for any *Sensitive Zone checks.

*Sensitive Zone Rules: 

• Force “re-authentication” IF: (1) User is trying to access a protected page, and 30 mins have passed since the last successful password validation, including “at login”. 

• Force “device authorization” (2-step verification challenge) IF: (a) user is trying to access a protected page, and user did NOT check “remember this device when last challenged, and 30 mins has passed since they were last challenged, or (b) user is trying to access a protected page, and user DID check “remember this device when last challenged, and 90 days have passed since they were last challenged.

• Note - these are device dependent, and not synced across devices or browsers.

What’s New/Different/Better:

Once Enrolled:

Enrolled users will be able to use the “Face or Fingerprint ID” they use to unlock their mobile device for sign-in and Sensitive Zone authentication instead of using their password.

Who can enroll/enable:

• • Non-enterprise mobile app users
    • Users signing in with password will be able to use this feature for both sign-in and Sensitive Zone check as soon as they enroll
    • Users signing in with SSO will be able to use this immediately for “re-authenticating” at Sensitive Zone, but will have to disconnect Google or Apple SSO before they can use this feature for sign-in.

How to enable

Path 1 - Enroll manually via Settings/Password & security/Authentication options/Face or Fingerprint Recognition (See deck for more details)

 

Two Paths when enabling via Settings:

• Happy Path - User has already set up face/fingerprint ID enabled in their device Settings
  • Check Deck for the Setting Enable Flow - HAPPY PATH

 

• Unhappy to Happy Path - User is guided to enable face/fingerprint on their device and then “try again”
  • Check Deck for Settings Enable Flow Unhappy to Happy Path (iOS) 

Path 2 - Guided enrollment is offered at sign-in

(See deck for more details)

 

 

Path 3 - Guided enrollment is offered at Sensitive Zone re-authentication

(See deck for more details)

How to disable

Users can disable this feature from Settings/Password & security/Authentication options/Face or Fingerprint ID.

(See deck for more details)

What the user sees when the feature is enabled vs disabled

 

 

How users with this feature enabled are challenged to authenticate

1) At sign-in, and;

(See deck 28-31 for more details)

 

2) At Sensitive Zone

(See deck 32-33 for more details)

 

Fallback Options at Failed Authentication

When challenged, if users fail to successfully complete their Face or fingerprint recognition they will be returned to the page where they normally would “password”. There they will have the option to complete authentication either by entering their password, or by tapping on the “Face or fingerprint recognition” icon to re-initiate the biometric authentication flow.

 

What if the user is enrolled for Face or fingerprint recognition, then signs out of their mobile app?

If a user signs out of the mobile app they’ll have to sign back in, but instead of being asked to enter their password, they’ll need to provide their biometric. 

 

You can see this user experience for users that either explicitly signed out, or were signed out by Upwork due to inactivity.

 

 

Manually Disable Fingerprint/Face Recognition

If a customer is having difficulty trying to log in with their fingerprint/face ID for whatever reason and can't get in to turn it off themselves, TLs and SAs can help manually disable it for the user.

 

CS Agents: Follow the 7 AS process before sending to a TL/SA to be manually disabled. If a SA/TL does manually disable for you, please share with the customer that to re-enable, they can go to Settings > Password & Security.

 

TL/SAs:

1. Hover to Identity widget’s wrench icon. Then click “Other”.
2. Scroll down to the Manage AF tab on the sidebar.
3. Check the Biometric checkbox to remove
4. Add detailed notes. Then click “Disable” button
5. Inform agent it’s disabled and remind to share with the customer how to re-enable

Sample note:

[ACTION] Manually disabled fingerprint/facial ID

[DEPARTMENT] CS

[CAUSE] Unable to login with fingerprint/facial ID

[NEXT STEP] N/A

[TICKET ID] Insert ticket URL

FAQs

Agents - Please use Tag Only::Biometric Auth (macro_tag_only_biometricauth)
 

How do I enable Face or Fingerprint recognition for authentication?

Thanks for your question. Here’s how you can enable Face or fingerprint recognition for authentication:

1. In the app, tap the Settings button and select “Password & security”
2. Go to “Authentication Options” and tap “Face or fingerprint recognition” to toggle it on (highlighted green)
3. Follow the prompts to scan your face and/or fingerprint

Do I have to stay signed into my Upwork app in order to use Face or fingerprint recognition?

Thanks for your question. You do not have to remain signed into the Upwork app to use Face or fingerprint recognition. In fact, signing in is one of the places where Face or fingerprint recognition is utilized.

What if I get a new phone after I’ve set up Face or fingerprint recognition?

Thanks for your question. If you get a new phone, you’ll need to do two things to continue to use this feature:

• In your mobile app, go to Settings › Password & Security › Authentication Options, using your password to re-authenticate if asked

• Enable “Face or fingerprint recognition” for your new mobile device

This will pair your new device with your Upwork account. 

Do I have to enable Face or fingerprint recognition?

Nope! We understand you may have concerns about scanning your face or fingerprint, so we made Face or fingerprint recognition on the Upwork Mobile apps purely optional. It’s there for those who would like a simplified and more-secure authentication; users who prefer passwords can continue to use them.

If I enable Face or fingerprint recognition, am I stuck using it forever?

Not at all! You can disable Face or fingerprint recognition at any time. To disable:

1. In the app, tap the Settings button and select “Password & security”
2. Select “Authentication Options” from the menu
3. Tap the “Face or fingerprint recognition” to toggle it off

What do you do with the biometric information?

We understand you may have privacy concerns, but for this sign-in feature none of your biometric information is ever in our possession. In fact, it never leaves your device. During authentication, the Upwork app checks your fingerprint/face scan against the scan you’ve saved on your device.

What happens if I have Face or fingerprint recognition enabled but it's not working?

Sorry you’re having trouble. If Face or fingerprint recognition fails numerous times, you will be automatically redirected to the password page. Here you can either tap the “Face or fingerprint recognition” icon to re-attempt, or simply enter your password.

If you continue to have issues with Face or fingerprint recognition, try disabling it.

We are updating our password policies due to the vulnerabilities identified during penetration testing. The key callout was the need for Upwork to introduce password “blacklisting” in addition to other related functionality.

Objectives:

1. Force users who are (a) adding passwords at registration, or (b) editing existing passwords to create passwords that are "strong"

2. Encourage users who have "weak" passwords to strengthen them in a situation when it is logical to make this suggestion.

FAQs

Why did you make this change? Why are you making me do this now?
Thanks for your question. Passwords are a user’s frontline defense against someone gaining unauthorized access to their account. Because we are continuously working to help our customers keep their accounts secure, we have updated our system to prompt all users to create a strong password.

What is considered a “strong” password?
Thanks for asking! A strong password meets the following criteria:

• It is at least 8 characters (max is 4000 characters)
• It contains one number or special character
• It isn’t known as weak and easily hackable, like “password123”
• It does not match your email address

How did you set the criteria for what’s considered a “strong” password?
Thanks for your question. We carefully reviewed and aligned our password update with the recommendations of the National Institute of Standards and Technology, a U.S. agency that sets password guidelines. 

 

I see other people talking about Upwork requiring users to enter a stronger password. I haven’t been asked to do so, why?
Thanks for your question. If you are worried that your password may not be strong enough, you can update it anytime by going to “Settings” then “Password & Security.” Click on the edit icon (the pencil) and you'll find tips for creating a strong password and be guided through the strong password set-up process.

I keep trying to update my password and it keeps giving me an error message (due to weak password issues). What’s wrong?

Thanks for reaching out. I’m sorry you are having trouble. In most cases, this usually occurs when your selected password doesn’t meet the required criteria. Your password must:

• Be at least 8 characters (and no more than 4000 characters)
• Contain at least one number or special character
• It isn’t known as weak and easily hackable, like “password123”
• Not match your email address

This is dumb! Can I opt-out? I’m not worried about my security!
Thanks for reaching out. We’re sorry, you cannot opt-out of creating a strong password when you are prompted to do so. Requiring a strong password not only protects your Upwork account, but the accounts of other Upwork users who would be at risk if someone hacked your account and acted fraudulently in our marketplace.

Screenshots

Guidance	New UX
1a - User goes to password & security settings Users edit password today by going to Password & security settings. Clicking on the edit icon kicks off the editing process. Requirement: N/A.
2a - User clicks on “edit password” On the password modal users must enter their “current” password in order to authenticate before adding and saving a new password. Requirements:  - “Enforce” password policies as follows. ie) do NOT allow users to save passwords that do not meet the following policy requirements:: Min length = 8 characters Must contain at least one number or one special character Max length = 4,000 characters May not contain email address Must contain at least one “letter”
	Use Case #1 - “user has not yet entered their password choice”
	Use Case #2a -  “user has entered a password but it does not meet backend policy requirements for passwords”
	Use Case #2b -  “user has entered a password that meets backend policy requirements AND full set of complexity traits”
	Use Case #3 - Error Messaging Requirements - Error messages should be shown if the user attempts to “confirm/save” a password that meets the following conditions: Too short Error message: Your password is too short Too long Error message: Your password is too long Contains their email address Error message: Your password may not contain your email address Is on our “blacklist” Error message: The password you’ve chosen is not allowed Example when all “strength indicators are met but another policy requirement is NOT met Example when all “complexity attributes are NOT met and policy requirements is NOT met A link when clicked will pop up a box with “tips” for creating stronger passwords
1b & 2b - user adds their first password for email + password login When users register and choose username or email + password for future logins they’ll choose their password in this modal.
1c & 2c - user adds their first password after registering via Google SSO When users register with Google SSO they set their password at a point in time after registration. See circumstances right.	This is shown to SSO users in any circumstance where both have yet to be set. This is shown for users who register with SSO and end up setting their SQ/SA prior to first touching sensitive zone

 

Scenario 2 - Flow to check for password strength at Sensitive Zone password entry

Guidance	New UX
1 - User is challenged to enter password at sensitive zone (need more info) Today there are conditions under which users would be challenged to enter their password at sensitive zone, but we don’t currently check to see if that password is “secure”
2 - User enters a “weak” / “insecure” password
(original requirements) 3 - User clicks “update”
(revised requirements) 3 - User clicks “update”