Hacker News Reader

Comment by martius | Hacker News Reader

There is also the question of leaking whether a given user has an account on a website or not.

Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.

It might not be a security issue, but it could be a privacy issue.

View on HN

> Unfortunately this assumes that there's no other way for an attacker to discover whether a username/email address is registered for a service. This assumption is incorrect.

> 99.9% of websites on the Internet will only let you create one account for each email address. So if you want to see if an email address has an account, try signing up for a new account with the same email address.

This point is undermined by the sign-up workflow informing of whether an account is registered under a given username.

That depends on the sign-up workflow. It is possible to not provide the information "user already exist" on sign-up and instead just say "we sent you an email, please confirm". In this scenario a potential attacker who just wants to check for existing email addresses has no access to the email addresses he wants to check.

The contents of the email could be something like "Hey you just tried to register with this email address, but we already have an existing account with this email address ... Was that you? ... Maybe you have forgotten got your password?"

The author explains in the article that you're not protected from that case either, as the attacker can try to sign up with your email and find out anyway if that email is already registered.

He gives a solution for that and says it is "too cumbersome".

Not necessarily. You can design the sign up process by way of always ending with a message that says you will be notified.

Many services let you sign up with an existing email and just send a “you tried to sign up, but you seem to have an address already.” to the account owner. In that case it’s indistinguishable for the attacker.

Many services already require email confirmation to finalize the signup process so the extra effort is low.

And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.

I guess the better point for the article would be "many websites cargo-cult the login error message without understanding why it's there and how that should impact the rest of the service"

> And those services also plug the forgotten-password information leak by just informing you "if you have an account, you got an email" instead of giving you an explicit success or error message.

This might be a better approach, but one problem I see with it is: what if the email is not actually delivered because of an internal bug in the website? How would users know they didn't receive an email they were supposed to have received, and take the appropriate action (trying again or contacting help), versus that they entered a wrong or unregistered email?

Email might not be delivered for many reasons that may not all be in control of the sender. It may be classified as spam somewhere along the way. It may simply drop into a black hole. Eventually the user will try again.

That same problem can happen regardless of whether the password reset flow checks for user existence before sending the email.

sounds like a nightmare for someone who forgot their password and has multiple emails, and isn't sure which one is right. did i use the wrong email, did it land in the spam folder, or did my email provider just quietly delete the email (which unfortunately does happen, and not just with dodgy emails/IPs)

I have multiple emails, and this never turned out to be an issue - worst case i just try all of them.

But if you want to improve the implementation, the provide can also decide to send an email in case no account is registered with that email address - "Hey, someone tried a password reset for this email, but there's no associated account. If it was you, ..., if not, ignore this email."

With this approach, I imagine slightly less technically savvy users might be confused as to whether a new account was actually created before they were also informed of the old account. In other words, they might not know if a new password they entered is also usable for the original account.

Off the top of my head, I cannot remember any site I use that works that way (which is also basically what TFA is suggesting to do as a trade-off implementation)

Those sites probably prompt the attacker with a "We have sent you an email with an activation link" and the owner receives the "you tried to sign up, but you seem to have an address already" message. In this way they don't leak anything to the attacker.

By the way, I've been stuck for years with an ecommerce site that thinks I already registered with them using my email. They're telling me that I must activate the account. I click the link to send me the activation message again but then they say that my email is not registered with them. I'm still stuck and will probably never buy from them because I can't.

I'm confused, you've been trying to buy an item from that website for years and it never occurred to you to just use a different email address? This isn't really believable.

I just drive to the shop.

Xylakant explains how to cope with that in a sibling comment. Note that email is personal information often containing name, surname and maybe a likely year of birth (johndoe92@example.com). Leaking it is not OK in several legislations so we should take special care before telling someone that some person is or is not in our database.

This is a huge problem - if I know your email, and can get the error pages, I can find out where you have accounts; sometimes I can even find out the account name with that.

Even worse with phone numbers.

If you want to confirm a user is the same as another user on a different site, and you know their phone number, often part of the recovery process will reveal part of the phone (a text has been sent to *-*-*33, eg).

> Maybe I don't want my employer to know that I have an account on competitor-service.com, or my partner to know that I have an account on kinky-thing.website.

In that case, maybe employ the basic opsec measure of having a separate email account for competitor-service.com and kinky-thing.website?

For the vast majority of people, this is a bridge too far.

It is an advantage of using things like the apple-generated randomized emails for accounts.

Sure, but if we are talking about improving user experience, I don't see how this helps.

OPSEC and user experience are completely unrelated things.

If you have something to hide (from anyone at all), you have to employ opsec measures. Using an email account that can't be immediately linked back to you is the most basic of them (and would be perfectly sufficient in the scenario described).

It wouldn't even matter if the website didn't leak in any way that an email is registered with them, because data breaches happen, and should one happen, you'd be fucked from that perspective anyway. Remember the Ashley Madison leak?

Are they unrelated?

The article is about a tradeoff between security and user experience, claiming that a given practice is bad experience without any security gain.

The Ashley Madison leak shows that there are plenty of vulnerable users who are not educated to even "the most basic" things to do to protect their privacy.

It's also a question of user experience to protect users against themselves, or against threats they don't know about.

Saying "it's up to the user to do the right thing" isn't really helpful in the context of discussing account creation/login UIs.

> Are they unrelated?

Perhaps not when considering only the points made in the article, but in the grand scheme of things, yes.

If you’re worried about your opsec (not the sites, and if you’re worried about your opsec, you should treat the site as having no security measures whatsoever), ux is secondary to you, because in the case of a leak you should be in a position where you can plausibly deny everything. And you shouldn’t expect the site to help you with it.

While I agree in general that this is the better way, it’s in the end out of the sites control. The could notify the user, but cannot implement any measures that can help to protect the user. Avoiding information leaks is under the sites control - you just need to consider whether you can truly avoid this leak.

Reply on news.ycombinator.com