Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

701–710 of 816 posts

Re: Emailing a one-time code is worse than passwords

#701

Earlier quoted context omitted.

I don’t remember why KeePassXC didn’t make my list last time I checked. That was years ago, so I’m going to check it out again. Thanks for the pointer. Update: One thing that stands out immediately is a confusing mess of three different projects, two of them unmaintained, which all call themselves KeePassX or KeePassXC, sometimes linking to each other’s documentation. How do I even tell I’m facing the correct KeePass…

> How do I even tell I’m facing the correct KeePass(X(C)?)? project? Well, [0] lists a single project called KeePassXC, with [1] as its homepage. Search engines list [1] and [2] as the top results for the query KeePassXC, for whatever that's worth. [3] > Also, if a password manager project needs to be forked over and over and over again ... then does that tell us something about how the project is governed? No? KeePa…

Thanks for taking the time to follow up.

When I searched for `keepassxc`, my search engine ranked eugenesan/keepassxc [0] higher than keepassxreboot/keepassxc [1], so the former was the first that I’d visit. GitHub says that eugenesan/keepassxc is 2693 commits ahead of keepassx/keepassx:master, so I assumed that eugenesan/keepassxc was a legitimate and meaningful fork of keepassx/keepassx. Maybe I’m entirely mistaken, and I was just tricked by a blunder of my search engine and eugenesan/keepassxc is just a random person’s fork? (But then again, if it’s just a random fork, then why does it show up at the top, and why so many commits ahead of keepassx?)

To add even more to the confusion, not only is eugenesan/keepassxc unmaintained, it also points to www.keepassx.org (why?), which in turn says it’s unmaintained, too.

If I was just mistaken and eugenesan/keepassxc is really just a random fork, then my earlier allegations are all moot. Thank you for clearing this up, and also for clarifying that the other (legitimate?) KeePassXC was a preexisting fork (so it would have been difficult for them and possibly even more confusing to users if they had taken over the abandoned KeePassX project).

[0]: https://github.com/eugenesan/keepassxc

[1]: https://github.com/keepassxreboot/keepassxc

Re: Emailing a one-time code is worse than passwords

#702

Earlier quoted context omitted.

> simply check the URL before having KeePass autotype. I’m not going to rely on myself never making a mistake. I want a solution that protects me even during stressful moments where I have a lapse of judgement and forget to check.

If you're not using KeepassXC's browser plugin (or are using KeePassX, which -IIRC- never had a browser plugin), then its autotype feature will check the title of the window that has keyboard focus when deciding which entry to use. If one or more matches are found, it will [1] also ask you to confirm which entry you're about to have the software punch in. If no matches are found, it will alert you to that fact. You m…

Not sure how you got the impression that I was unwilling to use a browser plugin.

I’m absolutely looking for a browser plugin. I would refuse to use an auto-type feature that only checks the window title instead of, as a browser plugin would do, the site’s domain.

Re: Emailing a one-time code is worse than passwords

#703

Earlier quoted context omitted.

OP’s claim was not that “people don’t read.” It was that “[t]hey only read what they need to finish what they are currently trying to do.” Those are two different claims.

Ok. When they need the code they will have to scan through a message like Do not share the code 3456 and will read the words, because they read left to right. The code should be in the same font as the rest of the text.

I can assure you that by now, my brain is conditioned to lock into the four-digit code as soon as it can, entirely ignoring everything around it, including the words to the left.

I’m an avid reader. But there are limits to what I can process, and our world has become so full of noise that it has become a coping strategy for brains to selectively ignore stuff if they feel it’s not important at the moment. That effect becomes even more pronounced as the brain deteriorates with age.

Re: Emailing a one-time code is worse than passwords

#704

Earlier quoted context omitted.

If you're not using KeepassXC's browser plugin (or are using KeePassX, which -IIRC- never had a browser plugin), then its autotype feature will check the title of the window that has keyboard focus when deciding which entry to use. If one or more matches are found, it will [1] also ask you to confirm which entry you're about to have the software punch in. If no matches are found, it will alert you to that fact. You m…

Not sure how you got the impression that I was unwilling to use a browser plugin. I’m absolutely looking for a browser plugin. I would refuse to use an auto-type feature that only checks the window title instead of, as a browser plugin would do, the site’s domain.

I'm not sure how you got the impression that I had the impression that you're unwilling to use a browser plugin. I have absolutely no idea whether or not you're willing to use a browser plugin.

I was mentioning how auto-type worked because it's useful information for those who either are unwilling to use a browser plugin, or are like myself and simply have no need for one.

Re: Emailing a one-time code is worse than passwords

#705

Earlier quoted context omitted.

> How do I even tell I’m facing the correct KeePass(X(C)?)? project? Well, [0] lists a single project called KeePassXC, with [1] as its homepage. Search engines list [1] and [2] as the top results for the query KeePassXC, for whatever that's worth. [3] > Also, if a password manager project needs to be forked over and over and over again ... then does that tell us something about how the project is governed? No? KeePa…

