Info taken from http://www.bbc.co.uk/news/technology-26971363

But in summary theses are the “current” findings :-

Name Vulnerable? Patched? Change password?
Amazon No No need Only if shared with vulnerable service
Amazon Web Services Yes Yes Yes
Apple Not clear Not clear Not clear
Barclays No No Only if shared with vulnerable service
eBay No No need Only if shared with vulnerable service
Evernote No No need Only if shared with vulnerable service
Facebook Yes Yes Yes
Google/Gmail Yes Yes Yes
HSBC No No need Only if shared with vulnerable service
If This Then That Yes Yes Will force users to log out and ask them to update
LinkedIn No No need Only if shared with vulnerable service
Lloyds No No need No
Microsoft/Hotmail/Outlook No No need Only if shared with vulnerable service
PayPal No No need Only if shared with vulnerable service
RBS/Natwest No No need Only if shared with vulnerable service
Santander No No need Only if shared with vulnerable service
Tumblr Yes Yes Yes
Twitter No No need Only if shared with vulnerable service
Yahoo/Yahoo Mail Yes Yes Yes

 

More info on Heartbleed –> taken from http://heartbleed.com

The Heartbleed Bug

Heartbleed Bug

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

What leaks in practice?

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

How to stop the leak?

As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.


Q&A

What is the CVE-2014-0160?

CVE-2014-0160 is the official reference to this bug. CVE (Common Vulnerabilities and Exposures) is the Standard for Information Security Vulnerability Names maintained by MITRE. Due to co-incident discovery a duplicate CVE, CVE-2014-0346, which was assigned to us, should not be used, since others independently went public with the CVE-2014-0160 identifier.

Why it is called the Heartbleed Bug?

Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.

What makes the Heartbleed Bug unique?

Bugs in single software or library come and go and are fixed by new versions. However this bug has left large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation and attacks leaving no trace this exposure should be taken seriously.

Is this a design flaw in SSL/TLS protocol specification?

No. This is implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services.

What is being leaked?

Encryption is used to protect secrets that may harm your privacy or security if they leak. In order to coordinate recovery from this bug we have classified the compromised secrets to four categories: 1) primary key material, 2) secondary key material and 3) protected content and 4) collateral.

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

Recovery sounds laborious, is there a short cut?

After seeing what we saw by “attacking” ourselves, with ease, we decided to take this very seriously. We have gone laboriously through patching our own critical services and are in progress of dealing with possible compromise of our primary and secondary key material. All this just in case we were not first ones to discover this and this could have been exploited in the wild already.

How revocation and reissuing of certificates works in practice?

If you are a service provider you have signed your certificates with a Certificate Authority (CA). You need to check your CA how compromised keys can be revoked and new certificate reissued for the new keys. Some CAs do this for free, some may take a fee.

Am I affected by the bug?

You are likely to be affected either directly or indirectly. OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL. Many of online services use TLS to both to identify themselves to you and to protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.

How widespread is this?

Most notable software using OpenSSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according to Netcraft’s April 2014 Web Server Survey. Furthermore OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.

What versions of the OpenSSL are affected?

Status of different versions:

  • OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
  • OpenSSL 1.0.1g is NOT vulnerable
  • OpenSSL 1.0.0 branch is NOT vulnerable
  • OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.

How common are the vulnerable OpenSSL versions?

The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST).

How about operating systems?

Some operating system distributions that have shipped with potentially vulnerable OpenSSL version:

  • Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
  • Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
  • CentOS 6.5, OpenSSL 1.0.1e-15
  • Fedora 18, OpenSSL 1.0.1e-4
  • OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
  • FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
  • NetBSD 5.0.2 (OpenSSL 1.0.1e)
  • OpenSUSE 12.2 (OpenSSL 1.0.1c)

Operating system distribution with versions that are not vulnerable:

  • Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14
  • SUSE Linux Enterprise Server
  • FreeBSD 8.4 – OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD 9.2 – OpenSSL 0.9.8y 5 Feb 2013
  • FreeBSD 10.0p1 – OpenSSL 1.0.1g (At 8 Apr 18:27:46 2014 UTC)
  • FreeBSD Ports – OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

