Hacker News Reader

Comment by meroje | Hacker News Reader

1password does mitigate it to some extent by automatically copying the code to your clipboard after filling the form, these 2 things only work on the right domain. Of course you can still copy the values from the app but at least it hints at things being wrong.

View on HN

I always wondered what was the point of using 1Password for 2FA. After all, if you store your 2FA secrets in 1Password to generate codes, you've just reduced your 2FA to one factor?

While that's true because you have a single point of failure, I think it's more likely that your passwords get leaked through site security than 1Pass security (depending how you sync/if you use their cloud version) so it's still more (not the most) secure because if they find your password in a database they still don't have your 2FA code.

If you're using a password manager to have unique passwords for every site, what does TOTP 2FA even protect you against?

Since 2FA only comes into play for protection if the password is compromised, if you're using a password manager that should mean that data breaches at unrelated sites shouldn't be a risk.

So we're down to phishing and malware/keyloggers being the most likely risk -- and TOTP offers no protection against that. If you're already at the point that you're keying your user/pass into a phishing site, you're not going to second guess punching in the 2FA code to that same site. I'd even argue push validation like Google Prompt would be at a significant risk for phishing, unless you are paying close attention to what IP address for which you're approving access.

> If you're using a password manager to have unique passwords for every site, what does TOTP 2FA even protect you against?

Man in the middle attacks of course, which are possible on insecure connections. With the prevalence of root certificates installed on people's computers as a corporate policy, by shitty anti-viruses, etc, it's very much possible to compromise HTTPS connections.

The TOTP 2FA code acts as a temporary password that's only available for a couple of seconds. A "one time password" if you will.

Yes, it still strengthens security.

Read 1Password's article about it: https://blog.agilebits.com/2015/01/26/totp-for-1password-use...

If there's a MitM attack, you've already lost. Sure, they can only login one time, but they're in once you provide the authentication steps.

Phishing sites collecting and using the 2FA creds in real time was discussed here, among other places: https://security.stackexchange.com/questions/161403/attacker...

With available open source like https://github.com/ustayready/CredSniper readily available, you're only going to stop lazy phishing attempts.

You only get protection if you assume the scripts are just passively collecting information for use at a later time. If they're actively logging in to establish sessions while they're phishing, it's game over.

Yeah that's why codes don't make for a good second factor. You should use something like Fido or a client cert such that a MitM can't continue to impersonate the client.

But don't many sites require a second authentication to modify access to the account (change password, add collaborator, etc)? In that case, an attacker would need a second one-time code.

Normally I believe they just require the password. The threat model there is someone leaving their account logged in.

> Normally I believe they just require the password.

Shoot, you're right. Not sure what I was thinking. My bad.

This would make sense if virtually every website in the world didn't react to the short-term TOTP secret by handing back a long-term HTTP secret.

If there's no point improving client authentication until you've improved website security and no point improving website security until you've improved client authentication then neither will ever get better.

> If you're using a password manager to have unique passwords for every site, what does TOTP 2FA even protect you against?

Sounds a little obvious to write it out, but it protects against someone stealing your password some way that the password manager / unique passwords doesn't protect you against. Using a PM decreases those risks significantly, mostly because how enormous the risks of password reuse and manual password entry are without one, but it certainly doesn't eliminate them entirely.

This is the thing I struggle with: name a scenario where you would have your unique site password compromised but not have at least 1 valid 2FA code compromised at the same time.

The best answer I have for where TOTP can provide value: you can limit a potential attack to a single login.

I wanted to say you could stop someone doing MitM decryption due to timing (you use the 2FA code before they can), but if they're decrypting your session they can most likely just steal your session cookie which gets them what they need anyway.

Because you accidentally type your password for site A into the login for site B.

Someone “hacking” the 1Password web service

Logging in to a site on a public computer and the browser auto-remembers the password you typed

A border agent forcing you to log into a website (this scenario only works if you leave your second factor, which will most likely be your phone, at home)

Usually in a higher security environment, we'll make sure the authenticator is a separate device (phone or hard token) and expressly forbid having a soft token on the same device that has the password safe.

It's not at all obvious to me, because 1Password passwords are stored in the exact same places that 1Password-managed TOTP codes are. You might as well just concatenate the TOTP secret to your password.

which is why I'm wary of using my password manager for OTP, and use a separate one. Not sure if it's too paranoid, but it doesn't make sense to me to keep the 2 in the same place.

