Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emailing a one-time code is worse than passwords

blog.danielh.cc

Post reply on HN
Print view View original

731–740 of 816 posts

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

#731

Post by chii »

SethMurphy wrote: post #595
chii wrote: post #171

Earlier quoted context omitted.

> convince a user to enter their google 2fa code into a site that isn't obviously google? if the BAD site itself looks legit, and has convinced a user to do the initial login in the first place, they won't hesitate to lie and say that this 2-factor code is part of their partnership with google etc, and tells you to trust it. A normal user doesn't understand what is a 2factor code, how it works, and such. They will ea…

What I don't understand is how the site will send the 2FA code request to the bad actors phone, instead of the real users phone? Is this not part of what makes it more secure than a text or email? Wouldn't the bad actor need to be logged into the authenticator as the user your trying to hack?

> how the site will send the 2FA code request to the bad actors phone, instead of the real users phone?

the 2FA code in this case is in the email, not via an app. This email is triggered by BAD on their end, but it is sent by GOOD.

If the 2fa is _only_ via the authenticator app, then the BAD will need to convince the user to type in that 2fa code from the app into the BAD site (which is harder, as nobody else does this, so it should raise suspicions from the user at least).

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

#732

Post by rpdillon »

Hackbraten wrote: post #536
rpdillon wrote: post #458

Earlier quoted context omitted.

I've been using Keepass for two decades and have never had a single issue. I would never recommend a browser plug in (too much attack surface area), and instead simply check the URL before having KeePass autotype. No clipboard. I think you're rejecting good solutions out of hand. Meanwhile...millions of users trusted LastPass. Twice.

> 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.

I don't think fixing this at the browser-level is the right place. In general, I'm very vigilant, but I know I can be tricked. So I have a policy about not clicking links in emails from companies I already know the address for. I also aggressively right click / long tap links to examine the URL before opening.

In general, opening a malicious URL exposes the user to unnecessary risk, so the correct solution is not to assume the user has visited a malicious site (since that would already be high-risk), but rather to prevent opening of malicious URLs. The most obvious solution is to treat any untrusted content as questionable. So I very carefully examine every domain I visit - as I say to my kids: have a model about who owns the computer you're talking to. Domains matter.

Now, this works for me. I'm not cognitively impaired, I have high conscientiousness, probably from working in military and classified defense contexts way back when, but I'm not really sure to be honest, could just be my personality. But it works for me.

I get that you want that extra safeguard, but it's just not a dealbreaker for me, especially since I'm highly suspicious of browser add-ons and the security implications they bring in. I guess I'm just extremely selective about what add-ons I'll use.

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

#733

Post by KingOfCoders »

Hackbraten wrote: post #450
KingOfCoders wrote: post #385

Earlier quoted context omitted.

Please log into BAD.com - we're a login provider to GOOD.com with a higher security level, from now on use BAD.com to log into GOOD.com Why would I put a secret code from GOOD.com into BAD.com? That's the core of the problem. If you put a code you get from GOOD.com into BAD.com, it's like you put a password from GOOD.com into BAD.com - don't do that.

> If you put a code you get from GOOD.com into BAD.com, it's like you put a password from GOOD.com into BAD.com - don't do that. A password manager will protect me from doing the latter. There’s no way it can protect me from doing the former. Any human can be tricked, no matter how smart they are. A bad actor just has to wait for the right moment. No amount of “don’t do that” can change that fact.

If a website says "Do this" and you're the person who follows random websites against security practices, because you believe in authority, a password manager does not help. You will open the password manager, search for GOOD.com and put it into BAD.com and be angry that your password manager can't do that for you.

"Any human can be tricked, no matter how smart they are."

and

"A password manager will protect me from doing the latter."

Don't work together. Either everyone can be tricked or not.

It says "Everyone can be tricked" but I can't be tricked because I use a password manager.

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

#735

Post by BrenBarn »

dabeeeenster wrote: post #689
StillBored wrote: post #214

And there is _NOTHING_ worse than being locked out of an account because without asking they reverse the password and second factor authentication while your traveling and don't have access to a phone/etc. Nevermind. that pretty much all services treat the second factor as more secure than my 20 character random password saved in a local password safe. And those second factors are, lets see, plain text over SMS, plai…