How can OpenSSL be fixed?

Even though the actual code fix may appear trivial, OpenSSL team is the expert in fixing it properly so latest fixed version 1.0.1g or newer should be used. If this is not possible software developers can recompile OpenSSL with the handshake removed from the code by compile time option -DOPENSSL_NO_HEARTBEATS.

Should heartbeat be removed to aid in detection of vulnerable services?

Recovery from this bug could benefit if the new version of the OpenSSL would both fix the bug and disable heartbeat temporarily until some future version. It appears that majority if not almost all TLS implementations that respond to the heartbeat request today are vulnerable versions of OpenSSL. If only vulnerable versions of OpenSSL would continue to respond to the heartbeat for next few months then large scale coordinated response to reach owners of vulnerable services would become more feasible.

Can I detect if someone has exploited this against me?

Exploitation of this bug leaves no traces of anything abnormal happening to the logs.

Can IDS/IPS detect or block this attack?

Although the content of the heartbeat request is encrypted it has its own record type in the protocol. This should allow intrusion detection and prevention systems (IDS/IPS) to be trained to detect use of the heartbeat request. Due to encryption differentiating between legitimate use and attack can not be based on the content of the request, but the attack may be detected by comparing the size of the request against the size of the reply. This seems to imply that IDS/IPS can be programmed to detect the attack but not to block it unless heartbeat requests are blocked altogether.

Has this been abused in the wild?

We don’t know. Security community should deploy TLS/DTLS honeypots that entrap attackers and to alert about exploitation attempts.

Can attacker access only 64k of the memory?

There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.

Is this a MITM bug like Apple’s goto fail bug was?

No this doesn’t require a man in the middle attack (MITM). Attacker can directly contact the vulnerable service or attack any user connecting to a malicious service. However in addition to direct threat the theft of the key material allows man in the middle attackers to impersonate compromised services.

Does TLS client certificate authentication mitigate this?

No, heartbeat request can be sent and is replied to during the handshake phase of the protocol. This occurs prior to client certificate authentication.

Does OpenSSL’s FIPS mode mitigate this?

No, OpenSSL Federal Information Processing Standard (FIPS) mode has no effect on the vulnerable heartbeat functionality.

Does Perfect Forward Secrecy (PFS) mitigate this?

Use of Perfect Forward Secrecy (PFS), which is unfortunately rare but powerful, should protect past communications from retrospective decryption. Please seehttps://twitter.com/ivanristic/status/453280081897467905 how leaked tickets may affect this.

Can heartbeat extension be disabled during the TLS handshake?

No, vulnerable heartbeat extension code is activated regardless of the results of the handshake phase negotiations. Only way to protect yourself is to upgrade to fixed version of OpenSSL or to recompile OpenSSL with the handshake removed from the code.

Who found the Heartbleed Bug?

This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomiconand Neel Mehta of Google Security, who first reported it to the OpenSSL team. Codenomicon team found heartbleed bug while improving the SafeGuard feature in Codenomicon’s Defensics security testing tools and reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team.

What is the Defensics SafeGuard?

The SafeGuard feature of the Codenomicon’s Defensics security testtools automatically tests the target system for weaknesses that compromise the integrity, privacy or safety. The SafeGuard is systematic solution to expose failed cryptographic certificate checks, privacy leaks or authentication bypass weaknesses that have exposed the Internet users to man in the middle attacks and eavesdropping. In addition to the Heartbleed bug the new Defensics TLS Safeguard feature can detect for instance the exploitable security flaw in widely used GnuTLS open source software implementing SSL/TLS functionality and the “goto fail;” bug in Apple’s TLS/SSL implementation that was patched in February 2014.

Who coordinates response to this vulnerability?

