Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow different kinds of identifiers for registration #1085

Closed
generalmanager opened this issue Mar 7, 2014 · 22 comments
Closed

Allow different kinds of identifiers for registration #1085

generalmanager opened this issue Mar 7, 2014 · 22 comments
Labels

Comments

@generalmanager
Copy link

I know it's come up in the mailing list and on twitter and I'd also really like to see the possibility to register with different kinds of proof of identity.

It's obvious that this would be a rather large feature and all the little quirks and bugs have to ironed out before any of the devs will have time to think about implementing something like this. But I'd like to use this issue for brainstorming and discussing ideas which possibilities of proof of identity exist, that are safer and / or more anonymous than phone numbers or email addresses.

TextSecure uses a security model called trust on first use or TOFU.
This means the TextSecure server checks if you control some unique identifier by which your contact's know you.

This is currently done with your phone number, which is great if your friends want to find you. But it's not ideal at all if you don't want to be found. And also for security reasons.

If this initial check was not compromised, you can be very sure that your communication can not be intercepted or faked by any known kind of attack on the transport. If TLS breaks (again) then an attacker with control to the data transport can tell that you are using TextSecure and probably also with which number you registered and who you talk to. But they won't be able to read your texts, unless they compromise your phone directly. But this isn't something TextSecure or any app can do much about. It's also a lot harder, more expensive, complex and dangerous (easier to detect) to do this on a wide scale than it is to compromise the transport.

Phone numbers are really bad for many reasons:

  1. They are directly linked to your real life identity by several public and non-public databases. There are no throw-away phones in Europe and many other parts of the world like there are in the US. EU law requires the stores to register and verify your identity with your national ID card.
  2. You can only carry around / check so many phones/sim cards. You also have to get one phone for each sim card, because the phones IMEI is automatically logged together with the sim card identifier. That means if you just change sim cards, it's rather obvious to the network provider / the guy that owned the network provider / your average dictator that you are still using the same phone. So you are probably the same person/entity.
  3. Once you somehow got a relatively anonymous phone number, it's not easy to just switch to a different one, because you probably use this for a number of different places / contacts, because it was expensive/arduous to get and you can't have 50 phones lying around all the time (see 2.).

4 It's really easy for the network providers or anybody with a little incentive to trace you to a rather small physical area. If you want to know more about the phone tracing (for 15$), watch some of Karsten Nohl's talks from the differenc Chaos Communication Congresses.

  1. It's also rather easy to fake the identity of a mobile phone. Not just for the network operators but also for the average IT guy. Watch the same stuff I recommended in 4. if you want to know more.

