RP Name and Logo Dialog

[Shane Tomlinson]

About a month ago I sent out a message asking for opinions on placing
the RP name and logo inside of the dialog. While some very valid
concerns over phishing and XSS were aired, feedback was mostly positive.

I have implemented the initial revision of this feature in a branch and
would like to get more feedback.

We are going for the easiest possible implementation with the initial
revision - the RP's name and logoURL are specified in the options block
when calling navigator.id.experimental.request. This takes the form of:

navigator.id.experimental.request({
name: "Your Favorite Site",
logoURL: "https://<site>/<logo>",
....
});

There is a limitation with respect to the logoURL. Since the BrowserID
dialog is served up using HTTPS, RP logos must also be served using
secure methods to avoid any mixed content errors. This means RPs must
serve up the logo using either an "https" based URL or a data-URI.

What are your thoughts concerning this limitation? We realize that
having all RPs use https to serve up their logo is not realistic, are
data-URIs a viable alternative? Will this limitation block sites from
using the feature? There are already several image to data-URI
converters on the web, should we provide another?

A second option we have considered is to proxy all RP logos. Doing so
requires more work on our part, but it does allow for some flexibility -
we can perform sanity checks and image resizing to ensure users are not
downloading images that are too large.

What are your thoughts?

Shane

[Jeff Schnitzer]

Speaking as an RP, there's nothing wrong with the HTTPS requirement.
A data-uri is a fine backup.

I have a reasonably high degree of faith in my own image serving CDN,
and in any case, if it fails my whole website is toast anyways. A
persona proxy solution is more moving parts and more things that can
fail, and therefore gives me less confidence in the whole solution.

Jeff

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity

[Ian Bicking]

On Tue, May 1, 2012 at 6:07 AM, Shane Tomlinson <stoml...@mozilla.com>wrote:

> What are your thoughts concerning this limitation? We realize that having
> all RPs use https to serve up their logo is not realistic, are data-URIs a
> viable alternative? Will this limitation block sites from using the
> feature? There are already several image to data-URI converters on the
> web, should we provide another?
>

Will you have some service to validate RPs? If it's really easy you could
do it there, or just link to one from that same location.

> A second option we have considered is to proxy all RP logos. Doing so
> requires more work on our part, but it does allow for some flexibility - we
> can perform sanity checks and image resizing to ensure users are not
> downloading images that are too large.
>

We have the same problem with app icons and I was expecting we'd end up
proxying. OTOH for many apps it's reasonable to be unconcerned with
security, but any RP should be security-conscious and so the https
requirement doesn't seem like that big a deal. If an RP can't figure that
out, I'm not sure how much I'd trust them to handle my identity.

[Lloyd Hilaiel]

On May 1, 2012, at 9:13 AM, Ian Bicking wrote:

> We have the same problem with app icons and I was expecting we'd end up
> proxying.

We were talking about the same thing. I'm worried that this prevents intranet
apps from working. In both cases, we can degrade gracefully and just not display
app icons that aren't publicly accessible. But I'm not completely happy with
this restriction.

lloyd

[Ben Adida]

On 5/1/12 8:51 AM, Lloyd Hilaiel wrote:
> We were talking about the same thing. I'm worried that this prevents intranet
> apps from working.

Oh. That's a very important point, actually. To date, we have *not*
required any server-to-server communication for full functionality.
Changing that model would be unfortunate. Tips the scales, in my
opinion, away from proxying.

-Ben

[Daniel Mills]

Though note that a native client would be able to offer full functionality without proxying.

Jeff's point was very good though: proxying feels like more moving parts from an RP's POV, an https feels simpler and only depends on the site's cdn, data uri is a nice backup.

Any site owners disagree with that?

Dan

[Ben Adida]

On 5/1/12 9:24 AM, Daniel Mills wrote:
> Though note that a native client would be able to offer full functionality without proxying.

Sure, but I don't think we should plan a feature that breaks in the shim :)

-Ben

[Daniel Mills]

I agree :) sorry that wasn't clear, I was just pointing out that interesting property!

Dan

[Brian Warner]

On 5/1/12 4:07 AM, Shane Tomlinson wrote:
>
> About a month ago I sent out a message asking for opinions on placing
> the RP name and logo inside of the dialog. While some very valid
> concerns over phishing and XSS were aired, feedback was mostly
> positive.

One concern that came mind (late, I know) was the "attacker tricks you
into signing into their own account" attack, where you think you're
logged in your web-mail provider and you send a message, but actually it
goes into the attacker's outbox so they can read it later. (there's a
cooler name for this one, but I can't seem to find it right now).

> There is a limitation with respect to the logoURL. Since the BrowserID
> dialog is served up using HTTPS, RP logos must also be served using
> secure methods to avoid any mixed content errors. This means RPs must
> serve up the logo using either an "https" based URL or a data-URI.

The dialog needs to be careful about those URLs, to avoid allowing the
RP to do an injection attack against the dialog provider (browserid.org,
or a native implementation). SVGs delivered as <img> tags don't run
scripts, right?