NCSC-FI took up the task of reaching out to the authors of OpenSSL, software, operating system and appliance vendors, which were potentially affected. However, this vulnerability was found and details released independently by others before this work was completed. Vendors should be notifying their users and service providers. Internet service providers should be notifying their end users where and when potential action is required.

Is there a bright side to all this?

For those service providers who are affected this is a good opportunity to upgrade security strength of the secret keys used. A lot of software gets updates which otherwise would have not been urgent. Although this is painful for the security community, we can rest assured that infrastructure of the cyber criminals and their secrets have been exposed as well.

Where to find more information?

This Q&A was published as a follow-up to the OpenSSL advisory, since this vulnerability became public on 7th of April 2014. The OpenSSL project has made a statement athttps://www.openssl.org/news/secadv_20140407.txt. NCSC-FI published an advisory athttps://www.cert.fi/en/reports/2014/vulnerability788210.html. Individual vendors of operating system distributions, affected owners of Internet services, software packages and appliance vendors may issue their own advisories.

References

Heartbleed logo is free to use, rights waived via CC0[download logo in SVG format]

Page updated 2014-04-11 14:20 UTC.

 UPDATED INFO — TAKEN FROM http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/

Social Networks

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Facebook Unclear Yes YesYes “We added protections for Facebook’s implementation of OpenSSL before this issue was publicly disclosed. We haven’t detected any signs of suspicious account activity, but we encourage people to … set up a unique password.”
Instagram Yes Yes YesYes “Our security teams worked quickly on a fix and we have no evidence of any accounts being harmed. But because this event impacted many services across the web, we recommend you update your password on Instagram and other sites, particularly if you use the same password on multiple sites.”
LinkedIn No No No “We didn’t use the offending implementation of OpenSSL in www.linkedin.com or www.slideshare.net. As a result, HeartBleed does not present a risk to these web properties.”
Pinterest Yes Yes YesYes “We fixed the issue on Pinterest.com, and didn’t find any evidence of mischief. To be extra careful, we e-mailed Pinners who may have been impacted, and encouraged them to change their passwords.”
Tumblr Yes Yes YesYes “We have no evidence of any breach and, like most networks, our team took immediate action to fix the issue.”
Twitter No Yes Unclear Twitter wrote that OpenSSL “is widely used across the internet and at Twitter. We were able to determine that [our] servers were not affected by this vulnerability. We are continuing to monitor the situation.” While reiterating that they were unaffected, Twitter told Mashable that they did apply a patch.

Other Companies

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Apple No No No “iOS and OS X never incorporated the vulnerable software and key web-based services were not affected.”
Amazon No No No “Amazon.com is not affected.”
Google Yes Yes YesYes* “We have assessed the SSL vulnerability and applied patches to key Google services.” Search, Gmail, YouTube, Wallet, Play, Apps and App Engine were affected; Google Chrome and Chrome OS were not.

*Google said users do not need to change their passwords, but because of the previous vulnerability, better safe than sorry.

Microsoft No No No Microsoft services were not running OpenSSL, according to LastPass.
Yahoo Yes Yes YesYes “As soon as we became aware of the issue, we began working to fix it… and we are working to implement the fix across the rest of our sites right now.” Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr and Tumblr were patched. More patches to come, Yahoo says.

Email

Was it affected? Is there a patch? Do you need to change your password? What did they say?
AOL No No No AOL told Mashable it was not running the vulnerable version of the software.
Gmail Yes Yes YesYes* “We have assessed the SSL vulnerability and applied patches to key Google services.”

*Google said users do not need to change their passwords, but because of the previous vulnerability, better safe than sorry.

Hotmail / Outlook No No No Microsoft services were not running OpenSSL, according to LastPass.
Yahoo Mail Yes Yes YesYes “As soon as we became aware of the issue, we began working to fix it… and we are working to implement the fix across the rest of our sites right now.”

