We have confirmed that a copy of certain user account information was stolen from the company’s network in late 2014 in what we believe is a state-sponsored actor. The account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (the vast majority with bcrypt) and, in some cases, encrypted or unencrypted security questions and answers. The ongoing investigation suggests that stolen information did not include unprotected passwords, payment card data, or bank account information; payment card data and bank account information are not stored in the system that the investigation has found to be affected. Based on the ongoing investigation, Yahoo believes that information associated with at least 500 million user accounts was stolen and the investigation has found no evidence that the state-sponsored actor is currently in Yahoo’s network. Yahoo is working closely with law enforcement on this matter.
We are taking action to protect our users:
We are notifying potentially affected users. The content of the email Yahoo is sending to those users will be available at https://yahoo.com/security-notice-content beginning at 11:30 am (PDT).
We are asking potentially affected users to promptly change their passwords and adopt alternate means of account verification.
We invalidated unencrypted security questions and answers so they cannot be used to access an account.
We are recommending that all users who haven’t changed their passwords since 2014 do so.
We continue to enhance our systems that detect and prevent unauthorized access to user accounts.
We are working closely with law enforcement on this matter.
Change your password and security questions and answers for any other accounts on which you used the same or similar information used for your Yahoo account.
Review your accounts for suspicious activity.
Be cautious of any unsolicited communications that ask for your personal information or refer you to a web page asking for personal information.
Avoid clicking on links or downloading attachments from suspicious emails.
Additionally, please consider using Yahoo Account Key, a simple authentication tool that eliminates the need to use a password altogether.
An increasingly connected world has come with increasingly sophisticated threats. Industry, government and users are constantly in the crosshairs of adversaries. Through strategic proactive detection initiatives and active response to unauthorized access of accounts, Yahoo will continue to strive to stay ahead of these ever-evolving online threats and to keep our users and our platforms secure.
For more information about this issue and our security resources, please visit the Yahoo Security Issue FAQs page, https://yahoo.com/security-update, which will be up beginning at 12pm (PDT).
Statements in this press release regarding the findings of Yahoo’s ongoing investigation involve potential risks and uncertainties. The final conclusions of the investigation may differ from the findings to date due to various factors including, but not limited to, the discovery of new or additional information and other developments that may arise during the course of the investigation. More information about potential risks and uncertainties of security breaches that could affect the Company’s business and financial results is included under the caption “Risk Factors” in the Company’s Quarterly Report on Form 10-Q for the quarter ended June 30, 2016, which is on file with the SEC and available on the SEC’s website at http://www.sec.gov./
By Katie Shay, Legal Counsel, Business & Human Rights
Twelve security trainers, tool developers and human rights activists from four continents came to our headquarters in Sunnyvale, California. Their mission? To share their unique perspectives with our Yahoo products, engineering, security, public policy and legal teams. Yahoo’s Business & Human Rights Program, the Paranoids and Yahoo for Good orchestrated this ‘hack of the minds’ in partnership with Internews and the USABLE Project.
USABLE Project’s aim is to inform the development of security tools that are easy to use and simple to understand for users from diverse backgrounds and skill levels. Their goal is to support vulnerable populations around the world who use the internet for more than just sharing pictures of cats or Venmoing a friend for lunch. In many cases, these users rely on the internet to exercise their right to free expression, expose corruption or fight against injustice in their communities. For these users, the ability to be secure online is critical.
In July, Yahoo was proud to sponsor the USABLE Project’s first ever public forum, UX in a High Risk World in San Francisco, bringing together frontline digital security practitioners, users, tool developers and UX experts from around the world. In addition, Yahoo participated in the final day of USABLE’s four-day closed-door workshop leading up to this event, working directly with this community to build concrete, actionable roadmaps to improve usability in security tools.
Following the forum, the delegation from USABLE that visited Yahoo shared their on-the-ground perspective on why remaining secure online is so important to their work. They explained how they use Yahoo products, including Flickr and Mail, why it’s important to have a principled approach to responding to government requests for user data and content moderation, as well as the importance of baking in security features to products from the outset by turning them on by default. These visionary leaders are working toward solutions for activists facing censorship, hacking, surveillance and suppression in some of the world’s most challenging environments.
During the delegation’s visit, our Yahoo teams asked pointed questions to understand the experience of some of our most vulnerable users and to explore how their experiences might inform Yahoo’s product development and online security work.
We are grateful to the USABLE team for sharing their stories with us, and for inspiring our teams to continue to find new and innovative ways to put our users first!
Recent headlines might lead you to believe that when a company runs a red team exercise that the red team should fail. After all, the company has invested in security teams, products and processes. So the outcome should be a win for the blue team and a failure for the red team. (For those of you who are lost already, a red team is an independent group within a company’s security organization that challenges the effectiveness of its security defenses. The red team performs analysis of systems and process gaps. Then it attacks you, hopefully before a real adversary does.) Let’s set the record straight on this critical aspect of modern security programs.
The red team always wins. Always.
It can be humiliating. And the timing is rarely convenient. Friday late night or on Christmas morning? Fair game.
The red team adopts the tools and techniques of actual adversaries. They use their understanding of attacks on other organizations that have been made public. They mimic the work of adversaries that the blue team has caught. They do not fight fair, nor will your adversaries.
Most companies prepare their defenses around best practices and compliance. Those alone will not get you very far. Even the organizations that use threat models and attack chains (i.e. the common events in an attack) need to practice. Practice. Measure. Learn. Repeat.
Most companies think they have a security plan. One of the great philosophers of our time, Mike Tyson, once remarked “Everybody has a plan until they get punched in the mouth.” Will your muscle memory kick in after getting hit? Or will you be stunned? Companies that engage in continuous red/blue battles are far more likely to detect and survive real attacks.
Having a security program without a red team is like practicing martial arts in the mirror rather than with a worthy sparring partner.
A red team exercise should not be an annual activity. It should represent a continuous clear and present danger. An employee, for example, may (incorrectly) doubt that they are the target of state-sponsored actors. They might think “Why should I close these minor gaps? It’s not like anyone would use these vulnerabilities against us!” They can, however, be sure that their red team is actively targeting them. Continuous red team exercises, over time, will give the blue team a fighting chance.
After the red team attack, what do you do? Do you “fix the glitch”? Or do you take time in the post-mortem to find the root cause and to fix it? More mature organizations will revisit the gaps over time. They provide input into the next planning cycle. Lessons learned from red team exercises contribute to a stronger defense and a better chance of stopping the real adversaries.
The real scandal is not that a red team won (the red team always wins!), but that many companies do not have red teams. Reporters: want a great story? Ask every CISO you talk to if they have a full-time, dedicated red team. Prepare yourself to hear some spin.
Unacceptable answers:
We are not the target of sophisticated adversaries.
We already know we have a lot of work to do so adding a red team report isn’t going to help.
We work in a highly regulated industry so it’s not necessary.
We have not had a breach in years.
Our attack surface is small.
Our IT team is great and we do a good job of user training.
Yahoo has its own internal red team known as Offensive Engineering (yes, that can be read two ways!). Their job is to take a contrarian view of Yahoo systems. They don’t care what the code was designed to do. They care about what it actually does. And yes, this red team always wins. Always. It’s what we pay them to do.
Let’s stop talking about red team wins as if they are a bad thing and let’s start talking about the red vs blue feedback loop: Practice. Measure. Learn. Repeat.
In our inaugural post to The Paranoid, we discussed the human element behind online attacks–the human adversary. We sought to give some perspectives as to who is behind online threats in order to better understand how to defend against them. Yahoo’s bug bounty program applies that insight in our ongoing efforts to provide a safe environment for our users. By thinking about the economics of security, we’ve found that we can tilt the advantage in our favor by partnering with industry-leading security researchers.
We often get questions from both security researchers, and people just interested in learning about how programs like these work. We thought we’d use this opportunity to take a quick look under the hood.
First, some background. Bug bounty programs essentially crowd-source security. They allow companies to improve coverage so they are able to add additional eyes where they need them. Bug bounty researchers also bring depth of expertise and different skill sets that can uncover hard to find bugs.
For the past two years, Yahoo has developed one of the largest and most successful bug bounty programs in the industry. We’ve paid out over $1.7 million dollars in bounties, resolved more than 2,000 security bugs and maintain a “hackership” of more than 2,000 researchers, some of whom make careers out of it.
Security researchers often ask us how we decide the payout associated with a given bug report. At first it might seem logical that we pay based on the type or classification of a security bug. Some bug types tend to be bad, so you might think that they would be paid the same. However, in the vast majority of cases, that’s not the complete story. So if the bug type alone is not what we use to determine the payout, what is? The missing input to the calculation is the impact of the vulnerability. We take into account what data might have been exposed, the sensitivity of that data, the role that data plays, network location and the permissions of the server involved. Those factors are of great importance.
Given the importance of the impact of a bug, the Yahoo bug bounty program does not reward researchers solely based on bug type. The type of bug a security researcher finds is mostly irrelevant. It’s what the bug allows them to do and where that are most important. What can an attacker actually do with this specific bug to potentially affect the security of Yahoo or our users? Furthermore, Yahoo’s application landscape is not necessarily uniform; certain properties or applications are more equal than others.
Here’s an example to show how these factors work in practice. SQL injection bugs are often a devastating bug class because they can provide full access to a database. Odds are, if a company has a presence on the web, they are storing sensitive information in databases. But just because an attacker can access the database does not mean it’s game over. The real reason that the SQL injection bug class can be so devastating is the data stored in the database may be accessed or changed by unauthorized parties. The typical impact of a SQL injection bug is high because the data exposed is typically sensitive, except when it’s not. What if the database doesn’t contain any sensitive data?
Part of the process in determining impact can seem opaque to the researcher, and we understand that. That obscurity is an unfortunate but necessary fact of life in a bug bounty program. As an external party, it is just not possible to have all the information. The sort of testing available to participants in a public bug bounty program is inherently “black box”–no documentation, no source code, what you see is what you get.
So we encourage bug reporters to include in their reports what they believe the impact of the vulnerability to be (example report here). Submitting a report that contains a thorough and detailed explanation of a legitimate security issue is much more highly valued and rewarded.
We also work closely with the developers to ensure the bug is fixed in a timely manner, and to obtain their expert opinion on impact if necessary. If the developers that created the application tell us that no sensitive data is stored in a particular database, we take that into consideration when awarding your bug. More detailed guidelines for our bug bounty program are available at hackerone.com/yahoo.
To paraphrase a little-known quote, “bug bounty programs don’t reward you for being clever.” Users and researchers should know that we place far more weight on how impactful bugs are to our platforms.
If the countless data breaches we read about in the news have confirmed anything, it’s that online security is somewhat of a moving target. We’ve witnessed compromised security at one point or another across every industry and government. From health records and email to financial information, intellectual property and critical infrastructure, it would seem nothing is secure these days.
Yet, despite being armed with this fundamental understanding of online security, it’s often treated as a static challenge–as if there is one solution for one vulnerability. In an inherently insecure world with ever changing threats, our conventional wisdom must evolve just as online threats do.
The obvious next question is how, and that’s a good question to ask with a plethora of answers. But in order to understand how we adapt to emerging threats, it’s first and foremost critical to understand the dynamics behind the threats themselves. Why are the threats changing and what allows them to continue to be successful?
In fact, the next best question to ask is who is behind today’s online threats. The most important aspect of online security that we can internalize is that we are up against dedicated, human adversaries who organize their activities into campaigns.
They are dedicated, which means they have a job to do, or a calling. They’re going to keep coming back until they achieve their goals. Maybe they work for a criminal syndicate, or for a foreign military. Or maybe they are on a mission from God.
They are also human, which means they can be creative and resourceful. They are like water in a cracked vase. It will find a way to seep out. They spend time learning your internal processes and reading your internal documentation before acting.
And finally, they work in campaigns. The data they seek from a system may not be valuable by itself. It may be that the data is valuable because it provides information about human rights activists in their own country. Or because they want to know what their political opponents are doing. They are likely targeting other services of peers and competitors. The data they collect is only valuable to the extent the campaign objectives are known.
Our activities as defenders, whether the casual user to the chief information security officer, need to line up against these characteristics of our adversaries. Are we considering how a phone call from an unfamiliar number but a familiar voice might be part of a social engineering scheme? Are we employing security tactics that eliminate an attack instead of letting it shift to a new vector?
Until we start thinking about online adversaries this way, we’ll continue to find ourselves playing whack-a-mole without ever turning the tide.
This is the first edition of our new Yahoo Tumblr series–The Paranoid–where we will delve into the security space and share how we’re working to protect our users, as well as useful tips for users to consider as they go about their everyday lives online. Like all good security researchers, we will look at security issues from the viewpoint of an adversary. Our goals with this series are to break conventional wisdom, ask tough questions about how we approach online security, and ultimately allow our users to hold us to a higher standard. Most importantly, we want to start a conversation to ultimately improve the safety and security of our users and our network.
We
put our users’ security first at Yahoo, and today we’re proud to
highlight one way in which we’re protecting our users against evolving
online threats through our bug bounty program. Partnering with HackerOne,
Yahoo’s bug bounty program has grown dramatically since our launch
about two years ago. Our bug bounty program boasts more than 2,000
security researchers and we’ve awarded $1.6 million in the last two
years. Our security team, known as the Paranoids, work night and day to
secure our users, but, with an online property as large as Yahoo, having
as many eyes as possible focused on the security of our users
crowd-sources what would otherwise be an impossible task for the
resources of a few.
Learn more about our growing bug bounty program here.
We recently learned that a third party had obtained access to a set of Tumblr user email addresses with salted and hashed passwords from early 2013, prior to the acquisition of Tumblr by Yahoo. As soon as we became aware of this, our security team thoroughly investigated the matter. Our analysis gives us no reason to believe that this information was used to access Tumblr accounts. As a precaution, however, we will be requiring affected Tumblr users to set a new password.
For additional information on keeping your accounts secure, please visit our Account Security page.
Recent years have witnessed exciting progress in the development of cryptographic techniques enabling new functionalities and ways of interaction, such as fully homomorphic encryption, program obfuscation, and verifiable outsourcing of computation. The second Bay Area Crypto Day workshop, for Bay Area researchers to present and discuss the latest developments in the theory of crypto, will take place at Stanford University on Monday, May 2. The workshop’s program and other relevant information can be found here. Yahoo Research is proud to co-organized the event along with Stanford University and UC Berkeley.
By Binu Ramakrishnan, Security Engineer, Yahoo Mail
Summary
At Yahoo, our users send and receive billions of emails everyday. We work to make Yahoo Mail easy to use, personalized, and secure for our hundreds of millions of users around the world. In line with our efforts to protect our users’ data, our security team recently conducted a study to measure the deployment quality of SMTP STARTTLS deployments. We found that while the use of STARTTLS is common and widespread, the growth has slowed in recent years. Providers with good/valid certificates have better TLS settings compared to others, and we believe there is an important need to improve the quality of STARTTLS deployments to protect messages – and therefore, users – from active network attacks.
The Modern Mail Ecosystem
Simple Mail Transfer Protocol (SMTP) is the underlying protocol used for email transmission, especially when sending or receiving email between different providers. The SMTP protocol does not require encryption by default, and mail providers like Yahoo depend on the STARTTLS extension to encrypt messages in transit. Unfortunately, not all providers support STARTTLS when they send or receive emails, potentially exposing them to network eavesdropping.
The diagram below offers a simplified view of a modern mail ecosystem. Communication between service providers are over the SMTP protocol, and the providers use MTAs to send and receive messages to/from other providers. MTAs speak the SMTP protocol and use STARTTLS to encrypt the messages in transit. To send a message, the sender (MTA outbound) resolves a mail exchanger record (MX) for the recipient’s domain from DNS. The MX record contains the recipient’s (MTA inbound) server name. Once the recipient’s server name is resolved, the sender connects to that server and transmits messages.
Figure 1: A high level overview of a mail ecosystem
STARTTLS has received a lot of attention in recent years. Around half a dozen studies were published and presented in 2015 (see Appendix), all of which underscore the importance of securing mail delivery infrastructure against mass surveillance and network eavesdropping. Since mail is an open system, a collective industry wide effort is critical to secure our email communication.
What is STARTTLS ?
STARTTLS is an extension that enables opportunistic upgrades of plaintext communication to encrypted communication between STARTTLS aware client and server. The diagram below shows an SMTP session between a client and a server. When the server desires to receive emails over TLS, it returns 250 STARTTLS back to client in response to EHLO from client. If the client supports TLS, it may initiate a TLS handshake and once the TLS session is established, messages will be sent over an encrypted channel.
Figure 2: SMTP STARTTLS session between a client and a server
STARTTLS provides protection against passive attacks and, in fact, the opportunistic nature of STARTTLS drove widespread adoption of TLS in SMTP. At the same time, ‘opportunistic’ encryption also means that STARTTLS is not effective against MITM (active) attacks because of: (1) STARTTLS downgrade attacks - by stripping STARTTLS from an active SMTP session that forces messages to send over cleartext, and (2) the possibility of DNS MX spoof attacks in which a compromised name server returns a spoofed MX target host or IP address and diverts the traffic through the attacker’s mail server.
Methodology
For this study, we collected 12M unique domains from a 30 day period in January 2016 of mail outbound logs. Of the 12M domains we scanned, we gathered stats for 9M domains with 3.7M unique MX hosts and ~1M unique IP addresses. The data collected is aggregated and presented in multiple buckets – unique Domain, MX, IP etc. This data is also compared with a previous study (slides) we did in May 2015 (presented at M3AAWG 34th General Meeting in Dublin, Ireland). We scanned the domains with a fast TLS scanner written in Go and used Unix tools to analyze the data.
Caveats
The Go TLS implementation has limited cipher support: specifically, it does not support deprecated/insecure ciphers. It also does not have SSLv3 client side support. This study is based on domains we collected from Yahoo, and we considered only those domains with at least three or more emails sent during that period.
Findings
Our findings are grouped and presented in buckets based on:
Domains - Unique domains (9M)
MX - Unique MX hosts (3.7M)
IP - Unique IP addresses (1M)
Valid Cert - Unique MX with valid CA signed certificate (1.8M)
Strict validation - Valid cert with a matching host name (peer verify) (626K)
Note that these 9M domains are hosted by 3.7M MX hosts which in turn map to 1M unique IP addresses. Many domains share the same MX and many MXs share the same IP.
STARTTLS Adoption
Around 80% of MXs we scanned support STARTTLS. When compared to a similar study we conducted last year, STARTTLS adoption rate was flat with no significant growth expected in the near future. Adoption rate in the case of the unique IP bucket is lower than the other two buckets.
Figure 3: STARTTLS adoption (*data from 2015)
TLS X.509 Certificates
Public Key Size
Public key size is the length of the RSA (or ECDSA) key used by the server. An RSA key size less than 2048 bits is considered weak, but we found that around 14% of MXs are still using weak 1024 bit RSA public keys. Interestingly, key sizes in the last two buckets were found to be more compliant than other buckets, which is expected considering that those hosts have valid CA signed certificates. We also observed five valid ECDSA certificates.
Figure 4: Public key size distribution chart
Signature Algorithm
Signature algorithm is the cryptographic hash algorithm used by certificate authorities to sign TLS certificates. SHA1 based certificates are deprecated and currently being phased out. We have observed a few RSA-SHA1 based certificates issued in 2015 but found no RSA-SHA1 certificates issued in 2016 (as of January 31, 2016). However, a significant number of these SHA1 certificates remain valid well beyond 2016, which is a concern. Almost all browser vendors (in the HTTPS world) decided to mark SHA1 signed certificates as ‘untrusted’ if they encounter them after January 1, 2017. When compared with data from 2015, we find a significant increase in SHA256-based certificates which is expected. You may also notice a small percentage of MD5 based certificates, especially in Domain, MX and IP buckets. Note that almost all are either expired or self-signed.
Figure 5: Signature algorithm distribution chart
Certificate Validation
This chart presents the certificates distribution in three groups: (1) Untrusted, (2) ValidCert, and (3) StrictValidCert. The ValidCert group represents certificates that chain to a trusted root CA and the StrictValidCert is the grouping of valid certificates with peer verified. Note that peer verification is against the MX hostname, not to the email domain. The unique domain bucket has more valid and strict-valid certificates than the other two buckets with more than 50% certificates that are peer-verified. This was largely because the large mail service providers that host millions of third party domains mostly use valid certificates for STARTTLS. In the case of unique IP category, we find a large percentage of untrusted certificates.
Figure 6: Certificate validation
Certificate Validation - Error-type Distribution
This chart shows the distribution of certificate validation error types. Hostname mismatch (PeerVerifyFailed) is more prevalent than self-signed/expired certificates in the domain and MX buckets. This was largely because the large hosted email providers prefer to use CA signed certificates over self-signed certificates. Interestingly, even the large mail providers grapple with hostname mismatch. Self-signed and expired certificates are more prevalent within the IP bucket.
Figure 7: Certificate validation error-type distribution
Certificate Chain Depth
Chain depth of zero mainly represents self-signed certificates (in red) and is more prevalent in the first three buckets. However, for valid and strict-certs buckets, the chain depth is either two or three, which is expected.
Figure 8: X509 certificate chain depth distribution
TLS Session
TLS Protocol Version
TLS version 1.2 usage increased since last year. The usage is higher in verified and strict-certs buckets. TLS1.1 usage is not statistically significant.
Figure 9: TLS protocol version
Negotiated Ciphers
The data presented in this chart may not be 100% accurate, as our scanner is written in Go and the Go TLS implementation has limited cipher support. In particular, the Go TLS implementation does not support deprecated/insecure ciphers and DHE cipher suites, nor does it have SSLv3 client side support.
Figure 10: TLS session cipher distribution
Deployment Quality - Focus areas for email service providers
Though STARTTLS protects against passive network eavesdropping, it is not effective against active MITM attacks in its current form. An industry-wide effort is underway to strengthen the mail delivery infrastructure and the end goal is to protect against active MITM attacks, thereby upholding users’ privacy. Below are a few recommendations that can greatly improve STARTTLS deployment quality. While these steps alone cannot protect against active attacks, by implementing these changes, mail providers can meet the baseline requirements to fight against pervasive monitoring attacks and increase the difficulty of active attacks.
Server side
Eliminate self-signed and expired certificates. There are a few certificate authorities that provide certificates free of cost, including Let’s Encrypt. Let’s Encrypt is a new certificate authority that provides free TLS certificates with the ability to automate certificate refresh, which solves the cert expiration issue. DNS-based Authentication of Named Entities (DANE) is an alternate way to authenticate STARTTLS server entities without a certificate authority. DANE relies on Domain Name System Security Extensions (DNSSEC) for security, but the challenge is that DNSSEC is not widely deployed and its adoption rate remains low. DANE does not require certificates issued by certificate authorities.
Upgrade valid certificates to conform to strict validation (peer verify). Operators must make sure their certificates are not only valid, but also match their hostname. We observed a large number of valid certificates with hostname mismatches, some of which were from large mail providers.
Replace SHA1 based certificates with SHA256 based certificates. The SHA1 cryptographic hash algorithm is considered weak and the industry recommendation is to transition from SHA1 signed certificates to SHA256 signed certificates as early as possible.
Strict certificate validation. Validate MX certificates and verify them by matching the hostname of the server with the name in the certificate presented by the server. A soft validation is recommended initially, which is useful for Log and monitoring (see below).
Log & monitoring. Data related to validation failures when connecting to a recipient server help to detect active network attacks. Log events such as STARTTLS=false, MX mismatches, and cert validation failures for this purpose.
Keep up to date with root CA certificates bundle. SMTP clients, unlike browsers, have no standard mechanism to update CA bundles. In recent years, Microsoft and Mozilla pruned their CA bundle and removed many old root certificates. Our recommendation is to keep your root CA bundles up to date, irrespective of which root CA bundle you trust.
Certificate revocation support (CRL, OCSP, OCSP stapling). Considering the opportunistic nature of current SMTP deployments, until now there was no compelling reason to check whether the certificates presented by servers are revoked or not. But this feature may become more important in coming years.
Recommendations
The use of STARTTLS is common and widespread; however, its growth has slowed in recent years. Through our study, we found that providers with good/valid certificates have better TLS settings compared to others. There is an important and fundamental need to improve the quality of STARTTLS deployment in order to protect messages – and therefore, users – from active network attacks. As a baseline requirement, email providers should work to eliminate self-signed, expired certificates and use good ciphers with PFS on SMTP servers. Senders should validate the certificates and log validation failures, as the failure logs can provide valuable insights and use it for reporting.
Acknowledgments: We want to thank Mike Shema, Elizabeth Zwicky, Suzanne Philion, and colleagues from Yahoo Mail Delivery and Paranoids teams for their support and contribution to this work.
Passwords can be a hassle - they’re easy to lose track of and forget, or they are weak passwords that are vulnerable to hacking. At Yahoo, we are moving fast in our mission to “kill the password” and make it easier for users to sign in without sacrificing security.
With Yahoo Account Key, you can easily and securely sign in to your Yahoo account using your mobile phone. Whether you use Yahoo Finance, Fantasy, Mail, Messenger, and Sports for iOS or Android, each time you sign in, you will receive a push notification on your mobile phone for you to approve. Once you tap it, you’ll be signed in immediately. It’s secure, and there’s no need to remember a difficult password. Read on for how to set up Account Key.
How to set up Account Key First, make sure you are signed into a Yahoo mobile app, then click here to set up Account Key. Or, you can follow the steps below.
In the Yahoo Mail app:
On Android, tap the top left menu icon. On iPhone, tap the profile icon in the top right of the navigation bar.
Tap the key icon next to your account
Tap Set up Account Key and follow the steps
In Yahoo Sports, Finance or other Yahoo apps:
Tap the top left menu icon
On Android, tap the key icon next to your account. On iPhone, select Account Key from the list (under the Tools section).
Tap Set up Account Key and follow the steps
And now you’re ready to go! Next time you sign in from your desktop, we will send you a push notification to your mobile app. Simply open it and tap “Yes” to approve and sign in. Make sure not to sign out of your app or turn off notifications, as this will prevent you from receiving your Account Key push notification.