There appear to be two points being conflated — 1/ 2FA via secrets stored on a separate device from your primary device with a PM provide more security than those stored on one device, and 2/ once you use a PM with unique password for every site, much of what OTP helps with for is already mitigated.

Both seem true, and what to do to protect yourself more depends on what kinds of attacks you're interested in stopping and at what costs. Personally, PM + U2F seems the highest-security, fastest-UI, easiest-UX by far — https://cloud.google.com/security-key/

Having a TOTP secret would protect against theft of credentials in transit. The TOTP is only valid once, so that credential exchange is only valid once. They wouldn't be able to create any additional login sessions with the information they've attacked. However, there's a good chance if they could see that they might also be able to see a lot of other information you're exchanging with that service.

It creates a race condition in transit - if they can use the code before you, then they win. I can intercept at the network level, but also via phishing attacks - there is no domain challenge or verification in TOTP.

I know having someone malicious get into your account multiple times vs once is likely worse, but its hard to quantify how much worse it is - and of course using that one login to change your 2FA setup would make them equivalently bad.

Not quite exactly "equivalently bad", since a user is more likely to notice a 2FA setup change than they are a phishing site's login error and then everything working as usual, but yeah, perhaps it's splitting hairs at that point.

If you're using 1p password for storing your passwords, then yeah, it would make sense to use something else for your TOTP.

You may not be the best example of how this can help, sounds like you have good security sensitivity.

Where I'm working now, we deal with several credential loss incident each month. Invariably, our users are tricked into authentication via a bogus site. 2FA would protect the credentials from being used by unauthorised people. Our staff are encouraged to use password managers, but that does not help this situation.

TOTP can protect against knowledge leakage as it is a second factor. For example, it will prevent someone successfully using a shared password a LinkedIn, associated with a corporate email address, to log into Gmail/O365.

It doesn't prevent any sort of active phishing campaign, because the login process can just ask for and immediately use the TOTP credential. User gets a possible failure (or just content based on what they thought they were accessing), phisher gets account access.

The point is that one time passwords are only valid once. If your password is stolen, it's stolen. If a TOTP code is stolen, it's probably not even useful because it's already invalid when they log in (including for time based, in well-designed software.)

There's obviously a class of attack that hardware tokens protect against (malware) that password managers can't entirely (unless your operating system has good sandboxing, like Chrome OS for example.) But it really does protect against phishing to a degree, as well as certain attacks (key loggers or malicious code running on a login page on the browser)

Hardware tokens are the winning approach, but even when you put TOTP into a password manager it is far from useless.

It only protects against the most naive phishing attacks, where the attacker just accumulates passwords for use at some later date. More sophisticated phishing attacks will just copy the OTP in real time:

https://www.schneier.com/blog/archives/2015/08/iranian_phish...

U2F defends against that sort of phishing as well.

Sure, but most people aren't targeted by advanced adversaries, so using your password manager for TOTP can be a lightweight way to make most hackers completely disinterested in attacking your account. U2F requires an additional investment. Depending on the type of physical security you want, it's normally a good idea to invest in at least n+1 U2F keys, so you have a spare key you can keep with you and permanent keys in all of your devices. (Obviously, the latter means that your U2F can be stolen easier, but the reality is that this is not nearly as big of a deal as stealing a password, since you can unprovision a U2F key immediately upon realizing that it's gone.)

Proxying the authentication isn't really an "advanced" attack. In a 19 minute video[0] the author of CredSniper[1] gives a complete walk-through for setting up his proof of concept tool, including building the login pages and registering for LetsEncrypt SSL certs. The hardest part still remains choosing the domain name and getting people to click the link, and still people find ways to overcome those hurdles.

As TOTP use has increased, the basic phishing toolkit has evolved to match. Attackers want accounts, not passwords, so they're just adjusting to get working sessions. The passwords were only ever just a means to an end.

[0] https://www.youtube.com/watch?v=TeSt9nEpWTs [1] https://github.com/ustayready/CredSniper

That attack doesn't work when using 1password. 1password refuses to fill on the wrong domain.

It's not multi-factor auth.

Most of the smartphone based solutions are two-step auth -- it's just a different kind of secret that you know. If you use 1Password or Authy, your token is your 1Password/Authy credential.

The hardware based token approach is always going to be better, because the secret is part of the device and isn't portable. The Yubikey and challenge/response tokens are great as you need to have it present, you cannot easily get away with hijinks like putting a webcam on your RSA token.

I’d say that a separate phone app with MFA codes that are only stored offline qualifies as a second factor, as you need both the phone and it’s access code (fingerprint etc.) to see the code.

It can, but users have the ability to undermine those controls in many cases via Authy, 1Password, etc.

I think 1password discourages it too, the option to add a 2fa code is pretty hidden.

Marking something as "2FA enabled" is super easy in comparison.

If you're not tracking your 2FA code through 1Password you get a big warning banner[1].

[1] https://i.imgur.com/uENh9oL.png

Just add the "2FA" tag and the banner goes away :)