Stores and Commerce

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Amazon No No No “Amazon.com is not affected.”
Amazon Web Services(for website operators) Yes Yes YesYes Most services were unaffected or Amazon was already able to apply mitigations (see advisory note here). Elastic Load Balancing, Amazon EC2, Amazon Linux AMI, Red Hat Enterprise Linux, Ubuntu, AWS OpsWorks, AWS Elastic Beanstalk and Amazon CloudFront were patched.
eBay No No No “eBay.com was never vulnerable to this bug because we were never running a vulnerable version of OpenSSL.”
Etsy Yes* Yes YesYes Etsy said that only a small part of its infrastructure was vulnerable, and they have patched it.
GoDaddy Yes Yes YesYes “We’ve been updating GoDaddy services that use the affected OpenSSL version.” Full Statement
Groupon No No No “Groupon.com does not utilize a version of the OpenSSL library that is susceptible to the Heartbleed bug.”
Nordstrom No No No “Nordstrom websites do not use OpenSSL encryption.”
PayPal No No No “Your PayPal account details were not exposed in the past and remain secure.” Full Statement
Target No No No “[We] launched a comprehensive review of all external facing aspects of Target.com… and do not currently believe that any external-facing aspects of our sites are impacted by the OpenSSL vulnerability.”
Walmart No No No “We do not use that technology so we have not been impacted by this particular breach.”

Videos, Photos, Games & Entertainment

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Flickr Yes Yes YesYes “As soon as we became aware of the issue, we began working to fix it… and we are working to implement the fix across the rest of our sites right now.”
Hulu No No No No comment provided.
Minecraft Yes Yes YesYes “We were forced to temporary suspend all of our services. … The exploit has been fixed. We can not guarantee that your information wasn’t compromised.” More Information
Netflix Yes Yes YesYes “Like many companies, we took immediate action to assess the vulnerability and address it. We are not aware of any customer impact. It’s a good practice to change passwords from time to time, now would be a good time to think about doing so. “
SoundCloud Yes Yes YesYes SoundCloud emphasized that there were no indications of any foul play and that the company’s actions were simply precautionary.
YouTube Yes Yes YesYes* “We have assessed the SSL vulnerability and applied patches to key Google services.”

*Google said users do not need to change their passwords, but because of the previous vulnerability, better safe than sorry.

Financial

All the banks we contacted (see below) said they were unaffected by Heartbleed, but U.S. regulators have warned banks to patch their systems.

Was it affected? Is there a patch? Do you need to change your password? What did they say?
American Express No No No “There was no compromise of any customer data. While we are not requiring customers to take any specific action at this time, it is a good security practice to regularly update Internet passwords.”
Bank of America No No No “A majority of our platforms do NOT use OpenSSL, and the ones that do, we have confirmed no vulnerabilities.”
Barclays No No No No comment provided.
Capital One No No No “Capital One uses a version of encryption that is not vulnerable to Heartbleed.”
Chase No No No “These sites don’t use the encryption software that is vulnerable to the Heartbleed bug.”
Citigroup No No No Citigroup does not use Open SSL in “customer-facing retail banking and credit card sites and mobile apps”
E*Trade No No No E*Trade is still investigating.
Fidelity No No No “We have multiple layers of security in place to protect our customer sites and services.”
PNC No No No “We have tested our online and mobile banking systems and confirmed that they are not vulnerable to the Heartbleed bug.”
Schwab No No No “Efforts to date have not detected this vulnerability on Schwab.com or any of our online channels.”
Scottrade No No No “Scottrade does not use the affected version of OpenSSL on any of our client-facing platforms.”
TD Ameritrade No No No TD Ameritrade “doesn’t use the versions of openSSL that were vulnerable.”
TD Bank No No No “We’re currently taking precautions and steps to protect customer data from this threat and have no reason to believe any customer data has been compromised in the past.”
T. Rowe Price No No No “The T. Rowe Price websites are not vulnerable to the “Heartbleed” SSL bug nor were they vulnerable in the past.”
U.S. Bank No No No “We do not use OpenSSL for customer-facing, Internet banking channels, so U.S. Bank customer data is NOT at risk.”
Vanguard No No No “We are not using, and have not used, the vulnerable version of OpenSSL.”
Wells Fargo No No No No reason provided.

