Sent from my mobile device
> On Apr 11, 2022, at 3:52 PM, Ben Schwartz <bem...@google.com> 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 that matches the appearance of > the SSO login, in order to trick the user into entering their SSO credentials > into an attacker-controlled tab. > > This doesn't seem like something that can be fixed by the TLS working group. Right, but maybe by people here who also work on the interfaces to where credentials are stored? It’s posed as a browser attack as that’s the current mechanism, but is going after credentials to access SSO. I guess that could be replayed later as well if only captured by this and doesn’t access the store, but the article seems to say that the store is accessed. Thanks for thinking about it, Kathleen > >> On Mon, Apr 11, 2022 at 3:48 PM Kathleen Moriarty >> <kathleen.moriarty.i...@gmail.com> wrote: >> 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 Mon, Apr 11, 2022 at 3:35 PM Kathleen Moriarty >>> <kathleen.moriarty.i...@gmail.com> wrote: >>> 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 attacks, >>> called "Browser in the Browser". >>> https://www.techrepublic.com/article/browser-in-the-browser-attacks-arise/ >>> >>> Is there a way in the browser for an organization to configure (or can >>> there be in those interfaces) the only permitted addresses to prompt and >>> allow access to the interface, so not just the password is needed? It >>> seems like the best place to fix it even though each organization would >>> have to enter an allow list. The alternative would be deny lists of all the >>> malicious sites performing this activity and that won't catch everything. >>> >>> Is this being discussed already somewhere? Hopefully. Perhaps there are >>> other ideas? >>> >>> Thank you. >>> -- >>> >>> Best regards, >>> Kathleen >> >> >> -- >> >> Best regards, >> Kathleen >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
