Account Manager coming to Firefox

Update: The Account Manager is no longer maintained. Building on this experiment, we have conceived BrowserID. Please consider using it instead.

Last month Mozilla Labs announced a new concept series on online identity. As part of this exploration, we developed the Account Manager.

The Account Manager makes it incredibly easy for users to create new accounts with optional randomly generated passwords, and log into and out of them with just a click. As a web developer, adding support for this feature could take as little as fifteen minutes of hacking (in fact, we’ll mention the first 5 people to add support – read below to learn more.).

We want to make signing into websites easier for all Firefox users, and are looking to ship this feature as soon as possible in Firefox. As part of that process we’re looking for feedback to refine the specification. Now is a really good time to get involved in defining the spec.

There are three things that you can do right now:

This feature is currently available as an experimental add-on, available on the Account Manager homepage.

Here’s a video where you can get a basic idea of how Account Manager works today:

How Does It Work?

The Account Manager specification proposes two small changes to Web sites:

  1. The browser needs to know how to register, sign in, and sign out of your site. You will need a static JSON document, automatically discovered by the browser, which describes what methods the site supports and how they should be executed. For example, a web site might describe their support of “connect” (sign in) like this:

      "methods": {
        "username-password-form": {
          "connect": {
            "method": "POST",
            "path": "/accounts/LoginAuth",
            "params": {
              "username": "Email",
              "password": "Passwd"
          }
      }
    

    This example tells the browser that the site supports signing in with a form POST to /accounts/LoginAuth, and what parameter names to use for the username and password (Email and Passwd respectively).

  2. The browser needs a way to check which user (if any) is currently signed in. To do this, you need to set an HTTP header in the same code where you would set a cookie with a session ID. If you can’t set an HTTP header, you can also supply a URL the browser will ping.

    The header would look like this:

    X-Account-Management-Status: active; name="Joe User"

    That would tell the browser that “Joe User” is now signed in, so it can provide the appropriate UI (to switch users or sign out).

    How do I try it?

    • Install the demo add-on.
    • Place a host-meta document to your website at /.well-known/host-meta (it must be at this location). This tells the browser where to find the JSON file we described above. For examples, check the spec or Yahoo!’s host-meta.
    • Add the JSON file itself to your site. We call this the Account Manager Control Document, or AMCD for short. The AMCD should contain your form end-points for sign-in and sign-out. Note that you don’t need to change the end-points, just describe them. Check the spec for a complete example.
    • Change your site to set the correct headers when users sign in or out.
    • Make sure you have a password saved in the password manager; you may need to sign in manually once to do that if you haven’t already (this requirement will go away in the future).
    • When we add sign-up support in Account Manager, you will likely need to make minor changes to your registration code.

    Update, 5:45PM PST: Just realized while debugging an intrepid first adopter’s site that there is one more requirement:

    • You can send the status header with every request, or if you don’t want to do that, then you need to provide a sessionstatus method (see the spec) that the browser can ping to find out the user’s signed-in status.

    That’s it, folks! Be one of the first to try implementing the specification on your website, and let us know, and let us know how long it took you to add support for it. We’ll put the first five people to implement this on the @mozhacks twitter account with a link to your site!

    Next time we will go into more depth on how discovery works, our plans to support other auth schemes (like HTTP Auth, OpenID, etc), as well as other neat features we plan to add. Stay tuned! And don’t forget to tell us what you think.


    Web Developer FAQ

    • Do I need to redo all of my authentication code?

      No. Account Manager is designed to require minimal server-side changes. You do have a couple of options, but the minimal setup is just a flat file and a couple of extra headers you need to send out.

    • Do I need to redo all of my account creation code?

      Registration will require some small changes to your registration flow, but we have put extra thought into making it as simple as possible for both Web sites and users alike. Check out our discussion group and specification for the details, and let us know what you think!

    • How is this going to help my users?

      Account Manager is great for users. Here are a few highlights:

      • Simple, convenient, user control

        The browser has a couple of advantages when it comes to making this kind of UI. First, it can dedicate a spot in the browser chrome that will look and behave the same for every site, making it a convenient and automatic go-to place for users to check or change their sign-in status.

        The browser also has deep knowledge about the user. For example, the browser could implement fast user switching with just a click. Or think about picking a username: the browser can look at usernames for other accounts and make some pretty good guesses about what usernames are preferred.

      • Secure

        Many security researchers will tell you: one of the biggest security problems on the Web today is that usernames and passwords are often short and easily guessed. Account Manager makes it so that users don’t need to remember their passwords, and in fact can automatically generate strong passwords when signing up.

        Moreover, Account Manager begins the process of abstracting the plumbing of account management from the UI, making it possible in the future to support cryptographically strong protocols without any major UI changes.

      • Works on top of current and emerging solutions

        Lastly, Account Manager is not a new ID for the Web. Rather, it is designed to work on top of current and emerging solutions like OpenID or others, to bring them all under the same user experience. Users shouldn’t have to care what the underlying technology is.

    • How is this going to help me get more users?

      The easier it is to sign up and sign into your site, the more users you will get. It’s pretty much that simple.

      Note that Account Manager doesn’t force your users to make a choice: you can keep all of your current content-based flows intact, so there is really no downside to adding Account Manager support to your site.

    • Do I need to have special content for Firefox only?

      No! First of all, you don’t need to do *any* changes to your current content at all. Account Manager works behind the scenes using a sitemap and headers to communicate with your site and present the right UI to the user.

      On the other hand, we hope that Account Manager will not be a Firefox-only technology. We’re working towards defining the protocol as a formal specification that other Web browsers can implement.

    About Dan Mills

    More articles by Dan Mills…


74 comments

  1. Dan

    How does this fit in with Weave? Will they converge at some point?

    April 27th, 2010 at 15:02

  2. Dan Mills

    It’s an independent, but complementary effort. Seamless, automated negotiation of accounts with user control will help users interact with online services.

    April 27th, 2010 at 15:07

  3. Fernando Agüero

    Seriously, you are making Firefox even better than he is. I recommend it to everyone like it was a creation of mine.

    April 27th, 2010 at 15:20

  4. Way

    Great! That’s the next into the right direction. Looking foward to this new feature and will try the test version now.

    April 27th, 2010 at 15:22

    1. Way

      I’ve forgot the “step” in my comment above ^^

      April 27th, 2010 at 15:23

  5. Ulrich

    Nice idea, but this should definitely support OpenID. I have enough usernme/passwords for 5 livetimes already.

    April 27th, 2010 at 15:29

  6. Robert

    The video is way too short, and they did not even clearly show what is what.
    I am confused. It sounds great but I have no clue what the hell is going on.
    please explain in more detail and please make video longer and more understandable.

    Show us how it works clearly and the steps to get to each step.
    thanks.

    April 27th, 2010 at 15:34

  7. Toby Adams

    I have been waiting for this for ages, It just seems such a good idea!

    April 27th, 2010 at 15:54

  8. Hans

    How does the user control which account will be used? Can websites use this to transparently redirect login to OpenID or facebook friend connect or google accounts?

    April 27th, 2010 at 16:20

  9. Nino D’Aversa

    Dan,

    I love this, great stuff. Can’t wait until this lands on truck.

    April 27th, 2010 at 16:36

  10. Kroc Camen

    /.well-known/host-meta? Are you serious? Are you insane!? Don’t URI squat, that’s bad. That’s why we are still plagued by by favicon.ico which is hard to change, and it fills up 404 logs.

    Please come up with something more elegant for discovery, URI squatting is unacceptable. Allow for a meta tag or header to determine the location, or even use robots.txt since that is there to describe where things are located for machines (like Google have with sitemaps).

    April 27th, 2010 at 16:43

    1. John Drinkwater

      Absolutely agree with allowing for flexibility and not imposing a URI (header is my preference, but meta tag is fine), but asking a client to ping robots.txt? Can’t say that’s a good idea.

      April 28th, 2010 at 03:59

    2. l.m.orchard

      You know /.well-known/host-meta isn’t just a Mozilla thing, right?

      http://tools.ietf.org/html/draft-nottingham-site-meta-05
      http://tools.ietf.org/html/draft-hammer-hostmeta-05
      http://tinyurl.com/2csd8na

      Kind of hard to build complete flexibility into the discovery phase of things where you don’t know what you’re looking for

      April 28th, 2010 at 18:12

  11. Dan Mills

    Thanks for the encouraging comments, guys!

    Ulrich, the demo doesn’t support OpenID right now, but we are designing this to support it in the future. The idea is that Account Manager is not an authentication technology itself, it automates (and abstracts) current/future auth schemes.

    Robert, perhaps we can work on an updated video for next time! But in the meantime, here are some mock-ups (note: these are just mockups, the final feature will almost certainly not look like this. it’s just to give you an idea):

    https://wiki.mozilla.org/File:IdentityInTheBrowser2.png

    Hans, the mockup above has some ideas, though we’re still exploring how it will work.

    Keep the comments coming! :)

    April 27th, 2010 at 16:45

  12. Edward Lee

    @Ulrich: Account Manager works with existing methods of authentication including OpenID. If your OpenID provider uses traditional username and password fields to verify you’re you, Account Manager can automatically log you in to your OpenID provider. Additionally, if a site uses OpenID, Account Manager can automatically provide your OpenID identifier and log in that way.

    April 27th, 2010 at 16:48

  13. Paul-Joseph

    How does this work with multiple accounts on a site?

    April 27th, 2010 at 16:54

  14. Dan Mills

    Kroc Camen,

    Actually, we didn’t make that up. It came out of the Webfinger work (which we’re also very interested in), and got spun off into a couple of specs. See here for details:

    http://hueniverse.com/2010/04/rfc-5785-defining-well-known-uris/
    http://hueniverse.com/2009/11/host-meta-aka-site-meta-and-well-known-uris/ (older, has some background info).

    Also, we have an alternative method for discovery that uses headers. It has the advantage that you can split a single domain into multiple realms, and also that it doesn’t require any extra requests (other than the amcd itself), of course.

    As for meta tags, we had that in a draft spec before, but our security team didn’t really like it, so we took it out. I think we can make meta tags work if absolutely necessary, but we now see that as a last resort.

    April 27th, 2010 at 16:56

  15. Kroc Camen

    What about account cancellation / deletion? The spec should provide an optional value for an account deletion page to visit. It’s sad that you can sign up so easy to anywhere but more often than not it’s impossible to ever leave a site. Mozilla should also be encouraging sites to provide easy account cancellation too.

    April 27th, 2010 at 16:57

  16. […] today we announced that the Account Manager feature we’ve been working on is graduating from Labs into the […]

    April 27th, 2010 at 17:03

  17. Dan Mills

    Kroc,

    Agreed! That could easily be added as an extra method to the spec.

    April 27th, 2010 at 17:08

  18. Hans

    The mockups seem promising. I want to clarify that my concern isn’t so much about handling multiple accounts. I just want to be sure that inter-site tracking/profiling doesn’t become too easy because the manager is doing things behind the scenes. The mockups show phishing detection–I think that’s more in line with what I’m concerned about but I’m also concerned about all the facebook friend-connect buttons popping up all over the web. I think the word “automatic” is what gives me the jeebies. If I now understand correctly the automatic part is limited to detection of where to send bits, but the user experience is perhaps better described as simplified and streamlined rather than automatic.

    April 27th, 2010 at 17:31

  19. Jesse Ruderman

    The “well-known URIs” method introduces both security and performance problems. Why support it at all?

    April 27th, 2010 at 17:52

  20. Dan Mills

    Jesse, would like to hear more about why you think this would introduce problems. We’ve run this by several other security folks who are OK with it.

    Come downstairs sometime and we can chat :)

    April 27th, 2010 at 18:27

  21. Mike Jones

    Do you have a proposed syntax (and semantics!) for OpenID?

    April 27th, 2010 at 19:03

  22. Dan Mills

    Mike, not yet, but I’d love to hash something out!

    I think parts are pretty simple (RP says “I’m an RP”, basically), other parts not so much (OP has no way of telling the browser about success/not, and no way to automate). But basically, I think we should be able to get some kind of demo working as another profile of our spec.

    Object tags like in your last demo at the OpenID summit might be more difficult (?), because Account Manager doesn’t require the current page to have any login stuff–the recipes all get loaded from the AMCD separately. Might be interesting to think about this intersection, though!

    April 27th, 2010 at 19:26

  23. Justin L.

    What I’ve never understood about all of these keychain-type things is: What if I want to log into one of my accounts from a computer which doesn’t have the keychain software available? Do I have to go to another website (run by Mozilla, say), and copy-and-paste my password out? That’s not nearly as easy as just having one password for all of my accounts. :)

    April 27th, 2010 at 20:25

  24. Dan Mills

    Justin,

    In the majority of cases, that’s not necessary – specially if you use something like Weave sync. In the future, we may have a “guest mode” in Firefox that could pull some of these passwords down too (using Weave sync).

    But bottom-line is, you can still pick your own passwords if you like, we just want to make it easy either way :-)

    April 27th, 2010 at 21:27

  25. Kumar

    Very useful idea, but why not just make OpenId as a login standard? This tool won’t work beyond Firefox and I’m already on Chrome. So tomorrow, Chrome will have to come with something matching. Website owners will be clueless on which way to go.

    April 27th, 2010 at 21:59

  26. Tharaka Devinda

    Good as long as it doesn’t NAG us to save passwords every time it detects the JSON file and doesn’t do that without any knowledge of it doing so! Great feature. Thanks guys!

    April 27th, 2010 at 22:16

  27. Martin Kliehm

    Have you considered security from an anti-spam position? In WordPress direct requests to files are often prohibited, I believe they check the referrer to prevent spam. How would you prevent massive automated abuse by spammers?

    Talking about spam prevention, CAPTCHA is evil for accessibility. Why do you still use it when there are better methods or honeytraps?

    April 27th, 2010 at 23:34

  28. […] initial work has been taken to the next level with the Account Manager Add-on by Dan and […]

    April 28th, 2010 at 04:11

  29. Robert Accettura

    One thing the spec doesn’t make clear is how passthrough variables are handled.

    For example if you need to pass a site identifier to the authentication page (what’s normally a hidden param). Can I just do:

    “username”: “username”,
    “siteIdentifier”:”123″

    The specs only talk about Account Manager specific data from what I can see so far.

    April 28th, 2010 at 06:38

  30. Terence Johnson

    This is a great idea in principle, but please could you explain how this copes with CSRF protected login forms, or provides a similar level of security?

    Many CSRF protection mechanisms use some kind of salt or token to help to ensure that a real user is logging in, so just sending a username and password, even when they’re correct, would be rejected. I see there is a mention of a “secret” parameter in the specification – could you provide more information on how this is used?

    It may also be worth having a chat with the folks over at the PCI Security Standards Council, to make sure that this standard is compatible with theirs and can be used on sites that accept credit cards.

    April 28th, 2010 at 07:14

  31. Shirley V.

    It didn’t work for me, the icon shows grayed out.

    April 28th, 2010 at 08:21

  32. fpiat

    How do you plan to manage computer in public acces?

    April 28th, 2010 at 08:28

  33. AZ

    I really like the idea of having authenticiation implemented in browser, especially when it comes to phising. However, from reading the specs, it looks to me like anybody announcing the correct realm on its host can trick the browser to hand out its credentials (especially since autologin is explicitly wanted). This would even simplify phising attacks.
    There should be a way to block sending credentials to the wrong host. Since passwords should be send using https, the realm could be bound to one or more certificates (possibly even CAs), or the realm could whitelist/blacklist hosts or domains belonging to that domain. Updates to the realm then could be made by any host in the domain to allow for transition, though it would require versioning (or just timestamping).
    That way, the browser could default to binding the realm to the host it fetches it from, and sites like yahoo could still whitelist their cross domain servers.

    April 28th, 2010 at 09:15

  34. Dan Mills

    Kumar, we definitely want to see support for OpenID, as well as other authentication protocols (federated or not). Account Manager is meant to adapt to whatever auth mechanism you & sites prefer/have in common.

    Martin, much of what Account Manager specifies are interfaces which are *already* there. So we’re not really enabling new interaction, although we are enabling easier discovery. One minor exception is the ‘register’ method, where we do have a new API which could be spammed. However, I’m hopeful that the way we’ve designed it will allow websites to take appropriate spam-prevention techniques. Maybe I’ll blog on this later, it’s an interesting (but broad) topic!

    Robert & Terence, we don’t support passthrough params right now, though we do have one proposal for one use-case for them:

    https://groups.google.com/group/mozilla-labs-online-identity/browse_thread/thread/cf4be006297eb8f6

    Note that a salt doesn’t ensure it’s a “real user”, it just ensures the POST came from the same person/machine that did a GET a little while ago ;-)

    Shirley, jump in the forums and give us more info!

    fpiat, what did you have in mind? Account Manager doesn’t have any public-computer features right now.

    AZ, that’s not quite correct–if you trick Account Manager into pointing to a different AMCD, that is effectively a different realm, with its own set of credentials.

    The only way to “steal” credentials is to hijack the actual AMCD, and that would be equivalent to, say, hijacking your php scripts and collecting passwords that way.

    April 28th, 2010 at 10:44

  35. […] thrown down the gauntlet in the race to take charge of your online identity, saying it will soon add identity management features to its browser, and hopes at some point to build recommendation services into the browser as well. […]

    April 28th, 2010 at 11:16

  36. AZ

    Hi Dan,

    thanks for pointing ACMD=Realm out, I’ve somehow missed it. So then there is no way to transition the ACMD location, which makes this approach save but also requires appropiate UI to be able to manually perform transition (which is not a problem in FF using password manager I guess).

    April 28th, 2010 at 11:25

  37. Dan Mills

    AZ, indeed, that is a potential problem. Would love to hear ideas for that problem… we could potentially assist with some sort of migration, I’m not sure.

    April 28th, 2010 at 11:50

  38. Dan Mills

    Also related, what happens when a site changes its auth schemes. e.g., if Account Manager had been in place when Flickr switched to using Yahoo! logins, how could it have helped that transition? Would it have hindered it? We need to think through these questions, I think, to ensure we can adapt to what really happens in the “real world”.

    April 28th, 2010 at 11:52

  39. Dave Mackey

    This is a great idea. I think it makes a ton of sense. I do hope a tight integration with major providers like Facebook Open Graph, Google Friend Connect, and OpenID will be high on the priority list.

    April 29th, 2010 at 06:40

  40. Nikita

    Check your video integration code:
    <source type="video/ogg; codecs="theora, vorbis"
    That seems odd.

    April 29th, 2010 at 08:11

  41. rivey

    How does the browser verify the identify of the user? The local cache like data needs to be stored somewhere. Where is the cache of information stored? Can the cache of user data be stored somewhere secure and require the user to verify their identity against some sort of centralized directory (LDAP)?

    April 29th, 2010 at 08:32

  42. Jason

    Seriously, the well-known URI crap needs to go or at least needs to not be the only option. I think the meta tag is the best option and will be important if you really want widespread adoption among the long tail. But at least do the HTTP Headers thing. I do not want to add more files to my web root!

    April 29th, 2010 at 14:39

  43. Carlos J.Mills

    I am very proud of you Daniel
    You will go places.
    We love you
    Carlos and Marcia Mills

    April 29th, 2010 at 15:43

  44. […] Sync functionality (your data, encrypted on the server, it’s yours, not ours!), Contacts, Account Manager, Canvas, Video and a bunch of other technology where we’re leading the web where we want to […]

    April 29th, 2010 at 17:13

  45. Markus

    I thought one of the biggest security problems today was that “people are already logged in”! Think about it: $EvilGuy sends you a link to some site where you are a member and in which $EvilGuy has found a security breach and injected some javascript. If you click the link, all of a sudden the injected javascript has access to your information on that site, which might be your so called strong password or credit card number.

    I would like Account Manager to automatically log me off from sites after some amount of time. Is that possible? Just helping me log in will only make security worse.

    May 1st, 2010 at 04:06

  46. Kim A. Betti

    I think this is a cool idea! It’s also very simple to implement. In a couple of hours I was able to create a proof of concept plugin integrating this with the Apache Shiro Grails plugin (http://grails.org/plugin/shiro).

    My experiences: http://www.developer-b.com/blog/entry/556/2010/may/02/grails-shiro-adapter-for-mozilla-account-manager

    May 2nd, 2010 at 10:45

  47. Armen

    Dan,
    This link is broken:
    https://mozillalabs.com/blog/2010/03/account-manager/
    and the .xpi’s name is not representative (latest.xpi)

    This has been one of my most wanted feature for years! Good job!

    May 3rd, 2010 at 11:25

  48. Dan

    Why not support HTTP Auth properly (as well)? Just provide a button that will stop sending the Authorize header, and we all could just use HTTP Auth on the server side. It’s really crazy that no browser has ever built that in.

    HTTP Auth over SSL and Auth Digest are safe enough most of the time. The biggest problem is still the lack of a logout button IMO.

    May 3rd, 2010 at 11:32

    1. Ron

      The lack of a log out button on the browser can be handled from the server side by encoding the authentication state into the nonce specified by the server. If the nonce sent by the browser indicates the server has logged the user out, the request can be rejected with a 401 status with no stale flag. Per RFC2617, the browser will then ask the user for ID and password. Given that any attempt to access a server side resource protected by HTTP Auth or HTTP Auth Digest will result in a 401, presumably the server, upon accepting a request with some kind of log out request, will be a redirect to an unprotected resource. Later, when the user attempts to access protected resources again, even if the browser sends credentials, the nonce sent will either be too old or indicate logged-out, so the server will respond with a 401 with no stale flag, then the browser will ask the user to log in again.

      May 25th, 2010 at 23:59

  49. KOK

    Hi,

    great idea – I quickly wrote a simple MediaWiki extension – certainly not perfect yet, but seems to work for my wikis:
    http://www.mediawiki.org/wiki/Extension:AccountManager

    Cheers, KOK :)

    May 4th, 2010 at 08:29

  50. […] and posters, Summit, preparations for upcoming releases, new add-ons manager, etc. I've been trying Account Manager this week, and interestingly it installed right away for SeaMonkey and even works somewhat! Of […]

    May 4th, 2010 at 10:10

  51. […] been a couple of weeks since we originally posted about Account Manager and we’ve gotten a lot of feedback. We’ve got a few opportunities for people to get […]

    May 13th, 2010 at 16:01

  52. Simon B.

    @Dan re Basic Auth; Yes, really a great suggestion! That way this new login/logout feature would be useful immediately, and those using HTTP Basic Auth can stop closing down the whole browser just to unlogin as they are today accustomed to. And basic auth logout is still very much needed — even recent products like Netgear ReadyNAS use Basic Auth for remote file access.

    May 21st, 2010 at 03:46

    1. Ron

      Per my earlier reply to Dan, if Digest Auth is used instead, the log out can be handled on the server.

      May 26th, 2010 at 00:02

  53. […] kind of attack once again shows how important Mozilla’s work on the Firefox Account Manager in keeping you […]

    May 24th, 2010 at 16:15

  54. […] It is remarkable what the passage of time can do. Not only are we furthering common goals for the betterment of the web, as we have in the past, but now we’re both working in various capacities for Mozilla. Tantek will help us out with the CSS3 Flex Box Model, figuring out what the right thing to do with respect to stylable HTML5 form controls are, and help us with fundamental questions of identity and the open social web in connection with the account manager initiative in Firefox. […]

    May 26th, 2010 at 12:37

  55. Patrick

    It won’t catch on (firefox account management)….what if I’m not at my computer?

    May 27th, 2010 at 06:49

  56. Pigpromoter

    How and where do you fit Captchas in this authentication model?

    May 27th, 2010 at 23:44

  57. Frank

    How do you plan to incorporate authentication schemes where steps have been already taken to prevent passwords from being sent in the clear. One such technique is described here, but there are many others:

    http://srp.stanford.edu/

    May 28th, 2010 at 11:54

  58. Anthony DeRobertis

    Doesn’t this mean I’d have to give up CSRF protection of login requests? Or is there some way to tell the Authentication Manager request apart from all other requests?

    June 8th, 2010 at 20:40

  59. Simon B.

    @Anthony, if you’re thinking of checking session tokens and referer headers, then it seems a valid question. It does seem that people run a risk of implementing unprotected login methods meant only for account manager, which would be bad indeed.

    Obviously nobody should disable CSRF protection for the sake of Firefox. Account manager must not depend on that.

    Surely session tokens done as cookies will continue to work like always. That leats tokens inside a form (type=hidden and theoretically also url parameters) and referer headers. Perhaps add a referer: key to the JSON document? That same referer entry could be used to fish out tokens hidden in a form, but this seems an ugly hack and doesn’t really give much more protection than a session cookie.

    CSRF protection methods include http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention and blocking anything with headers application/x-www-form-urlencoded (ref: http://directwebremoting.org/blog/joe/2007/02/07/csrf_protection.html)

    June 15th, 2010 at 00:05

  60. Anthony DeRobertis

    Currently, I do CSRF protection via hidden form field (with a session-unique token, stored as part of the server’s session info). It doesn’t look like the login manager spec allows that; the login (“connect”) request has anything more than the username & password. So token-based CSRF prevention doesn’t seem possible.

    June 21st, 2010 at 10:01

    1. Preturi asigurari RCA

      “Whoops! What are you doing here?” the account manager page is not working..

      July 15th, 2011 at 01:46

      1. louisremi

        This experiment is being replaced by browserID. We will soon write about it on this very blog, but you can already find info on http://identity.mozilla.com/

        July 20th, 2011 at 07:05

  61. Macarthur

    This doesn’t seem to going to be working exactly one hundred percent to me. My site for example(still in the drafting stages) requires you to get a one time use form token that’s generated any time a user needs to login and it HAS to of course match the one on the serverside. Also i just looked over the comments and someone’s already said it for me. So good job in bringing the web back a step in security mozilla labs. Be sure to change it up to work with CSRF like methods as stated above or else only the most stupid sites will be doing it. Ie those that store passes in plain text(ie pizza hut and other online sites that i don’t give any “real” information too). Also what about those sites that are stupid and require a maximum length? What about that then mozilla labs? Also i hash my passwords in sha512 after adding in some obscuring(based upon the password input sot hat it’s the same each and ever time) how would this work out for me then? It’d not work out since you’re just going to be posting a plaintext password which = bad.

    To me, it seems like you guys are just trying to make it “seem” more secure than what it really is.Yeah the passes will be better but it sure as hell won’t help prevent a mitm attack since the passwords have to be posted as plaintext and with the many many ways to strip ssl relying on it alone isn’t going to be enough.

    Also i normally don’t comment or sign up on sites that use recaptcha since i am not google’s worker but this seems to be something that you as in you and all of the other firefox devs need to rethink.

    July 13th, 2010 at 07:40

  62. RCA ieftin

    How and where do you fit Captchas in this authentication model?

    October 29th, 2010 at 07:10

  63. Eivind

    Currently the account-manager page-link gives 404. Might want to look into that ?

    February 3rd, 2011 at 01:22

  64. […] 5 przyniesie menedżer kont, interfejs mechanizmu F1 Simple Sharing, animacje interfejsu i 64-bitową wersję dla […]

    February 8th, 2011 at 17:15

  65. […] presentata da Mozilla si chiama Account Manager, deve essere implementata nei siti web (vedi Account Manager coming to Firefox) dopodichè una persona potrà effettuare il login ma anche cambiare nome utente “con 1 […]

    September 8th, 2011 at 19:26

  66. Asigurari Locuinte

    Currently, I do CSRF protection via hidden form field (with a session-unique token, stored as part of the server’s session info). It doesn’t look like the login manager spec allows that; the login (“connect”) request has anything more than the username & password.

    October 3rd, 2011 at 22:00

  67. dambovita

    http://www.mozilla.org/en-US/firefox/accountmanager/ is broken.

    October 19th, 2011 at 04:03

Comments are closed for this article.