> A second option we have considered is to proxy all RP logos.

It looks like there are other good reasons to avoid proxying, but I'll
just note that if we did that, you should avoid the approach where the
domain that hosts the dialog also proxies raw image bytes (i.e. if
https://browserid.org/proxy?url=http://example.com/logo.png just served
anything retrieved from http://example.com/logo.png). If the image is an
SVG, then loading that URL directly (instead of inside an <img> tag,
like if my page just redirects your browser to it) will execute any
scripts inside the SVG, giving example.com control over browserid.org,
which would be bad. And some browsers are known to get clever and look
inside the file for type indicators rather than honoring the server's
Content-Type, so you might wind up with a file named logo.png and served
as Content-Type: image/png but which actually contains (and executes as)
SVG.

If you really had to do that, the safest thing would be for the proxy to
render the image down into a grid of pixels, then build it back up into
a brand new PNG to be served, giving the attacker less control over the
output. Also, serve the images from a separate domain (e.g.
logo-proxy.browserid.org) that isn't used for anything else, so if it
fails, they get control over something useless.

cheers,
-Brian

[Will Bamberg]

On 12-05-01 11:58 AM, Brian Warner wrote:
> On 5/1/12 4:07 AM, Shane Tomlinson wrote:
>> About a month ago I sent out a message asking for opinions on placing
>> the RP name and logo inside of the dialog. While some very valid
>> concerns over phishing and XSS were aired, feedback was mostly
>> positive.
> One concern that came mind (late, I know) was the "attacker tricks you
> into signing into their own account" attack, where you think you're
> logged in your web-mail provider and you send a message, but actually it
> goes into the attacker's outbox so they can read it later. (there's a
> cooler name for this one, but I can't seem to find it right now).

Is this a Cross-Site Request Forgery? There's some documentation on this
that you might want to improve :-)
https://developer.mozilla.org/en/BrowserID/Security_Considerations#Implement_CSRF_login_attack_protection.

[Mike G]

Think he meant phishing.

> https://developer.mozilla.org/**en/BrowserID/Security_**
> Considerations#Implement_CSRF_**login_attack_protection<https://developer.mozilla.org/en/BrowserID/Security_Considerations#Implement_CSRF_login_attack_protection>
> .
>
> ______________________________**_________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-identity<https://lists.mozilla.org/listinfo/dev-identity>
>

[Mike G]

No proxy. Require it. It costs one cent to use s3 ssl image.

On May 1, 2012 4:08 AM, "Shane Tomlinson" <stoml...@mozilla.com> wrote:

>
> About a month ago I sent out a message asking for opinions on placing the
> RP name and logo inside of the dialog. While some very valid concerns over
> phishing and XSS were aired, feedback was mostly positive.
>

> I have implemented the initial revision of this feature in a branch and
> would like to get more feedback.
>
> We are going for the easiest possible implementation with the initial
> revision - the RP's name and logoURL are specified in the options block

> when calling navigator.id.experimental.**request. This takes the form of:
>
> navigator.id.experimental.**request({

> name: "Your Favorite Site",
> logoURL: "https://<site>/<logo>",
> ....
> });
>

> There is a limitation with respect to the logoURL. Since the BrowserID
> dialog is served up using HTTPS, RP logos must also be served using secure
> methods to avoid any mixed content errors. This means RPs must serve up
> the logo using either an "https" based URL or a data-URI.
>

> What are your thoughts concerning this limitation? We realize that having
> all RPs use https to serve up their logo is not realistic, are data-URIs a
> viable alternative? Will this limitation block sites from using the
> feature? There are already several image to data-URI converters on the
> web, should we provide another?
>

> A second option we have considered is to proxy all RP logos. Doing so
> requires more work on our part, but it does allow for some flexibility - we
> can perform sanity checks and image resizing to ensure users are not
> downloading images that are too large.
>

> What are your thoughts?
>
> Shane

[Brian Warner]

> On May 1, 2012 12:05 PM, "Will Bamberg" <wbam...@mozilla.com> wrote:

>> Is this a Cross-Site Request Forgery? There's some documentation on
>> this that you might want to improve :-)

>> https://developer.mozilla.org/en/BrowserID/Security_Considerations#Implement_CSRF_login_attack_protection

The particular attack that page describes does sound related, but "CSRF
attacks" are a more general thing. So "Login Attack" or "Login Attack
(enabled by CSRF attacks)" might be a good description. Sid suggested
"cookie stuffing" might be related, but it's not quite right either.

On 5/1/12 12:22 PM, Mike G wrote:
> Think he meant phishing.

Well, the usual phising attack is where I trick you into revealing the
password you use with someone else, by pretending to be that someone
else. This is a bit different, where I trick you into tricking someone
else that you're me. It's not as obvious what I can gain from doing
that, but I've seen compelling examples before (and if I could remember
the right name for the attack, I could probably search for them again).

cheers,
-Brian