My email is not my identity

[joshka]

For a number of reasons (primarily spam related), my email address is different for every single service that I use. Many people use plus-addressing for this purpose - I happen to own a domain and just use identifiers before the @. This protocol assumes that I want to share a single email with every service that uses it. Facebook login and other systems will give me an option to not provide an email. When that option is not there, I choose not to login with FB / Google.

[homakov]

In the end any service will still require an email. You either give it on first request, or you type it manually again. In that case you can always create a profile with fake email address. Would a check box "dont share my email" be enough?

[download13]

You could put the email into an "advisory information" section of the profile. The public key is the identifying part of the profile, so that should be the only required piece of information in the profile.

Anything else could be in the set of "suggested" fields which you can decide to fill in or not depending on the use of the profile.

Say you want an anonymous profile. Just create one and start using it. If you want to make a public profile then create one, and then type your public info into the advisory fields so your client can send them to services when logging in with that profile.

Though with the public key being the identifier it might be good to use a more human-recognizable signature of the public key. For example a generated name or avatar.

[deltaidea]

That wouldn't work, though, because then the public key would depend solely on the master password, meaning that two people who came up with the same password would have a collision. You can't expect users to have unique passwords.

Edit: you also can't generate keys based on something generated/random that the user doesn't enter, because then the user won't be able to generate the same key pair on their other devices, and the whole premise of the protocol breaks down.

An option not to share the email with services sounds like the best solution.

[download13]

If it's not a unique password then it's probably not strong enough to be used as the securing mechanism for all your accounts in the first place. As it is the email is essentially a (probably publicly known) salt.

This actually brings up something else I had a concern about. The master password needs to contain enough entropy to be unguessable while also being user-friendly enough that it can be manually transferred to different devices by a human that may not know much about information security.

Having randomly generated device-local keys that mutually sign when you sync your devices sounds like a better idea to me. It would take a lot more of the responsibility for securing key material out of users hands, plus you could individually revoke device keys instead of having to create all new accounts if your phone was stolen. Example.

[deltaidea]

That sounds like an entirely different protocol. Also see #21 on the subject of stolen phones.

[joshka]

If it's not a unique password then it's probably not strong enough to be used as the securing mechanism for all your accounts in the first place.

Have you seen the amount of crossover in passwords between data breaches? It's pretty massive.

As it is the email is essentially a (probably publicly known) salt.

Nope. You could guess my email for a service, but it would be a guess not a known fact. If a spammer guesses I delete that address and change the email with affected services.

The public key is the identifying part of the profile, so that should be the only required piece of information in the profile.

It seems that you're saying that if I know who a user is because I run service A, I can potentially see whether that user uses service B? (either directly enumerated or through a data breach).

[homakov]

That wouldn't work, though, because then the public key would depend solely on the master password, meaning that two people who came up with the same password would have a collision.

No, key = scrypt(email + pw) not just scrypt(pw).

[deltaidea]

@homakov

the public key would depend solely on the master password

We were talking about the possibility of making email optional and why it wouldn't work. If two users come up with the same password and choose not to enter an email, their accounts would collide.

[homakov]

There are two ways email is used in the system:

1) as a salt for creating root hash. This is required.

2) as a suggested email value for websites. We can easily drop it so website won't have it BUT in the end most services will still require to type it anyway, because they love sending "news" about your account.

[homakov]

this is how we can go about it: you can edit email if you want but it's required to set something

[download13]

So in this case the email acts simultaneously as an account label, a password salt, and an advisory contact point?

[homakov]

Yes, profile label for dropdown list, pw salt and currently sent by default as contact

[joshka]

Another part of this then is what happens when I wish to change my email address that I've originally chosen as the pw salt. This is not specifically relevant in my case as I own the domain. Often normal users however change their primary email when the move between ISPs, graduate from their university, change jobs, or decide that spanky93@gmail.com doesn't represent their identity anymore.

While I can understand that using an email that you no longer as an identity should continue to work, why should a user be forced to do so?

[deltaidea]

@joshka You can theoretically change your email using the same process as the password: https://github.com/sakurity/securelogin/wiki/How-password-is-changed

Judging by the example code there, services identify you by your public key and save the new key when you change the password. If you change email, the same thing would happen, so I guess the protocol already supports it.

[homakov]

Alright, now user can set new email (as salt and label) when they change password. This email will also be broadcasted inside of new_sltoken to all /securelogin endpoints so they can change email on their part too.

[joshka]

Reading http://gizmodo.com/gop-data-firm-accidentally-leaks-personal-details-of-ne-1796211612?rev=1497877260890 just now, I'm not sure I want any ability for sites to be able to know that I am a single identity let alone an email address.

[homakov]

We can generate app specific public keys and allow user to change email (see above) or entirely hide with checkbox.

Which one works for you?

[deltaidea]

Site-specific public keys would have annoying edge cases. I presume you'd use the domain name as additional data from which to generate the key. What if the domain changes? Even www.github.com to github.com.

[andrewda]

Yea, there will always be edge cases here so I don't really like site-specific public keys. If you leave the subdomain, dashboard.myapp.com would be different than myapp.com. If you exclude the subdomain, there would be no difference between the keys generated for app1.herokuapp.com and app2.herokuapp.com making it mostly useless.

[homakov]

It would not be fatal (provider can be set by site, but client is forced by Origin header) but would be more ugly.

I just don't understand what people ask for: do they want to hide or modify email and why simply creating a profile with forspam@mail.com is not an option?

[homakov]

Profiles allow full compartmentation. E.g. you can use profile1 in host machine, profile2 on a virtual machine etc. Simply mimicking privacy with unique pubkeys and no emails is not long term solution. Web is full of trackers: if you use two apps in one browser it's safe to assume they can figure out the link. That's what you need to tell users to start with.

[joshka]

@homakov forspam is not an option. And it's not spam. I get so little spam that I can look though my junk folder and mark everything as not spam.

How many of your emails appear in the haveibeenpwned database? Can you track the reason why?

Not sure if profiles would work, will think about the approach on the weekend

[homakov]

Just tell me which way suits you. Editing email? I'm fine with adding it transparently.

[homakov]

I'm closing this down because we didn't figure out what exactly people want. If they want privacy, just create a profile with throwaway email. If you don't want to provide any email, just use fake mailinator. No one requires you to use your real one.