Re: [UI Security] iframe URL indicator

If the authentication to the issuer domain in 3D secure was FIDO or another
unphishable/domain scoped credential the user would have no need to
validate the domain. If it's not the real issuer site, the txn doesn't
complete, but you haven't given away any thing of use to an attacker,
either.

On Mon, Feb 22, 2016, 10:43 AM Bil Corry <bil@corry.biz> wrote:

> I agree that many users are challenged by the URL bar, but for the
> educated users, it's a valuable signal.  I suspect this would be similar.
> Currently, even experts would be challenged to assert an iframe is secure
> to enter sensitive information.
>
> One example I have in mind is 3DSecure, which is used to authenticate
> credit card holders in order to authorize credit card transactions via an
> iframe.  How would you reimagine that interaction so that's it
> consequence-free?
>
>
> - Bil
>
> On Mon, Feb 22, 2016 at 6:45 PM, Brad Hill <hillbrad@gmail.com> wrote:
>
>> <hat=editor/chair> I think we could put together a separate spec that
>> just covers this, as almost a one-liner or in "incubation" mode, and inline
>> it into the appropriate part of HTML or whatever other spec if it gets
>> interoperably implemented.  I would really not want to block advancement of
>> the other tech in the UISecurity spec, or have to rev that work constantly,
>> based on this feature that we have every reason to believe will be
>> controversial to implement consistently in multiple browsers.</hat>
>>
>> <hat=individual> I think that many of the scenarios that require this are
>> best re-imagined through technologies and experiences that are
>> consequence-free in the case of spoofing.  (e.g. pressing a "like" button
>> that's not really from Facebook can't do harm to the user at Facebook
>> vis-a-vis to what they expected to happen, or clicking login with a FIDO
>> authenticator is harmless when credentials are inherently origin-scoped)
>>  I'm willing to see the data from experiments, but my intuition says it
>> isn't reasonable to expect users to understand multi-address bar interfaces
>> when there is such a long history of difficulty and vulnerability, still,
>> after 25 years of the single-origin address bar. </hat>
>>
>>
>>
>> On Mon, Feb 22, 2016 at 5:11 AM Bil Corry <bil@corry.biz> wrote:
>>
>>> Is it possible for the specification to simply state that the in-focus
>>> iframe URL must be presented to the user and leave it up to the implementer
>>> to determine how best to do it?
>>>
>>> The specification solves the problem of visibility of the iframe, but as
>>> written, doesn't solve the problem of identifying the origin, which is what
>>> is required for secure iframe interactions where sensitive information is
>>> being entered (e.g. credentials to the iframed site).
>>>
>>> I agree that there are some challenges, such as user understanding or
>>> swapping out the legitimate iframe for a phishing iframe upon a click
>>> event, but hopefully we can understand those limitations with Dan's test
>>> platform.
>>>
>>>
>>> - Bil
>>>
>>>
>>>
>>> On Mon, Feb 22, 2016 at 10:05 AM, Dan Kaminsky <dan@doxpara.com> wrote:
>>>
>>>> Perhaps true, but there's wide classes of interactions that cannot be
>>>> secured without address bar management. I'm hoping to have a usable test
>>>> platform including this feature in the next 4-6 weeks.  Where I think
>>>> everyone would agree is that this feature needs user data before approval
>>>> in a way normal features might not.
>>>>
>>>> On Sunday, February 21, 2016, Brad Hill <hillbrad@gmail.com> wrote:
>>>>
>>>>> These kinds of decisions have proven in practice to be beyond the
>>>>> ability of groups like ours to specify well.  Our intuituons about users'
>>>>> understandings are not as good as data, may not be universal, or may need
>>>>> different treatment on different devices and experiences.  With my editor
>>>>> hat on, I'm inclined to leave this to each UA to experiment with and
>>>>> determine what is best for their userbase.
>>>>>
>>>>> -Brad
>>>>>
>>>>> On Sat, Feb 13, 2016, 5:21 AM Bil Corry <bil@corry.biz> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> i was reviewing the UI Security draft [1] and wondered if there were
>>>>>> plans to incorporate IronFrame's URL indicator for the iframe domain [2].
>>>>>> That is to say, will a user be able to see the URL of the iframe that is in
>>>>>> focus?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> - Bil
>>>>>>
>>>>>>
>>>>>> [1] http://w3c.github.io/webappsec-uisecurity/
>>>>>>
>>>>>> [2] Slide 72:
>>>>>> http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickjacking/
>>>>>>
>>>>>
>>>
>