It seems unlikely. The differences between OPAQUE and SRP aren't what kept SRP from being adopted. The fact that SRP doesn't really solve a problem that most organizations care about for their web applications is a bigger issue.
Remember, virtually all mainstream applications accept logins over TLS (exclusively) at this point, so being able to authenticate and encrypt a channel with a passphrase isn't all that valuable. As a security engineer working for a startup, there aren't a lot of new features I'd be able to build after having adopted SRP, and essentially none of my real current challenges (credential stuffing, phishing) would get any easier.
That's not to say OPAQUE isn't useful; it's just not that useful in SAAS-type application settings.
The killer use case I see for PAKEs is that they verify not only that the client has the password, but also the server.
When modern browsers trust 150 Certificate Authorities [0] (and the untold subordinate/wildcard certs that were further issued by them), it's reassuring to know that I've verified that the server actually had my password (or a derivative), which makes it even harder to phish or impersonate a server with a stolen/malicious signed TLS key (this is all assuming the browser has a special non-spoofable dialog when authenticating via a PAKE).
For example, picture all of the people who have lost their banking passwords to phishing sites. If PAKEs were used, then the attacker gets nothing except a single guess at the password. If the attacker already knew the user's password, then the user already lost.
> When modern browsers trust 150 Certificate Authorities
That's not what the link you provided shows.
It lists 150 CA roots. 20 of those roots lack a "websites" trust bit, which means the web browser does not trust those roots (Mozilla also has an email client even if it's not much loved)
Furthermore, the 130 of those roots that are trusted in a web browser are operated by only 52 distinct Certificate Authorities. CAs operate several roots either because of business consolidation or segmentation, for example DigiCert operates 23 of the web trusted CAs you linked because they purchased Symantec's business in 2017 and are in the process of replacing Symantec's soon-to-be-untrusted hierarchy.
It's very strange to merge subordinates and wildcards which aren't the same kind of thing at all. Unconstrained subordinates are, in fact, tallied by Mozilla and they're on the adjacent page:
The vast majority of these intermediates are just for issuance and remain entirely under both physical control and legal authority of the CA, so they make no difference to the trust picture they just reduce the exposure if things go wrong.
This is true, but can't you address the same problem without a PAKE by simply remembering the server certificate public key (or at least its issuing CA)? Remember: browsers don't support PAKEs now. So consider: what's the least required mechanism to solve the problem you're posing?
I agree the PAKE theoretically does a better job on this problem. But does it do that job so much better as to justify its inclusion in a protocol?
The difference seems to be that server certificate public keys and CAs will change, so browsers will have to include an "Ignore this change?" prompt, which means a certain number of people will click it.
On the other hand, a PAKE failure due to the server not having its half of the authentication data is not possible to ignore, so people will be forced to get it right.
But certificate authentication precedes user authentication, so the people who don't click it are sufficient to detect misissuance and kill the offending CA. You'd rather not have the problem at all, but if every exploit burns an entire CA, that's not the worst place to be.
I think I generally sympathise with this way of thinking about the value of a PAKE here, and you're right that only one person has to see a smoking gun - but just to be quite clear here on how fragile such manual checks would be:
The certificate used for the HTTP transaction where your credentials are submitted may be completely different from the one used to present the web form you filled them into.
A sneaky bad guy can let you talk to the real Bob for every single HTTP transaction aside from the one they want to capture, and intercede just for that single case, then drop back out silently, leaving you talking to Bob directly as before.
The web browser's own checks (including matching the FQDN against the certificate) run every single time - if they spot Eve taking Bob's place they'll freak out, but any human checks like "Look at the certificate in Certainly Something" (the nice certificate view for Firefox) only happen when a human gets to intervene which may not happen at all at key moments.
When did you get to examine that certificate for login.example.com? The answer in every browser I've seen is not at all, because it responded with a 30x so the page never finished and displayed.
I don't believe that's a security concern that motivates entire new protocols; further, I think it's one of those security issues that is talked about more than it is actually felt. So far as I know, none of the HIBP datasets have come from logs? I'd be interested in corrections.
The "real" issue PAKEs address is long-term compromise, where an attacker can observe passwords out of memory. For that matter: for attackers to get log files in the first place, 9 times out of 10 they had to get RCE somewhere in prod, and that is already game over. And, there's a lot of things you'd do first do address game-over than replacing your TLS login POST with a PAKE handshake.
It happened at Twitter, was discovered internally at Twitter, remediated at Twitter, and disclosed by Twitter. It was talked about but not in any apparent way felt. And, again, if that's your only concern, there are simpler ways to mitigate that threat than a whole PAKE.
PAKEs don't address Heartbleed-like issues; in fact, they create more opportunities for them.
Remember, virtually all mainstream applications accept logins over TLS (exclusively) at this point, so being able to authenticate and encrypt a channel with a passphrase isn't all that valuable. As a security engineer working for a startup, there aren't a lot of new features I'd be able to build after having adopted SRP, and essentially none of my real current challenges (credential stuffing, phishing) would get any easier.
That's not to say OPAQUE isn't useful; it's just not that useful in SAAS-type application settings.