1Password for Mac Updated With Apple Silicon Support

[Agrailag]

subscription = NO SALE. I paid full price for BUYING this software now I MUST subscribe to upgrade it! WTF

Suppose you purchase license, and there is some point in agreement about possibility of dropping support by devs.

 

[applicious84]

It's good. You won't look back.

The beauty of open source is that not everyone has to read everything all of the time.

Yeah, Logmein strikes again. I used LastPass forever. Dumped it over their new policy and went with Bitwarden. Bitwarden seems to work just fine and the transition was very easy. Just download a .csv from LastPass and import to Bitwarden. I'm baffled by Logmein's thought process. They would have been better off just limiting the number of devices of any stripe for the free program, rather than something as ridiculously silly as making it PC or Mobile. But Logmein has done silly stuff like this before. It's amazing they are still around, chasing away their customers as they do when open source is available these days...

I've been using Bitwarden almost since I posted. It's great! It's even better for me than LastPass, which I really liked. It's fewer clicks to get to things I need, and the csv upload worked perfectly. I think LastPass is great application. I wouldn't have even looked if not for changes in membership

 

[iObama]

Anyone seeing 7.8 in MAS yet?

 

[Apple_Robert]

Anyone seeing 7.8 in MAS yet?

Not in the U.S. store.

 

[johnalan]

I work as an applied cryptographer, `AES-GCM-256` isn't the "gold standard" of symmetric encryption.
When used properly with a per instance key, nonce tuple, its fine, but I would opt for XChaCha20-Poly1305 instead every time I reach for a stream cipher.

Their use of PBKDF2 instead of Argon2 as a password based key derivation mechanism is also questionable, lack of ASIC resistance etc.

Why do you think their choices are particularly good?
I can tell you I definitely wouldn't rely on 1Password.


There are other sub-optimal choices with regard to cryptographic primitives use by 1Password, like I said, it's fine (if you believe they implemented it all correctly), but it's not open-source.

@jinnj all you do is dislike people's posts criticising 1Password - do you work for them?

Can you respond to my post above and explain what you disagree with?

 

[Snørrbjørg]

I don't expect free software. However, if I can pay a one-time fee and get the same features that I was getting with 1Password, I will pay the one-time fee.

1Password has a one time fee option, no need to subscribe.

 

[Steve121178]

Yeah, Logmein strikes again. I used LastPass forever. Dumped it over their new policy and went with Bitwarden. Bitwarden seems to work just fine and the transition was very easy. Just download a .csv from LastPass and import to Bitwarden. I'm baffled by Logmein's thought process. They would have been better off just limiting the number of devices of any stripe for the free program, rather than something as ridiculously silly as making it PC or Mobile. But Logmein has done silly stuff like this before. It's amazing they are still around, chasing away their customers as they do when open source is available these days...

To be fair, what LastPass offered for free was too good. They are a business and exist to make money after all & I'm sure many users will now pay for the service and others will move on to a free alternative.

I don't think it's "silly" what they did. If people want something good, you pay for it otherwise it becomes unviable to sustain & everyone loses.

 

[jpgoldberg]

You raise some very valid points. I'm happy to talk about our choices with respect to cryptographic algorithms and constructions (as I played a significant role in choosing them).

I work as an applied cryptographer, `AES-GCM-256` isn't the "gold standard" of symmetric encryption.
When used properly with a per instance key, nonce tuple, its fine,

You are absolutely correct that per instance keys and unique nonces are essential to using GCM correctly. One of the things that we have done in our code base is provide our developers with an interface that takes care of all of that, so we can more strongly guarantee that GCM is used safely.

If you dig in deeply, you will find that we use AES-GCM-256 in places where we are "only" after 128 bit security. This is because we want to confront developers with having to know when to use which. Similarly, we used cryptographically secure RNGs even when those aren't necessary to avoid having developers deciding when they need one.

but I would opt for XChaCha20-Poly1305 instead every time I reach for a stream cipher.

We are using block ciphers here. We could get away with stream ciphers in some places and key wrapping constructions in others, but again decided that the performance and memory advantages of those aren't worth the potential for error. So it is AES-256-GCM for every symmetric encryption, even if it is overkill.

But I have to also address another big constraint in algorithm choice. We needed things for which there were trustworthy and readily usable libraries for all of our clients. These ranged from Android, Windows, Mac/iOS, and a web-client. So for the most part, what was available in WebCrypto was what we had to choose among.

Things are changing, as WebAssembly is becoming more practical and safe. But I am sure you understand the virtues of not rolling our own and of trying to go with what is most natively available.

Their use of PBKDF2 instead of Argon2 as a password based key derivation mechanism is also questionable, lack of ASIC resistance etc.

I was honored to be involved (well, more of a lurker on the mailing lists) in the password hashing competition that lead to Argon2. It certainly wasn't ready at the time we had to make our design choices, so the memory-hard KDF we looked at was scrypt. Ultimately, we were constrained by the availability of optimized implementations for all of the client platforms. PBKDF2 has its problems (in addition to not being memory-hard), but those problems are known and worked around in good implementations everywhere, and it was the only one available for our web client.

There are other sub-optimal choices with regard to cryptographic primitives use by 1Password, like I said, it's fine (if you believe they implemented it all correctly),

