Save your Phantom wallet details in 1Password | Hacker News Reader

Save your Phantom wallet details in 1Password

blog.1password.com

32 pointstechiedude14 comments

Perhaps this is neat, but ultimately I’m seeing the effects of their ambition and lots of raised money. I have a feeling a majority of the things they’re going after won’t apply to me, meanwhile they’re really going to push 1Password 8.0+ on me, plus a monthly license for a cloud service I don’t want to use.

It’s too bad — I like 1Password7 and it’s one time purchase.

As a long time 1Password customer this is incredibly disappointing. I guess it is time to look at BitWarden.

How exactly is saving your crypto passphrase, passcode in a password manager disappointing?

I wish 1Password had ways to add additional layers of security to especially-sensitive content like crypto keys (like a separate password, or only downloading the content on a subset of your devices, or Yubikey to encrypt content).

I have so much stuff in 1Password, I'm terrified I'll get a virus that will steal my password + encrypted 1pass data.

As it stands, this is not something I'm willing to store in 1pass.

But then they'd have to rebrand to 2Password!

(I have the same fear though. I worry about having everything potentially compromised via a single string.)

There's a long thread about this on their official forums and that is basically their argument against it. And it's true that there's a high likelihood I could forget this second, rarely used password.

You can create a separate user and use a Yubikey to gate access to it, so access would be through your primary 1Password account (where the pass is stored) + Yubikey. I have multiple accounts to separate things out that shouldn’t cross pollinate.

A 1Password feature for it would be neat but I think you’d end up in a situation where there was always risk that the primary account could be used to gain access to the sub account in some way. I’d argue the best way to tackle this would be to assume 1Password itself is an attack vector and have an encryption key stored on a separate device and so what is stored in 1Password is encrypted (by you) can only be decrypted with your physical key.

Basically, if you can’t trust your digital self, you definitely can’t trust 1Password.

> have an encryption key stored on a separate device and so what is stored in 1Password is encrypted (by you) can only be decrypted with your physical key.

I think this is basically what I want, where my whole account is encrypted using my 1pass master password, and then a subset of it is also protected by my YubiKey.

I can definitely do this manually, but it's a pretty huge pain. I wish it was built in to the desktop client. I'm not really worried about 1Password being malicious; I'd believe them if they said the client was doing all this client side and not storing the additional password.

I still cannot quite understand why it's impossible for 1password to always require a second factor (i.e. yubikey or phone) to unlock the vault. I.e. I want to require a second factor when I turn on my laptop or when I return to my desktop next day. Lastpass allowed that.

It is possible but not that simple. The model is going to be a bit different because it will always require the server connection to perform the authentication. At the moment, 1Password does not require server connection to operate.

Also, 1Password would have to be changed to not store any data (or at least the vault keys) locally and then retrieve it from the server after unlock. Otherwise, it is going to be vulnerable to local attacks, without even going through the app.

We were brainstorming this feature when we first were designing the service. It certainly would be an interesting option, it just requires quite a few changes on both server and client sides.

In any case, "unlocking" in 1Password is always based on encryption not authentication. The second-factor authentication can only help the server reject the clients that fail to provide it.

Roustem Founder of 1Password

Thank you for the reply. It would be certainly be a useful feature.

I could see the various browser extension based password managers and wallets providing a public API "standard" to do this so that it doesn't have to be a choice of using one product or the other and it would have an immediate benefit to the end users as well as help drive adoption of these tools.

What about using a recurring pattern for your passwords by using an encryption from an information of your choice from the service you use, which you then tweak a little and add to a static base password.

That way only you know how to pull that information to generate your password, it's always unique, and even in the worst case scenario where multiple of your passwords get leaked, it'd still be extremely unlikely for someone to make any sense of it in order to figure out all of your unique passwords relying on that method.

You should use your imagination here but for an example of what that would look like, let's say you want a password for amazon.com

Step 1 - Hash ''amazon'' or any variation based on their name that you can reproduce for other services

You can use md2, md5, sha256, doesn't really matter what you chose, you could even create your own. Let's say we use sha256, you're given the following:

  cbc62794911ff31b2864ecd3dbbbee7ebcb7ea41c5a42e2cba377f3cfdb42811

Step 2 - Decide what your pattern will be

A simple example could be to pick whatever character is at index 3, 5, 12 and 16 once from the beginning of the hash and once from the end, which gives you 8 characters. Then you just make those your unique key for your amazon.com password, in our case:

c2fb847b

All you have to remember is the hash you used and 4 letters, in this example. But as I mentioned, you could be imaginative.

Step 3 - Get a base password that ressembles whatever results you get from your hashing method

This will be the password you will have to remember, nothing new here. Example in our case:

  m188ct3q

Step 4 - Fusion both

Again you can implement this however you like based on how secure you want it to be relative to how likely you are to remember this and how time consuming it is to apply in practice, you'd be fine by simply joining them next to one another:

  c2fb847bm188ct3q

Thoughts?

> Thoughts?

Honestly, I hate it.

Why select a few chars of the hash instead of using something like hash(argon2(password) + domain)

Anyway FIDO tokens and WebAuthn are the future. They do a better version of this in addition to eliminating phishing, replay attacks, etc.

Reply on news.ycombinator.com