I was saying doing that is easier than adding 2FA through 1Password.

You could also use two separate systems for password and TOTP storage - one gets passwords, one gets TOTP, and the one with passwords explicitly does NOT get the password for your TOTP storage.

I consider possession of my device and a knowledge challenge in the form of the password and pin to be two factors. Use of a biometric in lieu of password is also two factors.

I don't see a way in which having the possession factor be on my keys is stronger than having it be in my laptop. In fact, for sites that require it my U2F key is in my laptop (Yubikey nano-C).

(Aside: That doesn't limit the usefulness of having a possession factor that is portable between devices, just I don't think it is necessarily stronger)

This is actually why I very rarely opt into the 2FA features of websites - I figure I already have two factors protecting me, but not necessarily factors recognized by the site.

If you're using 1Password-generated passwords and storing TOTP codes in 1Password, how are the TOTP codes not just theater?

Parent's argument is that it mitigates phishing - i.e your normal workflow is you go to a site and your credentials are automatically filled in, so you'd be suspicious if that doesn't happen. In my experience, the autofill breaks so much that I've started copying my password in manually all the time.

The TOTP code does not add anything to phishing mitigation.

Depends on the exact attack. If its a full MITM (including TLS), no. If its a fake website who don't forward after password-based authentication, yes. U2F would also detect the domain is incorrect, though so does my password manager. Though that's based on a browser extension. I suppose if the browser gets mislead, as would the password manager. And that did happen with LastPass (XSS attack IIRC).

> In my experience, the autofill breaks so much that I've started copying my password in manually all the time.

FWIW, this has not been my experience with 1Password at all.

I use LastPass but have had the same experience - autofill is very, very reliable

They are time-limited, at least? But yes, I've had similar arguments with coworkers who've started using 1Password for TOTP in the same way.

Normally I would reply back and explain, but you know more about this than I do, so instead I will ask a question.

Does it not protect against your password being compromised in some other channel? Sure you're probably not reusing passwords, but what if they compromised it some other way? What if the website had a flaw that allowed someone to exfiltrate plaintext passwords but not get at other application data?

Or to put it another way, if you're using a password manager, why use TPOP codes at all if you believe there are no other attack vectors to get the password that TPOP protects against?

The website and the password manager in this scenario are storing the exact same secrets. If you're going to store them in a password manager, it is indeed reasonable to ask "why bother"?

TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.

But the secrets serve different purposes, they aren't the same. So why not keep them in the same place? I'll admit that it is less secure of course, since someone could compromise your 1Password. But it is still more secure that not using TPOP at all, is not?

Again, is there no attack vector that exists that makes TPOP worthwhile when you're already using a password manager that makes it not worthwhile if it's in your password manager?

I'm not really sure I see how storing TOTP secrets in 1Password is materially any more secure than not using TOTP secrets and just letting 1Password generate a random password for that site.

Ok, so you don't see any use for TPOP when using 1Password then?

The issue is with storing your TOTP secret in the same store as your password. The idea of using MFA is that multiple secret stores must be compromised in order to grant access to a service.

If you put your TOTP secret on your phone (or Yubikey), then both your TOTP secret store (that is your phone or keychain) and 1Password store must be compromised in order to gain access to your account. TOTP is useful in this scenario.

If you put your TOTP secret in 1Password along with your site password, then only your 1Password store needs to be compromised. This is the scenario where TOTP becomes pointless.

Isn't that a less likely scenario? Or at least, a subset of the possible compromises, meaning you have materially improved your security in _some but not all_ cases. I don't disagree that it's best to not have TOTP in 1password, but isn't it still _better_ than not having TOTP at all?

