Sent from my mobile device
> On Apr 11, 2022, at 6:31 PM, Eric Rescorla wrote:
>
>
> Note that a password manager is a partial mitigation here, at least if it's
> tied into the browser and automatically fills in based on origin, much like
> WebAuthn is.
>
> -Ekr
>
>
>> On Mon, Apr 11,
Note that a password manager is a partial mitigation here, at least if it's
tied into the browser and automatically fills in based on origin, much like
WebAuthn is.
-Ekr
On Mon, Apr 11, 2022 at 3:13 PM Richard Barnes wrote:
> Just to be clear:
>
> * These "picture in picture" attacks have
Just to be clear:
* These "picture in picture" attacks have been around for years, as Ben
points out.
* WebAuthn is not vulnerable, because its assertions are bound to the
origin, and a phishing site can't access the correct origin.
* Anything that doesn't involve asymmetric cryptography will be
Thank you, Ben. Much appreciated. I’ll think about this a bit more and a few
others now are as well.
Best regards,
Kathleen
Sent from my mobile device
> On Apr 11, 2022, at 5:05 PM, Ben Schwartz wrote:
>
>
>
>
>> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty
>> wrote:
>>
>>
>>
Sent from my mobile device
> On Apr 11, 2022, at 3:52 PM, Ben Schwartz wrote:
>
>
> I think there may be a misunderstanding here. According to my understanding,
> these attack pages do not need to contain any actual subresources from the
> SSO provider. They simply provide a login UI
This has to be dealt with at the container interface for non-browser
interfaces too, right?
If there are OASIS and W3C WebAuthn active participants, it would be
helpful to figure out the best place to deal with this issue.
Thank you and sorry for a second message.
Best regards,
Kathleen
On
Greetings!
In thinking about the attacks prompting for credentials to access SSO
credentials in browsers, I am wondering if the fix is in the interface to
each type of storage container for credentials, e.g. OASIS PKCS#11, W3C
WebAuthn, and maybe OAuth if that has been hit as well by these