In the future it will be possible to register with an email address, but that's not that great either. Let's see which of the above problems disappear by using an email.

  1. It's really easy to get an anonymous email address. TOR + some random email account, that's not linked to anything else you do, should be good enough for most people.
  2. No problem, you can have as many email accounts as you like. But you should start a new TOR session for checking each and should probably not check them one after another to prevent correllation attacks (the same e-mails always get checked together, it's probably the same guy).
  3. No problem, it's easy as pie to get a new one (see 1.)
  4. With TOR and/or other methods of anonymization it shouldn't be a problem if you are disciplined enough to always stick to some basic rules.
  5. Okay that's a biggie. It's actually easier for a powerful attacker to fake owning somebodies email address, or to get control over the adress itself by other means than it is for mobile phones.

So especially problem Number 5 still has to be solved.
Because this means that it's possible to do a man in the middle attack (MITM) on somebody who is using TextSecure.

Currently there aren't many ways to get a unique but anonymous identifier that is also extremely hard to impersonate.

One possible solution would be to use some kind of crypto currency.

Some possibilities I found:
Software:

Hardware:

  • Yubikeys
  • CryptoStick
  • TREZOR
  • Other Smartcards

It would be great if we found something that can be run on the clients themselves, otherwise we would still have to trust the TS server, that he has verified the identity (as it is now). But then all our effort would have been rather futile, because if the server gets compromised, the same attack as described above can happen.

However, the block chains of the crypto currencies that have a kind of id or alias system enabled are already too big to fit on most cell phones. If we just run a "light client", that asks a website if the person is indeed who he pretends to be, we have to trust this server that it hasn't been compromised. Sounds like a lot of work for nothing. We could ask several different servers, to lower the chances of an attack, but we can never be really sure.

Then there are things like Yubikeys or the Crypto-Stick. But they are so little used that there is currently no easy way to get them anonymously from a local shop.

I'm open for any suggestion.

Currently it seems to me like using anonymous email + verifying the keys after the exchange is probably the least effort.

This is also kinda connected to #838.

@Wikinaut
Copy link
Contributor

for your list above, I suggest to add this:

@Wikinaut
Copy link
Contributor

@moxie0 Have you already considered BrowserID (Persona) https://github.com/mozilla/persona - "Persona" is a login system based on the BrowserID protocol ?

@generalmanager
Copy link
Author

@Wikinaut I considered adding Mozilla's persona the other day, but Mozilla just abandoned it aka "gave it to the community" :-/

It's also not really any more secure than email if you can reset your password via email.

@juliaba
Copy link

juliaba commented Mar 19, 2014

First, I want to say that I only have little coding experience, so I'm an interested "normal user" of TextSecure and I'm also interested in the security issues. The idea is very good to get an additional kind of identifier, because I agree with the problems of the phone number as identifier.

But: Please do not delete the possibility to identify with a phone number. When I wanted to change my Instant Messaging Program for my mobile phone, I tried some, e.g. ChatSecure (it's pretty safe, too). For me, it was okay to register with a nickname, but I wouldn't have been able to convince any of my friends who are uninterested in all these security issues to get an account and to add all their friends manually. This was the reason why I chose TextSecure: I could just tell my friends: "Download this and use it."

So it would be great to have both possibilities: Easy phone number-identification and another one which is even more secure. Then I'm totally with you. :)

@generalmanager
Copy link
Author

@juliaba

So it would be great to have both possibilities: Easy phone number-identification and another one which is even more secure. Then I'm totally with you. :)

Sure, nobody wants to take away the simplicity of using a phone number.
What I want to accomplish is that the people who really want and the people who might need this kind of additional security (unfortunately those groups usually don't have a lot of overlap) have the option to profit from an authentication method that is more secure than the current phone number model.

In my opinion the great chance we have with TS is, that we can make a very secure tool that's easy to use, to appeal to the vast majority of users. But with a little work and clever design we can also make it an incredibly secure tool, that may need some configuration. But this can be greatly simplified with the proposals fro #838.

@neuhaus
Copy link

neuhaus commented Mar 20, 2014

I'd like to see plain OpenID supported as authentication.

@generalmanager
Copy link
Author

@neuhaus
OpenID is nice to reduce the number of accounts one has to set up and secure, but it isn't much safer than usual email. The biggest problem is, that you still have to trust a single entity, your OpenID provider. If they get compromised, your identity isn't secure anymore.
And in the current implementation basically all OpenID providers use email as a fallback. Which means if you (pretend to) forget your password, they'll send you a new one to your email address.

There are many more drawbacks, but I want to cite the last part of the conclusion from this paper:
http://nds.rub.de/media/nds/veroeffentlichungen/2010/12/20/CameraReady_SecurityofSingleSignOn.pdf

Although OpenID has a great potential, but yet again, a working protection against identity
theft as one of the biggest challenges of browser-based Single Sign-On systems remains
still unsolved.

I don't want to blast OpenID. It's certainly better than creating new identities everywhere, but just like those identities the OpenID identity is usally backstopped by an email address, which is simply not secure.

Currently the best security appears to be provided by the user having control of a unique, unclonable physical token (Yubikey/CryptoStick) and a private key, with the identity information (public key) stored in a cryptographically secured distributed network, where every client is a full node.

For anonymity the physical token might be skipped, but at the cost of reducing security.

@neuhaus
Copy link

neuhaus commented Mar 20, 2014

@generalmanager You raise some good points I hadn't considered - I was going to be my own OpenID provider (which obviously isn't going to be the standard situation).

@shea256
Copy link

shea256 commented Mar 26, 2014

Hey everyone, I'm one of the original creators and core devs of OneName. I'd be happy to answer any questions about OneName and help you determine if it is a good option for you to integrate into TextSecure.

Here are the protocol specifications for OneName: https://github.com/onenameio/onename

Here are some benefits of OneName over the other options you mentioned:

  • Thousands of people are already using OneName and have their own identities.
  • Profile completion on OneName is significantly better than the profile completion on the other services you named. A good percentage of users have profile photos, PGP keys, and twitter accounts already linked.
  • The protocol supports verification of twitter accounts, github accounts, membership of organizations, etc.
  • Discourse.org is considering using OneName for sign in.
  • Several Bitcoin wallets are working to integrate OneName payments, including Electrum.

The OneName protocol is open source and we are making a big push to get other developers to get involved and help in the development of the specifications. If there is something that you don't like about OneName, if there are limitations you see of OneName that would somehow prevent it from being useful to TextSecure, you can always hop on the Github and start a discussion or submit a pull request.

Cheers! Again, let me know if you have any questions. Happy to help.

@generalmanager
Copy link
Author

@rxl Thanks for your input!
I really like the idea of a distributed identity ledger, but the ecosytem just doesn't seem to be ready for mobile platforms.
Right now the main problem I have with OneName and NameID is, that there needs to be a lightweight Android client first. Downloading the whole namecoin blockchain is out of the question on mobile devices. As is relying on just querying a full node.
Because we only need the identity information, it should already be a lot lighter than the whole namecoin blockchain, even without doing something akin to SPV or pruning.

But until a client or a library exists, which can simply be queried from the app that needs to verify the identity, I think this is unfortunately not a viable approach.

@shea256
Copy link

shea256 commented Mar 26, 2014

I'd check out dnschain (https://github.com/okTurtles/dnschain).

Here is an API endpoint where you can query for my data using dnschain: http://dns.dnschain.net/u/ryanshea

@generalmanager
Copy link
Author

@rxl Yeah, I already looked at dnschain. But the inherent problem is, that we are trusting a single entity again, instead of talking directly to the distributed ledger.
It's the same game as with DNS or certificate authorities right now: How can I trust them?
The idea that everybody has a server somewhere, which he setup himself and which he trusts is unfortunately not realistic.

As long as we are directly connected to the distributed ledger, we can have very high confidence that the majority of the network agrees that an identity is valid. But as soon as there is a single point of failure, we loose all the confidence that the ledger provides..

From this perspective even email+PGP would be better, because it's widely available and there already are a lot of providers to choose from.

@shea256
Copy link

shea256 commented Mar 26, 2014

So I somewhat agree with you.

I think electrum has proven that you can have a very high level of reliability/trust while still having only a few entities host their own nodes. All you need to do is query multiple nodes (with some information about the source) and make sure that they return the same response. If you know that corp A, corp B, org C and org D all run nodes, you can query 2/4 or 3/4 of them and have a high level of confidence that the answer you're receiving is correct.

The other option is of course SPV.

IMO the long term model will be a hybrid of the electrum "few nodes" model and the multibit SPV model. But for now, I don't see anything wrong with a "few nodes" model. It is far from a single node model and it is definitely not "trusting a single identity."

@generalmanager
Copy link
Author

@rxl Thanks for pointing that out! A consensus based decision would be much better. Kinda like the Convergence plugin for Firefox works.
Even querying a few dozen/hundred full nodes shouldn't take too long if its only necessary for new contacts.
The registration however would also need to be done via one of the full nodes, which doesn't seem to work yet. But it's certainly worth checking out.

@shea256
Copy link

shea256 commented Mar 27, 2014

Registration doesn't actually need to be done through one of the full nodes. A mobile app with a private key can build a transaction and broadcast it to anyone who is running full node and is willing to relay it to the network.

@ghost
Copy link

ghost commented Jul 10, 2014

Has any progress been made since April? Any news? Is anyone working on this?

@generalmanager
Copy link
Author

Unfortunately I'm not aware of any new development, but the first big step will probably be email identifiers when websocket support is finalized:
#1000

@midi
Copy link

midi commented Aug 6, 2014

great to hear email identifiers are on the roadmap.

i have no problems to use phone numbers as identifier, the exclusive use is a major stress factor for me.

with friends in more than one country and as traveller, i have to decide if i want to stick with one number and always have that sim card ready or just always change to my current local number, both ways are far from ideal as they require me to either give people who i can bring to try textsecure/redphone, to give them one local number and one textsecure number or continually update my non-local friends with my current local number, used for textsecure/redphone.
for family, i'm just happy that i can use redphone with them, having them to figure out how to change my number several times is very difficult.
phone numbers are temporary, my email address will never change.

as privacy conscious person, without facebook, whatsapp, kakaotalk, skype and so forth, only email, phone number and hangouts for video, i have to stay strong to not give in and i'm ok with my exclusivity.
whispersystems applications allow me to also enjoy internet based communications, at least with the people that are important and therefore willing to install those applications to reach me, for that i'm so grateful!

i'm really looking forward to the day, where all the people that i give my email address, will automatically see me on the upcoming signal suite, i hope it will work as seamlessly as the phone number identification.
ideally i would be able to add multiple phone numbers by verifying them once, THAT would be killer.

until them i'm staying patient and wait for texting support on ios and multi device support and the firefox extension.

excuse the long post. hope to shine more light on wy email identifiers are important for a certain user group.

@ghost
Copy link

ghost commented Nov 15, 2014

I noticed there's a new repository called websocket-resources (https://github.com/WhisperSystems/WebSocket-Resources). Does that mean new identifiers are coming?

@Mannshoch
Copy link

How do you think about supporting gnunet?
Maybe the http://pep-project.org could be an entry point.

@JavaJens
Copy link

JavaJens commented Mar 5, 2015

@Manhole11 The repository you linked to has nothing to do with identifiers. This is just to allow easier handling of requests+responses sent over websockets.

@signalapp signalapp locked and limited conversation to collaborators Mar 5, 2015
@automated-signal
Copy link

GitHub Issue Cleanup:
See #7598 for more information.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

10 participants