To protect your privacy: email us with billing or account questions instead of posting here.

Chrome log-in: E-mail, password AND account key at each log-in?

Options
qooter
qooter
Community Member
edited January 2017 in Memberships

Hi there,
I've been using the stand-alone version 4 for 2 years now. Today I have changed to using an online account with version 6 on my windows desktop.
Whenever I start chrome trying to log-in online under my.1password.com I always have to give e-mail, password AND account key! Is that the way it's supposed to be? Kind of weird - especially because the browser add-in automatically inserts e-mail and password BUT NOT the account key.
Did I miss something?
Greetz from Germany,
Michael

PS: When I have logged-in successfully and open new log-in windows the account key is there. So the problem only occurs whenever I start chrome fresh!


1Password Version: 6.2333d
Extension Version: 6.2333d
OS Version: windows 10 64-bit
Sync Type: agile account
Referrer: forum-search:Account key at chrome log-in

Comments

  • Hi @qooter - Thank you for reaching out to us. Most of the time you don't have to re-enter the account key since the browser caches this information. Are you using incognito mode? Or are you clearing your history after closing Chrome? Sorry for the questions, just want to get a better understanding of the issue. Keep me posted and I look forward to hearing back. Have a great day!

  • qooter
    qooter
    Community Member
    Options

    Hi Frank,
    Thanks for your reply. Yes, I'm clearing the "history and all" when I close my browser. So that's the reason why? If so, wouldn't it be better to use 2-way-authorization with the help of one's mobile? Getting the account key every time is really not so much fun - and not clearing the browser's cache is out of the question.
    Or is there a way to keep single info in the browser's history (like 1password info)?
    Greetz from Germany,
    Michael

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    Thanks for your reply. Yes, I'm clearing the "history and all" when I close my browser. So that's the reason why? If so, wouldn't it be better to use 2-way-authorization with the help of one's mobile?

    @qooter: SMS is incredibly insecure, so that's not really a direction we want to go.

    Getting the account key every time is really not so much fun - and not clearing the browser's cache is out of the question. Or is there a way to keep single info in the browser's history (like 1password info)?

    I hear you! I'm not certain there's a way for Chrome to clear all but certain sites' data. Are you clearing everything? I wonder if unchecking the "hosted" option will help in your case. Perhaps there's some other tool that could give you more fine-grained control. Otherwise though, what you're asking is impossible: to wipe out the browser's storage after each session, but also have 1Password keep your Account Key in the browser's secure storage so you don't have to enter it each time. You just can't have it both ways.

    Personally, I use Incognito mode for most browsing, so you could use that for everything but 1Password.com. Or you could use a separate browser only for 1Password, and then you can keep wiping out Chrome til your heart's content. ;)

  • alexvy86
    alexvy86
    Community Member
    Options

    So the Account Key is being cached by the browser? And stored how, exactly? This sounds like a relatively weak spot where an attacker could get hold of the Account Key, no? I'm

    Could the Account Key be set by communicating with the local client (through the extension, I suppose, since there is no other way) to retrieve it?

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    So the Account Key is being cached by the browser? And stored how, exactly? This sounds like a relatively weak spot where an attacker could get hold of the Account Key, no? I'm

    @alexvy86: If someone can get access to the browser's local storage on your machine, they don't need to worry about any of that; they own your machine, and can simply install whatever they want and collect all of your data.

    Could the Account Key be set by communicating with the local client (through the extension, I suppose, since there is no other way) to retrieve it?

    Maybe, but I think in that case it would make sense to simply use the native app instead. The web app is meant as a means to access your 1Password.com account when it isn't possible to install a native app, so I'm not sure what this would solve. The native apps are always going to be a better option since they can be signed, and limit the attack surface by not operating in your browser. There was a rather extensive discussion on the security of the web interface that might interest you. Cheers! :)

  • alexvy86
    alexvy86
    Community Member
    Options

    You're right about the second point. About the first one, I agree that if someone owns the machine then all bets are off, but I was thinking of an attack "local" to the browser (coming from within it, if that makes any sense; not from outside it, i.e. the OS), that could compromise the browser's local storage. This is not my area of expertise, so I'm not even sure if it's possible, or how, but that's where I was coming from. Since it's so important to keep the Account Key (now Secret Key, from what I've read) private, basically known only to the apps (since not even the users are expected to know it), I just find it weird to let the browser store it. I understand letting the local apps do it, since they absolutely need it to do their primary job, and you (AgileBits) have complete control over the code and (many of) the risks, but when it gets stored by the browser it just feels like it's not as safe.

    For the record, I'm very happy with 1Password, in fact I just added my credit card to start billing my subscription :). And I'm looking forward to an updated version of the white paper.

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    You're right about the second point. About the first one, I agree that if someone owns the machine then all bets are off, but I was thinking of an attack "local" to the browser (coming from within it, if that makes any sense; not from outside it, i.e. the OS), that could compromise the browser's local storage. This is not my area of expertise, so I'm not even sure if it's possible, or how, but that's where I was coming from.

    @alexvy86: Ah, got it. That's an interesting distinction, but in general we need to assume that an attacker is pretty sophisticated. In practice, if the browser can be compromised in such a way as to allow access to files stored on the local machine, such exploits will be leveraged to gain access to the rest of the system as well. Desktop OSes were designed to work like this from the beginning, and steps taken to lock things down have been slow and small, since there's huge legacy baggage. Except on newer platforms with sandboxing and a tight security model by default (e.g. iOS), if an attacker can access one thing in the local file system we should assume they will be able to access the rest as well. You raise a good point, but I think we're all better off if we plan for the worst and hope for the best. :)

    Since it's so important to keep the Account Key (now Secret Key, from what I've read) private, basically known only to the apps (since not even the users are expected to know it), I just find it weird to let the browser store it. I understand letting the local apps do it, since they absolutely need it to do their primary job, and you (AgileBits) have complete control over the code and (many of) the risks, but when it gets stored by the browser it just feels like it's not as safe.

    The Secret Key is very important, but it is only one thing which is needed to decrypt the data since the Master Password is also used to encrypt it. If everything hinged on the Secret Key, then you'd be right that storing it in the browser would be a terrible idea. There are kind of layers here though, and I find it helpful to think of it this way with regard to what pieces are needed to access my 1Password data, and how they're handled:

    1. Database — stored on the server, and cached locally on my authorized devices; encrypted locally on the device, transmitted via SSL/TLS.
    2. Master Password — (optionally) stored in the device Keychain when using Touch ID; chosen by me, never transmitted.
    3. Secret Key — (optionally*) stored in the browser, stored within authorized apps; generated locally on my device, never transmitted.
      *You can always check "This is a public or shared computer" when logging into the website to not have it saved locally.

    So, in practice, the instance where all of these would be saved locally on a single device would be with an authorized app using Touch ID. And even in that case, the Master Password is obfuscated, the Secret Key is encrypted, and both are stored separately, therefore requiring separate attacks to obtain them — and again that assumes the attacker has access to the system in the first place. Ultimately, none of these protections are perfect on their own, but in conjunction they make gaining access to our secure data infeasible in most cases, and still very difficult even with privileged access to the machine. And it's good you're thinking about these things, as that enables you to make informed decisions with regard to your own security. :)

    For the record, I'm very happy with 1Password, in fact I just added my credit card to start billing my subscription :). And I'm looking forward to an updated version of the white paper.

    Me too! I think there's a new version of the white paper about ready to go, so I'll let you know as soon as I see that it's live.

    Thanks so much for the kind words, and your continued support. Looking forward to any other questions, comments, or feedback you have! :chuffed:

This discussion has been closed.