Hacker News Reader

Comment by mightybyte | Hacker News Reader

> whose to stop someone from cloning a Yubico key?

That is precisely what these devices are designed to stop. The device has a private key stored in hardware in a way that it cannot be retrieved by software. When you use one of these devices you dramatically decrease your number of attack vectors because now the attack has to happen physically. Someone has to actually steal your physical key. And because this is your "second factor", if that happens they still also have to have your password.

Two-factor apps get closer to this, but they usually can be copied. For instance, 1Password can be set up to mimic Google Authenticator.

> I do want to know if this is purely marketing hype

This is most definitely NOT marketing hype. It is the current security best practice.

View on HN

I didn't know about 1Pass, I've been a paying member for a while. I'll try that out! But to put a finer point on your actual statement, I usually screenshot the MFA setup in case my phone gets lost, so I can easily re-set it up.

With SAASPASS Authenticator you can set up recovery in case you lose your or change your phone.

For those who aren't aware, the author of the post works for them. Maybe a founder; it's a little hard to tell. I've run across him doing exactly this in the past. Bad form, and (having looked at it in the past) the product he's flogging is amateurish.

Do not store your 2FA codes in 1Password. It turns your second factor into the same one as your password.

I was storing backup codes in 1P before I realized that I was putting all my eggs in one proverbial basket.

Not quite - if someone steals your 1Password (or equivalent) database with TOTP seeds in, they need to crack the password on that, then have full access to everything. If they get the password from the other end (e.g. the site you log into), they can probably log into that specific site (they will have the TOTP seed), but not anything else. In general, there are more attackers looking at the site end than at the client password DB end.

Probably wouldn't be a bad idea to have a distinct password vault for TOTP seeds, although they'll be stored on whatever device you generate codes from anyway (hopefully in a secure way). At the very least, it might be helpful for moving between TOTP devices without needing to do the random steps required by different services!

Since, once unlocked, 1password as of version 7 stores everything de-crypted in memory, ANY attack on a host with an unlocked 1password keychain which can exfiltrate memory across processes can steal everything.

It's pretty obvious why this changed, however, it is a major increase in exposure and a terrible change overall. It is discussed in [1] and mostly the answers aren't very satisfying as demonstrated in [2].

[1] https://discussions.agilebits.com/discussion/101560/secure-m...

[2] https://discussions.agilebits.com/discussion/101551/article-...

Impresive, have they had external security firms try to steal the private key? Thats my final thought.

I guess it makes sense. By the time an adversary gets your key you would of noticed and have locked that key from your account.

> have they had external security firms try to steal the private key?

Definitely, it's an expensive vulnerability to simply reveal though. YubiKeys are proprietary so they can't be audited by non-contracted third parties. There are FOSS security keys that don't have that problem though.

Lockheed has a great deal of their MFA keys compromised because the factory that manufactured them had been breached for a while and nobody had noticed. Supply chain attacks are performed constantly against large, known entities and this case shows why they are so pedantic about security and justified in their paranoia. The problems have been execution of the policy and the costs of compliance.

Ah this sounds familiar... Probably saw the article here on HN ages back and forgot. I mostly ask cause I don't have one of these keys but if I were to consider getting one I'd want to know what a good option would be.

You should look for a vendor which understands that knowing the secret key inside the Security Key (that's how all the vaguely cheap ones work, they have a random secret AES key inside them, that's enough to do everything else securely) is a terrible idea and so they should arrange for the key to be chosen randomly and never recorded at all.

With SecurID and similar technologies vendors technically didn't need to retain the secrets inside those devices after they'd been manufactured and shipped, but you can see the practical temptation.

On a smaller scale, since the system doesn't use a shared secret you should just swap a brand new Security Key with somebody else or if deploying to an organisation just muddle them and let people pick whichever one they want. You don't care which key you have, the more random the better.

Reply on news.ycombinator.com