Closed generalmanager closed 6 years ago
for your list above, I suggest to add this:
@moxie0 Have you already considered BrowserID (Persona) https://github.com/mozilla/persona - "Persona" is a login system based on the BrowserID protocol ?
@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.
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. :)
@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.
I'd like to see plain OpenID supported as authentication.
@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.
@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).
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:
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.
@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.
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
@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.
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."
@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.
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.
Has any progress been made since April? Any news? Is anyone working on this?
Unfortunately I'm not aware of any new development, but the first big step will probably be email identifiers when websocket support is finalized: https://github.com/WhisperSystems/TextSecure/issues/1000
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.
I noticed there's a new repository called websocket-resources (https://github.com/WhisperSystems/WebSocket-Resources). Does that mean new identifiers are coming?
How do you think about supporting gnunet? Maybe the http://pep-project.org could be an entry point.
@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.
GitHub Issue Cleanup: See #7598 for more information.
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:
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.
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.
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:
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.