1248634 - Hide API Keys by default

Status: NEW

(Bugzilla :: User Accounts, enhancement)

Description

[Dylan Hardison [:dylan] (he/him)]

We should not display the API keys by default

Comment 1

[Frédéric Buclin]

For security reasons, or...?

Comment 2

[David Lawrence [:dkl]]

(In reply to Frédéric Buclin from comment #1)
> For security reasons, or...?

Mainly. In case of an accidental screencast or a screenshot of the API tabs. Someone looking over your shoulder would be less likely unless they take a picture or can remember a lot of letters ;) We could simply have a button that hides/shows a specific key on request.

dkl

Comment 3

[Frédéric Buclin]

Could installations which do not use an alternate server for attachments be vulnerable to some attack which would load the HTML page and parse it to collect API keys?

Comment 4

[:glob ✱]

(In reply to Frédéric Buclin from comment #3)
> Could installations which do not use an alternate server for attachments be
> vulnerable to some attack which would load the HTML page and parse it to
> collect API keys?

if you allow any attachments to be uploaded, don't use an alternative server, and allow in-browser display of these attachments, yes that's possible.  however it would be easier for the attacker to read the current user's login cookie, and with that they can perform any action as the user including reading api keys regardless of the counter measures put in place here.  in other words the security door is already wide open in that configuration, and we needn't worry about it with respect to this change.

Comment 5

[Frédéric Buclin]

(In reply to Byron Jones ‹:glob› from comment #4)
> however it would be easier for the attacker to read the current
> user's login cookie

No, login cookies are protected thanks to the HttpOnly attribute. No script can get them.


> in other words the security door is already wide open in that
> configuration, and we needn't worry about it with respect to this change.

I disagree. This is a new door which is opened here. And many installations have no alternate server for attachments. No reason to make attacker's life easier. One way to prevent this problem would be to use the same protection as for CSRF attacks, right? I.e. store a hash or session token in the page on the first load, and click a "Show API keys" button which will submit the form again and make sure the token matches the login cookie before displaying API keys. Also, maybe using X-Frame-Options Deny instead of SameOrigin would help mitigate the problem.

Comment 6

[Dylan Hardison [:dylan] (he/him)]

Note: I am hiding these with CSS and JavaScript. This does not change the how API keys are injected into the html. So if we are vulnerable now we remain vulnerable and if not, we are not...

Comment 7

[Frédéric Buclin]

(In reply to Dylan William Hardison [:dylan] from comment #6)
> Note: I am hiding these with CSS and JavaScript. This does not change the
> how API keys are injected into the html. So if we are vulnerable now we
> remain vulnerable and if not, we are not...

Ah sure, I didn't mean you were making things worse. :) My comment was not specific to this bug, but more general about how API keys are displayed to the user. Another way to prevent API keys stealing would be to do the same as the password manager in Firefox: ask for the user's password before displaying them (wouldn't work if authenticated with a method which doesn't require a password, though).

Comment 8

[David Lawrence [:dkl]]

(In reply to Frédéric Buclin from comment #7)
> Ah sure, I didn't mean you were making things worse. :) My comment was not
> specific to this bug, but more general about how API keys are displayed to
> the user. Another way to prevent API keys stealing would be to do the same
> as the password manager in Firefox: ask for the user's password before
> displaying them (wouldn't work if authenticated with a method which doesn't
> require a password, though).

For BMO we could ask for the 2fa code for those with it enabled. As LpSolit mentioned not sure how we would handle those who do not have it enabled or are using Persona/Github for auth.

We could create an API call with csrf token embedded that when clicking the button, it will call the REST API to get the API key and then display it. That way it is not embedded in the HTML as soon as the page is loaded.

dkl