What percentage of people reuse the same password as opposed to use a password manager?

I would say it is very high. In my experience password managers are rarely used by nontechnical people.

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

#736

Post by Hackbraten »

simoncion wrote: post #705
Hackbraten wrote: post #701

Earlier quoted context omitted.

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 ke…

> What search engine are you using?

I’m using Kagi. They say they rely on several third-party search indexes. I can’t see which one they are using for which particular search request. What I do know is that the backends are of varying quality. However, after years and years of using Google (back when their search was still good), I got used to the fact that if they return a GitHub project as a top search result, then that project was usually meaningful.

> 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".

Forks sometimes don’t update the About blurb that they inherit, and I think that that’s exactly what happened in the bogus repo.

> 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.

In this case, however, the Releases section said “13 tags.” Some projects don’t use GitHub’s Releases feature at all, and rely only on Git tags. It’s sometimes difficult to spot.

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

#737

Post by mediumsmart »

addandsubtract wrote: post #304
mediumsmart wrote: post #291

I think the registration pattern should be - user enters email to register. email is sent to that email with a link to verify. user clicks link. user gets email with username and password to login in to the profile created for them.

This reveals the user's password (even if temporary) in plain text in an unencrypted email. Basically the last thing you want. A better workflow is to send the user a link where they can set their initial password themselves.

same thing in blue which additionally opens the door for someone else to change their password and lock them out, never mind the quality of passwords users set initially etc. Looking at you, mum, registering a new account everytime you forget the last password.

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

#738

Post by Hackbraten »

KingOfCoders wrote: post #733
Hackbraten wrote: post #450

Earlier quoted context omitted.

> If you put a code you get from GOOD.com into BAD.com, it's like you put a password from GOOD.com into BAD.com - don't do that. A password manager will protect me from doing the latter. There’s no way it can protect me from doing the former. Any human can be tricked, no matter how smart they are. A bad actor just has to wait for the right moment. No amount of “don’t do that” can change that fact.

If a website says "Do this" and you're the person who follows random websites against security practices, because you believe in authority, a password manager does not help. You will open the password manager, search for GOOD.com and put it into BAD.com and be angry that your password manager can't do that for you. "Any human can be tricked, no matter how smart they are." and "A password manager will protect me from…

> you're the person who follows random websites against security practices, because you believe in authority

There are many reasons why such lapses of judgements happen, even to people who don’t believe in authority. For example, the fact that any human can be tricked.

> Don't work together. Either everyone can be tricked or not.

The password manager protects me from filling my password into the wrong site.

The password manager will not protect me from BAD.com tricking me into handing them out a one-time code that GOOD.com sent me via email.

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

#739

Post by johnisgood »

ErneX wrote: post #300
johnisgood wrote: post #217

Earlier quoted context omitted.

It is just the same old stuff with username & password combination. I used to duplicate websites, they looked exactly like the original, except I was storing the entered username and password combination. I did this when I was a kid. The process is the same (or very similar) with everything else that is not a password.

True, they do it to facilitate access to their site without a password, but personally I don’t like getting an email just because I entered my username to sign in (my password manager takes care of filling the form so that email with a code is unnecessary to me).

I agree, I do not want an email either.

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

#740

Post by growse »

ori_b wrote: post #698
growse wrote: post #691

Earlier quoted context omitted.

> If you make something possible, it will be used. Sure, but that's not without tradeoffs. I come back to: > Any service requiring attestation for passkeys will effectively lock out every iPhone user - not going to happen.

And I come back to: if it would never work, why not drop support? "We pinky promise" is just not good enough.

> if it would never work, why not drop support?

Because passkeys are designed to replace passwords across multiple different service contexts, that have different requirements. Just because there's no reason to use it for one use case doesn't mean it's not actually useful in a different one. See things like FIPS140 (which everyone ignores unless they're legally required not to).

Can you sketch out for me the benefit of a public-facing service deciding to require passkey attestation? What's the thought process? Why would they decide to wake up and say "I know, I'm going to require that all of my users authenticate just with a Yubikeys and nothing else"?

Post reply on HN