Government and Taxes

Was it affected? Is there a patch? Do you need to change your password? What did they say?
1040.com No No No “We’re not vulnerable to the Heartbleed bug, as we do not use OpenSSL.”
FileYour Taxes.com No No No “We continuously patch our servers to keep them updated. However, the version we use was not affected by the issue, so no action was taken.”
H&R Block No No No “We are reviewing our systems and currently have found no risk to client data from this issue.”
Healthcare .gov No No No “Healthcare.gov consumer accounts are not affected by this vulnerability.”
Intuit (TurboTax) No No No Turbotax wrote that “engineers have verified TurboTax is not affected by Heartbleed.” The company has issued new certificates anyway, and said it’s not “proactively advising” users to change their passwords.
IRS No No No “The IRS continues to accept tax returns as normal … and systems continue operating and are not affected by this bug. We are not aware of any security vulnerabilities related to this situation.”
TaxACT No No No “Customers can update their passwords at any time, although we are not proactively advising them to do so at this time.”
USAA Yes Yes YesYes USAA said that it has “already taken measures to help prevent a data breach and implemented a patch earlier this week.”

Other

Was it affected? Is there a patch? Do you need to change your password? What did they say?
Box Yes Yes YesYes “We’re currently working with our customers to proactively reset passwords and are also reissuing new SSL certificates for added protection.”
Dropbox Yes Yes YesYes On Twitter: “We’ve patched all of our user-facing services & will continue to work to make sure your stuff is always safe.”
Evernote No No No “Evernote’s service, Evernote apps, and Evernote websites … all use non-OpenSSL implementations of SSL/TLS to encrypt network communications.”Full Statement
GitHub Yes Yes YesYes GitHub said it has patched all its systems, deployed new SSL certificates and revoked old ones. GitHub is asking all users to change password, enable two-factor authentication and “revoke and recreate personal access and application tokens.”
IFTTT Yes Yes YesYes IFTTT emailed all its users and logged them out, prompting them to change their password on the site.
OKCupid Yes Yes YesYes “We, like most of the Internet, were stunned that such a serious bug has existed for so long and was so widespread.”
Spark Networks (JDate, Christian Mingle) No No No Sites do not use OpenSSL.
SpiderOak Yes Yes No Spideroak said it patched its servers, but the desktop client doesn’t use a vulnerable version of OpenSSL, so “customers do not need to take any special action.”
Wikipedia(if you have an account) Yes Yes YesYes “We recommend changing your password as a standard precautionary measure, but we do not currently intend to enforce a password change for all users.” Full Statement
WordPress Unclear Unclear Unclear WordPress tweeted that it has taken “immediate steps” and “addressed the Heartbleed OpenSSL exploit,” but it’s unclear if the issue is completely solder. When someone asked Matt Mullenweg, WordPress’ founding developer, when the site’s SSL certificates will be replaced and when users will be able to reset passwords, he simplyanswered: “soon.”
Wunderlist Yes Yes YesYes “You’ll have to simply log back into Wunderlist. We also strongly recommend that you reset your password for Wunderlist.”Full Statement

Password Managers

Was it affected? Is there a patch? Do you need to change your password? What did they say?
1Password No No No 1Password said in a blog post that its technology “is not built upon SSL/TLS in general, and not upon OpenSSL in particular.” So users don’t need to change their master password.
Dashlane Yes Yes No Dashlane said in a blog post users’ accounts were not impacted and the master password is safe as it is never transmitted. The site does use OpenSSL when syncing data with its servers but Dashlane said it has patched the bug, issued new SSL certificates and revoked previous ones.
LastPass Yes Yes No “Though LastPass employs OpenSSL, we have multiple layers of encryption to protect our users and never have access to those encryption keys.” Users don’t need to change their master passwords becausethey’re never sent to the server. But passwords for other sites stored in LastPass might need to be changed.

Discover more from Userfriendly-Devon

Subscribe to get the latest posts sent to your email.

Comments are closed