"sub-optimal" is not the same as "poor". And in most cases, we had to consider availability of good, trustworthy, implementations as part of our optimizing. So what might appear sub-optimal from one perspective is not necessarily the case when having to include other constraints.

> it's fine (if you believe they implemented it all correctly),

As I've suggested, some of the choices were governed by what we felt we were confident we could use correctly. And using what was natively available for our different platforms was part of this. You are also correct that counter modes, such as GCM, can be what I call "brittle": Using them a little bit wrong can lead to very bad consequences. We were fully aware of that when we made the choice. Quite honestly, GCM was the only game in town to give us authenticated encryption on all our platforms, without creating enormous complexity of linking in various different libraries on different platforms. As such, we had to take care to use it correctly.

but it's not open-source.

True. And this is for intellectual property reasons. We do attempt to be as open about 1Password as we can given those constraints, and we try to keep as much of what we claim about security to be independently verifiable. This is on top of our regular external reviews.

I realize that "as much as we can" and "regular external reviews" may not be enough for everyone. But I hope that you realize that our choices, even if you disagree with some of them, are reasonable and well-reasoned.

 

[johnalan]

You raise some very valid points. I'm happy to talk about our choices with respect to cryptographic algorithms and constructions (as I played a significant role in choosing them).

You are absolutely correct that per instance keys and unique nonces are essential to using GCM correctly. One of the things that we have done in our code base is provide our developers with an interface that takes care of all of that, so we can more strongly guarantee that GCM is used safely.

If you dig in deeply, you will find that we use AES-GCM-256 in places where we are "only" after 128 bit security. This is because we want to confront developers with having to know when to use which. Similarly, we used cryptographically secure RNGs even when those aren't necessary to avoid having developers deciding when they need one.

We are using block ciphers here. We could get away with stream ciphers in some places and key wrapping constructions in others, but again decided that the performance and memory advantages of those aren't worth the potential for error. So it is AES-256-GCM for every symmetric encryption, even if it is overkill.

But I have to also address another big constraint in algorithm choice. We needed things for which there were trustworthy and readily usable libraries for all of our clients. These ranged from Android, Windows, Mac/iOS, and a web-client. So for the most part, what was available in WebCrypto was what we had to choose among.

Things are changing, as WebAssembly is becoming more practical and safe. But I am sure you understand the virtues of not rolling our own and of trying to go with what is most natively available.



I was honored to be involved (well, more of a lurker on the mailing lists) in the password hashing competition that lead to Argon2. It certainly wasn't ready at the time we had to make our design choices, so the memory-hard KDF we looked at was scrypt. Ultimately, we were constrained by the availability of optimized implementations for all of the client platforms. PBKDF2 has its problems (in addition to not being memory-hard), but those problems are known and worked around in good implementations everywhere, and it was the only one available for our web client.


"sub-optimal" is not the same as "poor". And in most cases, we had to consider availability of good, trustworthy, implementations as part of our optimizing. So what might appear sub-optimal from one perspective is not necessarily the case when having to include other constraints.

> it's fine (if you believe they implemented it all correctly),

As I've suggested, some of the choices were governed by what we felt we were confident we could use correctly. And using what was natively available for our different platforms was part of this. You are also correct that counter modes, such as GCM, can be what I call "brittle": Using them a little bit wrong can lead to very bad consequences. We were fully aware of that when we made the choice. Quite honestly, GCM was the only game in town to give us authenticated encryption on all our platforms, without creating enormous complexity of linking in various different libraries on different platforms. As such, we had to take care to use it correctly.


True. And this is for intellectual property reasons. We do attempt to be as open about 1Password as we can given those constraints, and we try to keep as much of what we claim about security to be independently verifiable. This is on top of our regular external reviews.

I realize that "as much as we can" and "regular external reviews" may not be enough for everyone. But I hope that you realize that our choices, even if you disagree with some of them, are reasonable and well-reasoned.

Thanks for the detailed reply, it sure sounds like you've put thought into your engineering choices. It also sounds like you are talented/have a talented team.

I didn't intend to disparage 1Password, instead I intended to disparage some of the fanboyism declaring that 1Password's security was somehow a gold standard over and above average industry choices.

 

[jinnj]

@jinnj all you do is dislike people's posts criticising 1Password - do you work for them?

Can you respond to my post above and explain what you disagree with?

Sorry ran out of down votes... Here's yours LOL!!!!!

 

[CLS9]

1Password has a one time fee option, no need to subscribe.

Untrue. 1Password 7 requires a subscription. I'm still using 1Password 6 (the last software download version) which apparently is not compatible with Monterey so I'm looking at other options.

 

[Snørrbjørg]

Untrue. 1Password 7 requires a subscription. I'm still using 1Password 6 (the last software download version) which apparently is not compatible with Monterey so I'm looking at other options.

It was still true in mars. Why quote such an old post?

 

[aajeevlin]

Untrue. 1Password 7 requires a subscription. I'm still using 1Password 6 (the last software download version) which apparently is not compatible with Monterey so I'm looking at other options.

Um...I'm not sure what you mean by that. I have the Apple M1 with Monterey, have not had any issues with 1password6 at all.