I understand that, but it isn't it still better to store it in 1Password than not have TPOP at all? At least you're still protected against other attacks, right?

Marginally sure, but what "other attacks" are you looking to protect against?

Most MITM scenarios are going to result in giving up at least one TOTP code -- and that TOTP code will be used to obtain a long-lived HTTP session (I can't remember when Google last had me auth).

I think it's common for folks to think that TOTP means it's safe to lose a code because it is short-lived and invalidated when a subsequent code is used (usually), but it just takes one code for a long-lived session cookie to be obtained.

If an attacker is in the position to intercept your password via MITM, Phising, whatver, they're in position to intercept your TOTP code. They're not going to sit on that code -- they're going to immediately use it to obtain their long-lived session while reporting an error back to you.

No, I use TOTP and I use 1Password. But my TOTP secrets live in Duo's iPhone application.

And I also store them separately. But don't you agree that storing them in 1Password is still better than nothing, as there are still some use cases that you are protected against that way?

No, that's where you lose me. If you're using 1Password to generate passwords in the first place, then I really don't see how using it for TOTP accomplishes anything. To me, it looks like you could literally concatenate the TOTP secret to the 1Pw-generated password and have the same level of security.

In particular OTP codes are intended to be single use they're a ratchet. If a site does this properly then any OTP code you steal from me is not only worthless when it naturally expires, it's also worthless once I use that code or a subsequent code to authenticate. If you used a passive keylogger that may mean by the time you get the key events that OTP is already useless. Likewise for shoulder surfing attacks.

TOTP != HOTP

Nevertheless, RFC 6238 (TOTP) specifically tells implementers that:

Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.

The question is whether there is any point in having an OTP secret if it's stored in the same location as the password.

We're not talking about stealing single codes, but the entire secret.

With HOTP the answer is yes, because of ratcheting. A clone of the secret doesn't let you impersonate the original device, because their counters will conflict as both are used.

With TOTP the answer is no. You can make codes freely, and the clone is indistinguishable from the original.

The rule you cite is basically irrelevant. It just means that original and clone can't log in at the exact same time.

You've short-circuited by assuming the threat model is a bad guy breaks into 1Password. But there's no reason to insist upon this very unlikely threat model, there are other threats that _really happen_ in which having both OTP and a password under 1Password saves you.

Getting obsessed with a single unlikely threat leads to doing things that are actively counter-productive, because in your single threat model they didn't make any difference and you forgot that real bad guys aren't obliged to attack where you've put most effort into defence.

First, I don't agree that if the attackers have access to the password, guessing that they have access to data stored with the password is "very unlikely".

Second, any theoretical advantage still has nothing to do with ratcheting...

First: Fuzzy thinking. The attackers have access to _a copy of the password_. The copy they got wasn't necessarily anywhere near the OTP secret.

If I tell my phone number to my bank, my mom and my hairdresser, and you steal it from the hairdresser, this doesn't give you information about my bank account number, even though the bank stored that with the phone number.

Bad guys successfully phish passwords plus OTP codes. We know they do this, hopefully you agree that in this case they don't have the OTP secret. So in this case 1Password worked out as well as having a separate TOTP program.

Bad guys successfully steal form credentials out of browsers using various JS / DOM / etcetera flaws. Again, they get the OTP code but don't get the OTP secret regardless of whether you use 1Password

Bad guys also install keyboard monitors/ logs/ etcetera. In some cases they could just as easily steal your 1Password vault, but in other cases (depending on how they do it) that isn't an option. I believe it's "very unlikely" in reality that they'll get your 1Password vault unless it's a targeted attack.

A passive TLS tap also gives the bad guys the password plus OTP code but not the OTP secret. Unlike the former three examples this is going to be very environment specific. Your work may insist on having a passive TLS tap, and some banks definitely do (this is why they fought so hard to delay or prevent TLS 1.3) but obviously your home systems shouldn't allow such shenanigans. Nevertheless, while the passive tap can't be used to MITM your session it can steal any credentials you enter, again this doesn't include the OTP secret.

Second: A ratchet enables us to recover from a situation where bad guys have our secret, forcing the bad guy to either repeat their attack to get a new secret or show their hand. TOTP lets us do this when bad guys get one TOTP code but not the underlying TOTP secret.

> Second: A ratchet enables us to recover from a situation where bad guys have our secret, forcing the bad guy to either repeat their attack to get a new secret or show their hand. TOTP lets us do this when bad guys get one TOTP code but not the underlying TOTP secret.

I'm just going to focus on this, because it's not based on opinions of likelihood but simple facts. TOTP does not have a ratchet. If you copy the secret, you can use it indefinitely.

A ratchet is a counter (or similar) that goes up per use, so you can detect cloning. TOTP does not have this. It does not store any state. If I log in every day, and the attacker logs in every day, you can't look at the counters to see that something is very wrong, because there is no counter.

I goofed by using the word "secret" in the ratchet description after earlier choosing "secret" to mean the TOTP Shared Secret.

In the situation we care about (which you think hardly matters, but I believe evidence shows to be extremely common) bad guys do NOT have the TOTP Shared Secret, it's in your 1Password Vault and the bad guys can't access that.

What they do have is a code, a One Time Password typically six digits long.

Because TOTP produces a _One Time_ Password, if I use that code, or any subsequent code, the one the bad guys have is now useless even if it has not yet expired. This forms a ratchet.

Ratchets aren't about detecting cloning, they're about what happens if bad guys temporarily get access. Can we recover? In many systems we're permanently screwed, if there's a ratchet we may be able to recover. For example this is essential to the design of OTR and the Signal Protocol.

Ratchets serve multiple purposes, but they're fundamentally about having a state on both ends that ticks forward per use. TOTP tokens are stateless and "ratchet" is not the right word for only allowing one login per 30 seconds.

How is that materially different to storing the password and TOTP in 1Password?

Obviously, because if you compromise my desktop, you still won't have my TOTP secrets.

But what if I seize your phone at a customs inspection, or a traffic stop? Don't I then have password and OTP?

a keylogger sniffs your password for site X, now they have your password for that site and can log in. If you also had a TOTP code, they can only log in for the next 30 seconds using that TOTP code, but they can't send out an email with your password in a CSV file to their friends and expect it to be usable.

I know I'm wrong because you know everything but I can't get past this particular one. unless the argument is, attackers aren't that lame anymore, then sure.

Best not to assume anyone is infallible. If you don't put people on pedestals you've got less cleaning up to do later when they inevitably fall off. Yes that includes you (and of course me).

2-3 minutes is more realistic for real sites than 30 seconds, because there is usually a margin allowed for clock skew. But yes each OTP expires and that's a difference for an attacker who doesn't know the underlying secret.

TOTP is also not supposed to be re-usable. A passive keylogger gets the TOTP code, but only at the same moment it's used up by you successfully logging in with it. Implementations will vary in how effectively they enforce this, but in principle at least it could save you.

Caveat: The system may issue a long-lived token (e.g. a session Cookie) in exchange for the TOTP code which bad guys _can_ trade unlike the token itself.

I think there's also a difference with passwords on the other side of the equation. If I get read access to a credentials database (e.g. maybe a stolen backup tape) I get the OTP secret and so I can generate all the OTP codes I need, but in a halfway competently engineered system I do not get the password, only a hash. Since we're talking about 1Password, this password will genuinely be difficult to guess, and guessing is the only thing I can do because knowing the hash doesn't get me access to the live system. In this case 1Password is protecting you somewhat while my TOTP code made no difference. If you have a 10 character mixed case alphanumeric password (which is easy with 1Password), and the password hash used means I only get to try one billion passwords per second, you have many, many years to get around to changing that password.

Still, FIDO tokens are very much a superior alternative, their two main disadvantages are fixable. Not enough people have FIDO tokens, and not enough sites accept them.

[Edited to make the password stuff easier to follow]

The scenario of "attacker has a key logger but doesn't steal the entire password database" sounds like enough of an edge case to ignore. If someone's stealing data from my password manager I'm going to assume full compromise.

Do you have anything - statistics, examples of popular toolkits, something like that, to show this is actually just an "edge case" ?

In the threat scenario we're discussing bad guys aren't "stealing data from my password manager" they just have the password and OTP code that were filled out, possibly by hand. They can do this using the same tools and techniques that work for password-only authentication, including making phishing sites with a weak excuse for why the auto-fill didn't work. We know this works.

> In the threat scenario we're discussing bad guys aren't "stealing data from my password manager" they just have the password and OTP code that were filled out, possibly by hand.

Possibly by hand? You are definitely not discussing the same scenario as everyone else. They're talking about password and OTP being stored in the same password manager, both filled out at the same time all in software.

A key logger is stealing those bytes right out of the password manager's buffers. It takes more sophistication to dump the database, but it's a very small amount more.

You are, alas, not unusual in mistaking the autofill feature, which ordinary users are told is about convenience, for a security measure.

In the real world users go "Huh, why didn't my autofill work? Oh well, I'll copy it by hand".

A "key logger" logs keypresses. That's all key loggers do. There are lots of interesting scenarios that enable key logging. You've imagined some radically more capable attack, in which you get local code execution on someone's computer, and then for reasons best known to yourself you've decided that somehow counts as a "key logger". I can't help you there, except to recommend never going anywhere near security.

> TOTP is very useful! Just use a TOTP authenticator app on your phone, and don't put them in 1Password.

I was fully in that camp before I started talking with friends on red teams that were allowed to actually start using realistic phishing campaigns. Now I'm fully in the "U2F, client certs, or don't bother" camp.

Maybe I'm jaded, but it feels like the exploit landscape has improved enough that TOTP is as hopeless as enabling WEP on a present-day wireless network. Not only does setting it up waste your time, you're presumably doing so because you have the false belief it will actually offer protection from something. It may have been useful at one point, but those days are disappearing in the rearview mirror.

The only place I see TOTP still offering value is for people who re-use passwords, but only because it becomes the single site-unique factor for authentication.

U2F addresses phishing and password theft. TOTP just addresses password theft. That doesn't make TOTP useless; password theft is a serious problem, routinely exploited in the real world.

Do you see any problem with using a phone TOTP authenticator, but when setting it up saving a copy of the TOTP secret in a file encrypted with my public gpg key?

The idea is that if I lose access to my phone, I can decrypt that saved copy of the secret, and load it into 1Password temporarily until I get my phone back or get a new phone and get everything set back up.

Before people started storing their TOTP secrets in desktop applications so they could auto-fill them in their browsers, this question used to be the front line of the 2FA opsec wars. I was a lieutenant in the army of "if you want to back up 2FA secrets, just enroll two of them; a single 2FA secret should never live in more than one place". I think that battle is already lost.

Lots of reasonable people back up their secrets, or even clone them into multiple authenticator applications. I try not to.

> if you want to back up 2FA secrets, just enroll two of them

Could you elaborate on how you do this in practice?

Just like the first one. Most U2F web sites let you register multiple keys.

Any one gives you access. So you take one with you and put one in a drawer at home.

> Lots of reasonable people back up their secrets, or even clone them into multiple authenticator applications. I try not to.

Because if they lose access to the 2FA secrets, you lose access to your account. If that's just one account, recovery might be doable (depending on who ultimately is root on the machine). If its your Bitcoin wallet or FDE though, you're toast.

There's also a variety of protocols used for 2FA. I've seen: USB2, USB3, USB-C, BlueTooth, NFC.

As for how people do this: they use a second key, save their key on a cryptosteel(-esque) device [1] (IMO overpriced, YMMV), USB stick, a piece of paper, or gasp CDROM. Where its saved differs. Could be next to a bunch of USB sticks, in a safe, at a notary (my recommendation though does cost a dime or two), in a basement under a sack of grain, ...

[1] https://cryptosteel.com

What the actual fuck is this "cryptosteel" thing?

There's a FAQ on the bottom of the page.

I know, I read it. What the actual fuck is this? Who would spend money on this? How is this not an insane product concept?

> Who would spend money on this?

https://www.kickstarter.com/projects/zackdangerbrown/potato-...

https://en.wikipedia.org/wiki/Juicero

etc.

> How is this not an insane product concept?

I thought sanity died years ago.

It costs $199 and you can't even store '@' with it!

It doesn't even do its job: https://medium.com/@lopp/metal-bitcoin-seed-storage-stress-t...

Thank you for the link, that was actually an informative comparison instead of cursing.

Seems like they'd still protect you from anything that records your password and TOTP, but doesn't gain access to your store? E.g. a website gets some JS injected that skims your login. Which doesn't seem all that unlikely.

Basically it becomes "just" replay prevention. Which is a nonzero benefit, but totally agreed that it's not at the same level as a separate generator of some kind.

Reply on news.ycombinator.com