Firefox/Projects/AccountManager/Meetup/SecurityAndPrivacy

In scope for this discussion:

• possible attacks
• Automated registration opens the possibility of flood attacks\
• Automated login enables some attacks? (dealing with throttling)
• 2 CSRF-prevention proposals on the table, both require site support

Privacy

• Summary of concerns: protocol changes don't seem to change privacy risks, but the UI changes will.
• Leakage of existence of other accounts (via UI)
• Does the UI separate history based on authentication profile? i.e., are my cookies locked up when I log out?
• Maybe not clear *how* authentication is performed (federated vs. direct to site may be transparent to user)
• If the UI shows your user name, shoulder surfers may see who you are.
• ToS / privacy policy change (usually shows up right after log in)
• Auto-log-me-in checkbox: user should be able to specify which sites they'd like to log into without clicking through the UI each time.
• Covert channels: can a site determine if you've got an account by timing how long it takes to load or frame (or other similar mechanism)? Solution: limit AM to window.top for this.
• Limit AM to window.top helps with lots of things.

Security

• HostMeta / AccountManagement header attacks - connections for account operations should be over HTTPS and Strict-Transport-Security so that a MITM can't inject stuff. Maybe the UA should default to https and fall back to http if that fails.
• Do we allow 3xx redirects for any of the account manager stuff?
• UI for subframe logins? Which frame in a tree of frames corresponds to the account UI? (This is a user confusion attack) Should make the UI pair a representation of the site being communicated with when you select an account operation in the UI. Needs to be obvious who the user is interacting with. Maybe AM should only support window.top?
• Chrome should be non-spoofable from a web page.
• How are a site's requirements on input conveyed to the UA? E.g., if a password must contain only alphanumeric chars, and passwords are autogenerated, how does the client implementation enforce this? Is it well known what the flow is if these requirements are violated by the UA?
• UAs should not permanently store account management configuration data since if an attacker were able to inject just a little bit of data (one rogue session), it could be forced to be cached too long. Maybe after a short while, the host-meta data should be re-verified with a HEAD request to see if it has changed.
• CSRF: either the site says where to get the nonce/csrf-token it provides, or forbid headers from being sent across sites, but allow our UA to do it. (problem with second option is that a bad proxy could "oops" and inject bad headers).