1password Paypal 2fa Account
PayPal has now added 2FA, so this info is no longer needed. Kept for posterity.
Two-factor authentication today is a must to keep your online accounts safe. You certainly want to keep your PayPal account safe. Using SMS to add an extra
My paypal account (with 2FA) password changed without my knowledge I just woke up and get an email said that my password just changed a few hours ago. So I checked on my desktop to be sure and my password does changed. Just to be safe I changed it again with different password, but my main confusion is because I already activated 2FA on my. Even without PayPal 2FA (and any other), you've got many and varied problems if someone can find your phone, unlock it easily (or not have a lock at all), and retrieve your email: every site which allows email-based password reset is now available to the finder, and a shopping spree on Amazon or similar would be an easy next step.
Software Installation
First, we need to install some software. I’m using a Macintosh, and these instructions should work under Linux.
2fa Password
First, you need to install the Xcode command line software. Just open the Terminal application that you can find in the /Applications/
Start it and enter:
This command installs the necessary tools for the rest of the installation.
Now, let’s install the actual tool that creates the key.
Enter the following into the terminal application:
I had to replace pip3 with pip on my installation, but I have many changes in my Python setup, so that may be the reason why pip3 didn’t work on my Mac.
You need to install a software called HomeBrew.
Just enter the following in the Terminal window and press return:
Now we can use Brew to install the rest of the software needed.
Just type the following into Terminal and press enter:
That’s all the software you need. Now let’s continue.
Creating Two-Factor Authentication Key
Let’s continue in the Terminal application. We first need to create a key. This key will be used to generate all the six-digit authentications later.
Enter this into Terminal and press return:
This will create a unique key and store it in a hidden folder in your home directory.
The output from the command should look something like this.
Generating request…
Fetching provisioning response…
Getting token from response…
Decrypting token…
Checking token…
Credential created successfully:
otpauth://totp/VIP%20Access:VSSTXXXXXXXX?digits=6&secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&period=30&algorithm=SHA1&issuer=Symantec
This credential expires on this date: 2022-02-12T02:26:33.767Z
You will need the ID to register this credential: VSSTXXXXXX
You can use
as would be produced by the official VIP Access apps:
oathtool -d6 -b –totp XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # 6-digit code
oathtool -d6 -b –totp -v XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # … with extra information
Your information is going to look different. The X:ed out in the above output is my key, so I’ve obscured it with X:es. You are going to need this information later to create the key required for PayPal. It’s a good thing to save this output, so copy the text from the Terminal application and paste it into the “Notes” field of your PayPal password inside 1Password.
PayPal Settings
Now it’s time to log in to PayPal and do some changes.
You need to login to your PayPal account. Go to your account setting, and click on “My Settings”. Click on “Update” under the section “Security key”.
Click on “Activate a new security key token.” See picture below.
In the field “Serial number”, enter the key from the output in the Terminal application called “You will need the ID to register this credential:”
It starts with VSST and has six digits after it. Copy it complete with VSST and the six following numbers. Paste it into PayPal’s field “Serial number”
In step 2 on PayPal’s setting, you should input a 6-digit code, but you need to create one first. Copy the command you got from the Terminal output when creating your key. It should look something like this:
oathtool -d6 -b –totp XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX # 6-digit code
Paste it into the Terminal application and press return.
This will display a six-digit code. Just copy the generated code from your Terminal window into the first 6-digit field.
Now go back to the Terminal application, and repeat the command. The easiest way is to just press the up-arrow on your keyboard, which should fill in the command you just entered automatically. Press return. If the six-digit key is the same, just keep repeating the command until you get a new unique key. Copy that key and paste it into the field “Next 6-digit key” on the PayPal web page.
Now press activate on the PayPal page and if everything worked out, you should now have a security key completed in PayPal.
Let’s move on to 1Password and make it automatically generate the two-factor authentication for your PayPal password.
1Password Two-Factor Authentication For PayPal
Open the 1Password application. Search for your PayPal password in the search field. Select the PayPal password and press the “Edit” button in the lower right side of the 1Password window.
Now press the circle with three dots inside to add a new field. Select “One-time password” as the field type.
You now have a One-Time Password field, but you need to add the secret key into this field. Copy the information Credential created successfully: you got earlier when we created the key in the Terminal application. It should look something like this:
Now all you have to do is to paste the entire line into the “One-Time Password” field inside 1Password.
Press save in 1Password in the lower right side of the window.
Let’s try it out!
If you added the field described above, as a result, you should now have an indicator showing a timer and a six-digit generated key on one of the lines of information in 1Password for your PayPal password.
If you’ve have done all of the above and everything worked, you are now ready to try it out. Log out of PayPal, and try to log in again using 1Password. It should automatically fill out the password and then copy the generated six-digit key into the clipboard. Paste the six-digit key into the field when PayPal ask for it. You should now be logged in.
Conclusion
If you think that this was a lot of stuff to do just to get better security in PayPal, you’re absolutely right. Send an email to PayPal and ventilate your anger. If they just used normal 2FA-encryption you wouldn’t need all this work. But if you managed to get through all this, give yourself a pat on the back. You just made your PayPal much safer and also gives you a more
[See Part 2 for our CTO's insights.]
Overview
Researchers at Duo Labs, the advanced research team at Duo Security, discovered that it is possible to bypass PayPal’s two-factor authentication (theSecurity Key mechanism, in PayPal nomenclature). The vulnerability lies primarily in the authentication flow for the PayPal API web service (api.paypal.com) -- an API used by PayPal’s official mobile applications, as well as numerous third-party merchants and apps -- but also partially in the official mobile apps themselves.
As of the date of this post (June 25), PayPal has put a workaround in place to limit the impact of the vulnerability, and is actively working on a permanent fix. In light of the vulnerability reporting timeline and the trivial discoverability of the vulnerability, we have elected to publicly disclose this issue, so that users can be informed to the risks to their PayPal account security.
Duo would also like to thank Dan Saltman from EverydayCarry for his assistance in the initial reporting of this issue.
Impact
An attacker only needs a victim’s PayPal username and password in order to access a two-factor protected account and send money. The protection offered by the two-factor Security Key mechanism can be bypassed and essentially nullified.
While PayPal’s mobile apps do not currently support 2FA-enabled accounts, it is possible to effectively trick the PayPal mobile applications into ignoring the 2FA flag on the account, subsequently allowing the an attacker to log in without requiring secondary authentication.
We developed a proof-of-concept exploit to leverage this lack of 2FA enforcement, interfacing with the PayPal API directly and effectively mimicking the PayPal mobile app as though it were accessing a non-2FA account. The exploit communicates with two separate PayPal API services -- one to authenticate (only with primary credentials), and another to transfer money to a destination account.
Note that the standard browser-based PayPal web interface is not affected by the bypass. However, since an attacker can simply use the underlying API to gain full account access, this distinction is purely academic.
Below is a brief video that that discusses and demonstrates the PayPal two-factor bypass:
Technical Details
The vulnerability lies primarily in the authentication flow for PayPal’s API web services. In particular, api.paypal.com, a REST-ful API which uses OAuth for authentication/authorization, does not directly enforce two-factor authentication requirements server-side when authenticating a user.
As demonstrated in the video, the PayPal iOS application exhibited suspicious behavior by briefly showing the user’s account information and transaction history prior to forcefully logging them out. Based on this behavior, we decided to investigate what was happening communications-wise on the wire. Using Burp, we intercepted and analyzed HTTP/HTTPS traffic between the PayPal mobile apps and remote PayPal web services. In particular, we observed the authentication process, paying close attention to how the service responded to 2FA-enabled accounts versus non-2FA-enabled accounts.
The screenshot below shows a POST request to an OAuth endpoint on api.paypal.com. The POST body contains, among other things, primary credentials (username & password) and some identifying data about the device. This sort of request (to the OAuth endpoint) was consistent with developer documentation on PayPal’s site, so it didn’t stand out as anything unusual.
However, in the screenshot below, which shows the response to the above request, we see a JSON dictionary that was returned containing some additional PayPal service URIs, various tokens (primarily OAuth-related), and some 2FA-related attributes.
Note the red highlight around the “2fa_enabled” attribute. As it turned out, the value of this attribute being set to “true” caused the mobile application to return to the login screen and display an error message, indicating that 2FA was not currently supported:
Similar HTTP requests were generated by the PayPal Android application, and the same error message was displayed for 2FA-enabled accounts:
Using Burp’s match-and-replace feature, we were able to automatically modify the server response to rewrite the “2fa_enabled” value to “false”:
By simply adjusting this value, the mobile clients would then proceed as normal, as though the account had no two-factor authentication whatsoever. Although the underlying vulnerability is present on the server-side, this tweak amounted to client-side “enforcement” of 2FA.
Returning to the initial response right after authentication occurs, we observed an additional session identifier being returned in the JSON dictionary, as highlighted below.
As it turned out, “session_token” is used for authorization against mobileclient.paypal.com, an otherwise (publicly) undocumented SOAP-based API that provides additional account-related functionality, including but not limited to sending money.
We then stepped through the “send money” process in the mobile apps, again capturing traffic with Burp. Through this, we were able to observe the necessary requests/responses and SOAP envelopes (read: painful XML) that make up a PayPal fund transfer from their mobile applications. The funds transfer process turned out to be a four-step exchange, with each request requiring a value unique to the overall transaction.
1password Paypal 2fa Code
As an example, the screenshot below shows the aforementioned session identifier being used in the first POST to mobileclient.paypal.com:
As a proof-of-concept, we built a Python script that ultimately mimicked the behavior of a PayPal mobile application and exploited this vulnerability. This script would take in a PayPal username and password, a dollar (USD) amount, and a recipient. The script would then:
- Authenticate to api.paypal.com
- Display some limited account information (including the “wallet,” or linked fund sources, such as bank accounts and debit/credit cards)
- Read the “session_token” value
- Use “session_token” to authenticate to mobileclient.paypal.com and proceed with the steps to initiate and complete sending funds to the target recipient
As shown in the demonstration video, this was done with a 2FA-enabled account, with zero 2FA challenge/enforcement from the server. The screenshot below shows our proof-of-concept script authenticating with a 2FA-enabled account and sending $1.00 USD to a recipient. (Additionally, a UUID is generated and placed in the note/memo of the transaction for correlation purposes).
The screenshot below shows the notification email sent to the recipient:
As of re-testing on June 23, PayPal has implemented a workaround for the vulnerability, with a permanent fix planned for July 28. Currently, 2FA-enabled accounts authenticating against api.paypal.com no longer receive the “session_token” key in the JSON response, effectively restricting access to mobileclient.paypal.com (non-2FA accounts still get the token).
However, wallet information was still being returned, meaning the 2FA-bypass was still partially valid, though an attacker is limited in their capability. The screenshot below shows the output of our PoC script when re-testing, highlighting the 2FA flag, and displaying wallet information (note the absence of the “session_token” key in the response):
Using official PayPal mobile apps, we also see more descriptive error information returned, reflecting the change in the authentication flow of PayPal’s API services, as shown below:
As of re-testing once again on June 24, PayPal implemented additional mitigations, completely restricting the user's wallet information from being returned. The screenshot below shows the output of our PoC script when re-testing on June 24. The absence of the 'access_token' key seems to restrict any subsequent operations on api.paypal.com, including accessing wallet data.
Conclusion
While two-factor authentication, when done right, provides great value for protecting users and businesses, design and implementation flaws such as this bypass can negate that value. Users may be lulled into a false sense of security, unaware that a security feature isn’t truly living up to its promise. With the sheer number of primary credentials being compromised and dumped onto the Internet, strengthening account security with a well-designed two-factor authentication solution is paramount.
We hope that PayPal’s planned fix will rectify this vulnerability and lead to full support of two-factor authentication in their official mobile applications and third-party merchant apps.
1password Add 2fa
Timeline
2014-03-28: Dan Saltman (EverydayCarry.com) discovers a two-factor bypass in the PayPal mobile application for iOS -- toggling airplane mode after supplying only primary credentials (for two-factor enabled account) causes the application to remain logged in
2014-03-29: Dan reports the issue to PayPal via their Bug Bounty program. The case is assigned as EIBBP-27440.
2014-04-10: Dan requests a status update from PayPal; no response
2014-04-22: Dan contacts Duo Security for assistance in validating/reproducing the issue and leveraging any contacts at PayPal to make progress on the case.
2014-04-22: Duo successfully reproduces Dan’s iOS-specific findings.
2014-04-23: Duo reaches out to a contact at PayPal, citing Dan’s case number; inquiry is forwarded to the eBay/PayPal Bug Bounty team.
2014-04-23: Duo also reproduces the 2FA bypass in the PayPal mobile app for Android.
2014-04-25: Duo receives a response from the Bug Bounty team via eBay’s web-based Secured Email system, indicating that the case is still under investigation.
2014-04-25: Dan receives an automated e-mail from PayPal’s bug tracker showing the issue as “in progress”.
2014-04-28: Duo again reaches out to the Bug Bounty team, offering to share supporting data (proxy logs, mobile application logs, screen recordings, etc.), as well as information about the Android-centric bypass.
2014-04:28 The Bug Bounty team replies indicating that they are unable to provide case information to anyone other than the original reporter.
2014-05-15: Duo opens a new case through the eBay/PayPal bug bounty site. The submission cites the iOS-related case, provides an overview of the underlying/bigger issue, and includes screenshots of the proof-of-concept exploit. The case is assigned as EIBBP-28093.
2014-05-22: Duo contacts the Bug Bounty team requesting a status update; no response.
2014-05-29: Duo once again contacts the Bug Bounty team requesting a status update.
2014-05-29: The Bug Bounty team replies indicating that they had attempted to request more information on May 22, as the screenshots were truncated during upload. (For unknown reasons, this message was not received by Duo, perhaps due to an error in the eBay Secured Email system.)
2014-05-29: Duo re-sends the screenshots.
2014-05-29: The Bug Bounty replies requesting a copy of the proof-of-concept exploit script.
2014-05-29: Duo sends the proof-of-concept script to the Bug Bounty team.
2014-06-03: Duo sends another status inquiry to the bug bounty team.
2014-06-03: The Bug Bounty team replies with additional case information, and indicates the submission is eligible for a bounty.
2014-06-09: Duo inquires to the Bug Bounty team about a fix timeline.
2014-06-09: Duo notifies contact at PayPal, setting a public disclosure date of June 25.
2014-06-10: PayPal contact replies to Duo and includes a Bug Bounty program manager on the same email thread.
2014-06-10: Duo acknowledges the reply, offers to answer any questions or concerns.
2014-06-10: Bug Bounty program manager replies, indicating that development teams are still reviewing the bugs that have been submitted to determine fix windows.
2014-06-16: An initial bounty payment is sent to Duo via PayPal.
2014-06-16: Duo replies to the Bug Bounty program manager acknowledging the initial payment and reminding them of the intent to disclose on June 25.
2014-06-16: The Bug Bounty program manager replies indicating that development teams are working on a fix but are unable to commit to any particular timeline.
2014-06-18: Duo replies to the Bug Bounty program manager re-stating the intent to disclose on June 25. Duo also re-tests the issue, noting that PayPal has implemented a partial workaround which limits the attack.
2014-06-19: PayPal contact (including Bug Bounty program manager) replies, noting a targeted fix date of July 28, along with a request for Duo to delay public disclosure.
2014-06-20: Duo replies, again re-stating the intent to disclose on June 25.
2014-06-24: PayPal notifies Duo that additional mitigations have been put in place which no longer allow for retrieval of user's wallet data, further limiting the attack.
2014-06-24: Duo acknowledges the update/notification from PayPal and re-tests the issue. Duo notes that while the core bypass issue remains, interaction with the API is no longer possible, including no longer being able to access wallet data.
2014-06-25: Vulnerability write-up is shared publicly and posted to the Duo Security blog.