Sent from my mobile device
> On Apr 11, 2022, at 6:31 PM, Eric Rescorla <e...@rtfm.com> 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, 2022 at 3:13 PM Richard Barnes <r...@ipv.sx> wrote: >> 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 replayable, >> and thus perishable, through this attack or others. >> Thank you. From a different thread, I thought WebAuthn was vulnerable. Best regards, Kathleen >> >>> On Mon, Apr 11, 2022 at 5:21 PM Kathleen Moriarty >>> <kathleen.moriarty.i...@gmail.com> wrote: >>> 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 <bem...@google.com> wrote: >>>>> >>>> >>>> >>>> >>>>> On Mon, Apr 11, 2022 at 4:42 PM Kathleen Moriarty >>>>> <kathleen.moriarty.i...@gmail.com> wrote: >>>>> >>>>> >>>>> 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? >>>> >>>> This attack is on password-based security, so the credentials are stored >>>> in the user's head, and the user types them into an interface that they >>>> think is the SSO provider, but is in fact the attacker. It's literally >>>> window-dressing on a standard old-fashioned phishing attack. This page >>>> explains the technique: >>>> https://mrd0x.com/browser-in-the-browser-phishing-attack/ >>>> >>>>> 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. >>>> >>>> That article appears to be an attempt to restate the original report on >>>> Ghostwriter published here: >>>> https://blog.google/threat-analysis-group/tracking-cyber-activity-eastern-europe/. >>>> It may be easier to understand the details from the original report. >>>> >>>>> >>>>> 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 >> _______________________________________________ >> 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