Thanks for taking the time to follow up. When I searched for `keepassxc`, my search engine ranked eugenesan/keepassxc [0] higher than keepassxreboot/keepassxc [1], so the former was the first that I’d visit. GitHub says that eugenesan/keepassxc is 2693 commits ahead of keepassx/keepassx:master, so I assumed that eugenesan/keepassxc was a legitimate and meaningful fork of keepassx/keepassx. Maybe I’m entirely mistaken…

What search engine are you using?

I've tried DDG, Google, Bing, and Yandex. All of them rank official KeepassXC stuff in the top five results, and -with the exception of Bing- rank it above any other non-Wikipedia results. I didn't see this weird keepassx GitHub fork in the results from any of the search engines I tried.

> When I searched for `keepassxc`, my search engine ranked eugenesan/keepassxc [0] higher than keepassxreboot/keepassxc...

With the greatest of respect, I would expect someone who's sufficiently savvy to know what to do with a GitHub repo in their search result to also be sufficiently savvy to -at minimum- visit the homepage listed in the repo's About blurb and notice that [0] is the very first item in the list of "Latest News". I'd also expect that savvy someone to know to visit the repo's Releases page, notice that there are no published releases, and consider even more intensely that they might not be looking at the software they expected to see.

I can't explain why your search system is ranking this misleadingly-named GitHub repo so highly. AFAICT, noone with the repo owner's email address was ever involved in any public development on KeePassXC.

[0] https://www.keepassx.org/index.html%3Fp=636.html>

Re: Emailing a one-time code is worse than passwords

#707
post #661

Earlier quoted context omitted.

They paraphrased what you said in the thread, but I don't think it's much of a misrepresentation. You may have "been one of the most vocal proponents of synced passkeys never being attested to ensure users can use the credential manager of their choice", but as soon as one such credential manager allows export that becomes "something that I have previously rallied against but rethinking as of late because of these si…

You should really re-read the entire discussion. It wasn't about passkeys being able to be exported. It was specifically about clear text export. > The fact that that possibility exists, The possibility does not exist in the consumer synced passkey ecosystem. The post is from a year and a half ago.

A year and a half ago doesn't really matter; that this was ever even a concern from the industry, something that the industry could make happen at all, or even just was thinking about doing at some point in the past, poisons the entire effort. In a world where password+totp already exists and requires almost no hoops, no dependencies and is incredibly secure vs basic password flows, it's no wonder that folks remember discussions around curtailing user freedom around a new authentication pattern which already was less convenient, offers less user control, and further centralizes infrastructure in the hands of a few major brokers of technological power.

Until we have full E2E passkey implementations that are completely untethered from the major players, where you can do passkey auth with 3 raspberry pi's networked together and no broader internet connection, the security minded folks who have to adopt this stuff are going to remember when someone in the industry publicly said "if you don't use a YubiKey/iPhone/Android and connect to the internet, ~someone~ might ban you from using your authenticator of choice."

Re: Emailing a one-time code is worse than passwords

#708
post #329

Earlier quoted context omitted.

That's fine, but Chrome has 67% market share, and the majority of people will pick the default option for passkeys if prompted. For passkeys to replace passwords it's got to be seamless and easily recoverable without compromising security.

> the majority of people will pick the default option for passkeys if prompted Especially since Google doesn’t allow you to change your personal default which is what convinced me to go and switch all my accounts off of Google SSO

I’m not sure what you mean; I have multiple passkeys on different platforms for my Google account (and a few similarly important ones).

Re: Emailing a one-time code is worse than passwords

#709
post #65

Earlier quoted context omitted.

The problems of Passkeys are more nuanced than just losing access when a device is lost (which actually doesn't need to happen depending on your setup). The biggest problem are attestations, which let services block users who use tools that give them more freedom. Passkeys, or more generally challenge-response protocols, could easily have been an amazing replacement for passwords and a win-win for everyone. Unfortuna…

Do you have some examples where people actually require attestation in 3rd party facing systems? Or is this purely "But in theory..." and you've dismissed all the very real problems with the alternatives because you're scared of a theoretical problem ? I always reject attestation requests and I don't recall ever having been refused, so if this was a real problem it seems like I ought to have noticed by now.

> Do you have some examples where people actually require attestation in 3rd party facing systems?

That's not the right question. The right question is "what companies would be using passkey's if there was attestation on their security". To answer that question, you might look at the answer for a similar one on X509: "would we be doing banking over http if X509 didn't have attestation?".

Re: Emailing a one-time code is worse than passwords

#710

Earlier quoted context omitted.

Apple’s works fine, including when I’m logging on to my windows machine. Opening the camera app is a little annoying, but I don’t have to do it frequently. 1Password works well too and it runs on everything. There’s open source options, but I can’t attest to their UX.

That's fine, but Chrome has 67% market share, and the majority of people will pick the default option for passkeys if prompted. For passkeys to replace passwords it's got to be seamless and easily recoverable without compromising security.

So we need to make a new open standard, and then somehow prevent Google from implementing it? Too badly they implemented TOTP too. I’m not sure what you’re proposing here.
Post reply on HN