Introducing Telegram Passport(telegram.org)
telegram.org
Introducing Telegram Passport
https://telegram.org/blog/passport
84 comments
Would Telegram and others please stop using phone number as a primary source of identity? It's 2018, I have a data only sim and I have no desire to have a phone number.
If I could only upvote this more. I still want someone to take signal's protocol and do a BYOK approach. Let me use Keybase or something similar to handle identity management. Additionally, each device (or app instance) gets its own key. Signal and WhatsApp already do encrypted group messages. Treat each of my devices as different "users", who present with the same name.
It's a tractable problem.
(NB: Not necessarily keybase, but they do have a technical solution to the problem in place already.)
It's a tractable problem.
(NB: Not necessarily keybase, but they do have a technical solution to the problem in place already.)
Keybase has chat. Available on desktop and at least Android
Yes. But it doesn’t offer some of the features Signal Protocol does. I do use it though.
keybase is a proprietary walled garden.. so.. no thanks.
Proprietary? The backend maybe, but the keybase clients are open source. Some of the code is a little rough, and completed API docs would be nice, especially concerning KBFS, which is still missing. It's still under heavy development though, so these shortcomings should be understandable. (I personally won't use it much until I can actually develop my own non-reverse-engineered client, but that's just my requirement.)
I'm guessing you meant non-decentralized?
I'm guessing you meant non-decentralized?
No, the server implementation is proprietary. Therefore, it's a walled garden that relies entirely on them. Supporting federation would be going above/beyond just releasing the server implementation's source under a permissive license. As it stands today, you have no choice but to rely on their proprietary server implementation, since the clients are useless on their own.
Considering the whole point of end-to-end encryption is to reduce or eliminate necessary trust in the middleman, this seems like a minor, but still valid concern. Open sourcing the backend code wouldn't allow you to attest to what's running on the server. If the clients also allowed you to point to a custom server URL, which I would support, then the source availability might matter.
Without the proprietary server backend, you cannot use the clients. It's a walled garden. If keybase goes away for whatever reason, you're stuck. You cannot host it yourself, others cannot host it, and even if they released binaries, you'd have no idea what it is doing with the unencrypted 'metadata'.
I didn’t dispute the description of Keybase being labeled a walled garden. I opposed it being too-broadly called proprietary, when it’s not — only the backend is. And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective, which is the reason people usually (mistakenly) bring up source code availability.
Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.
About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Now I’ll also partially dispute the accusation of it being a walled garden, since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
The backend source code would be good to have, for the prudent reason you pointed out, as well as for private instances, but that’s not enough: you also need client code modifications to allow configuration for custom servers.
About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
> And for anyone only using the official keybase servers, that’s irrelevant from a trust perspective
Gosh, not really. They completely control who can use the service, and any information they 'require' to register for the service.
> since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
I'd like to point out that walled gardens will still openly invite folks to join, and give them tools that they could reproduce, but give them no way to experience the garden outside the walls.. including the tools previously given that are also useless outside the walls. That's exactly the case with keybase.
> About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Huh. I'm interested in hearing how having source code makes autiting more difficult, since that has not been my experience.
Gosh, not really. They completely control who can use the service, and any information they 'require' to register for the service.
> since walled gardens don’t have open specifications and documented APIs for third-party client implementations.
I'd like to point out that walled gardens will still openly invite folks to join, and give them tools that they could reproduce, but give them no way to experience the garden outside the walls.. including the tools previously given that are also useless outside the walls. That's exactly the case with keybase.
> About binaries: anyone who thinks source code is required for determining program behavior probably shouldn’t be auditing software in the first place. (Often having just the source code makes it more difficult, not less.)
Huh. I'm interested in hearing how having source code makes autiting more difficult, since that has not been my experience.
I agree with you that Keybase should release their backend code. My comment about (server source code- derived) trust was made in the context of users who would remain using the official keybase.io API servers, which would probably be the vast majority of Keybase users.
It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:
- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)
- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example
- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)
- the tools for analyzing binaries are often more advanced than code tools
It’s not all of the time, or even most of the time, but frequently there are reasons for preferring binaries:
- build systems which are more annoying to setup than just straight reading the assembly / IL dump (ex: android)
- you might want to reverse and/or edit the binary anyway — to look at compiler output, as one example
- it’s sometimes faster to understand the asm than it is to go over the code, compile it, and compare [non-]matching binary outputs (this is regularly true for smaller programs)
- the tools for analyzing binaries are often more advanced than code tools
I cannot up-vote this more.
Many people don't realise that they don't own their phone number! It is possible to own a phone number but it is not widely available just like domains are. Hence it is a stupid idea to use it as an identity.
Many people don't realise that they don't own their phone number! It is possible to own a phone number but it is not widely available just like domains are. Hence it is a stupid idea to use it as an identity.
I recently learned this the hard way. I changed my phone number after moving cities, and AT&T just leased my old number to someone else!
There is a finite supply of numbers. Not recycling old numbers and just throwing them in a hole forever wouldn't be very prudent.
There is an infinite supply of numbers. You can just add extra digits. Mobile phone numbers used to be 8 digits in NZ, then became 9 digits when they needed more numbers.
Numbers aren't limited to the amount you can count, there will always be more.
What did you expect was going to happen?
I'd expect it to be reused _eventually_; not right away though.
With a self-sovereign identity, you are in control. Our IETF draft + running code: https://tools.ietf.org/html/draft-pouwelse-trustchain-01#sec...
Our goverment even sponsors this work. Decentral, no need for Russian servers.
Same. I'm nomadic at the moment, and have to change sims with each country. I don't have a permanent phone number (or address). I know I'm in a minority, but still... it's like
things businesses assume about people: 1: they have a phone number. 2: they have an address. 3: the country they are in at the moment is the country they live in
things businesses assume about people: 1: they have a phone number. 2: they have an address. 3: the country they are in at the moment is the country they live in
Project Fi from Google has been a lifesaver for me while traveling. I get to use the same number everywhere I go and don't have to do the new SIM dance in every country I visit. It can also be very handy sometimes to have internet access minutes after hitting the tarmac.
They've also expanded it to support more phones recently. I think having a Fi phone, even if it's not your primary device, makes a lot of sense for nomads.
They've also expanded it to support more phones recently. I think having a Fi phone, even if it's not your primary device, makes a lot of sense for nomads.
yeah, that looks great for Americans, I guess. Again, another thing businesses assume about people: they're American ;)
There are plenty of disadvantages for Americans trying to live as nomads too, believe me.
zip codes. Whenever I see a form saying "enter your zip code" I know I'm in for a terrible user experience :(
I think everyone wants phone numbers to prevent people generating billions of accounts to spam people with.
Agreed that such services should stop using phone numbers. In the meantime, you can get inexpensive numbers from https://jmp.chat/ - useful for 2FA as well.
That's technically not two factor if you only need to know a password to get access to the one-time code.
It's two passwords, both are something you have to know, there's nothing you need to have or be (sms and biometrics respectively)
It's two passwords, both are something you have to know, there's nothing you need to have or be (sms and biometrics respectively)
Yeah I use Google Voice for this purpose, which isn't _really_ 2fa anyway (because it's my google account).
[deleted]
Some services somehow know that the phone number is VoIP (Google Voice) and disallow you from using it with TFA. IIRC, Steam is one example.
Add signal and whatsapp (not that i use whatsapp) to that.
This is possible? Or do you technically have a phone number but just don't use it? Also, don't lots of situations require you to give a phone number? How do you handle that?
It's a Google Fi data only sim, so nope no real phone number. I do have a number through Google Fi and Google Voice, which usually works for 2fa but not always. The phone number goes directly to voicemail always.
Using a phone number does let the app quickly build a social graph of your friends using it. But email could do the same thing, with higher risk of fake accounts.
It could be worse, an app could say "You must sign up with Facebook"
It could be worse, an app could say "You must sign up with Facebook"
In cases like these I usually buy a pre-paid SIM for a few cents, verify the account and throw the SIM away. I can continue to use my main data SIM then.
Then in the future the number gets recycled and someone else suddenly takes over your account.
WhatsApp lets you set a pin number to prevent this. Can't remember if Signal does similar..?
WhatsApp lets you set a pin number to prevent this. Can't remember if Signal does similar..?
I just keep a rando Skype number for this kind of stuff. After the first login Telegram will typically ping your other active devices anyway.
You are forgetting social graph embedded in phone book.
No one else would give you social graph that easily.
No one else would give you social graph that easily.
Intentionally building Chatdog (https://chat.dog) to not require a phone number.
I’m not sure if I’d really trust any platform to store my personal documents without encrypting them myself before the upload.
But I’m always amazed at the pace at which Telegram keeps improving its feature set and UX. I haven’t experienced a messaging platform that’s anywhere close to it on these aspects. And for these reasons alone, it still remains my primary messaging application (while I keep checking the competition to see where they are).
But I’m always amazed at the pace at which Telegram keeps improving its feature set and UX. I haven’t experienced a messaging platform that’s anywhere close to it on these aspects. And for these reasons alone, it still remains my primary messaging application (while I keep checking the competition to see where they are).
I really wish telegram would focus on being a messaging app and not whatever this is. I'm not going to trust them with my info.
Any reason in particular you choose not to trust Telegram? Or you're just (rightfully) distrustful of sharing that info in general?
Personally I don't trust telegram because of their funding source.
Additionally their first encryption protocol was extremely wonky and most people I know would correctly call it unsafe for use in a chat messenger.
Their second version is a tiny bit better but neither has been verified by any proper cryptographer I know.
Additionally Telegram as an App seems more like a Toy rather than a proper chat app, the stickers are big and completely destroy the flow of a conversation last I checked it. Other features are like this too.
Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
Additionally their first encryption protocol was extremely wonky and most people I know would correctly call it unsafe for use in a chat messenger.
Their second version is a tiny bit better but neither has been verified by any proper cryptographer I know.
Additionally Telegram as an App seems more like a Toy rather than a proper chat app, the stickers are big and completely destroy the flow of a conversation last I checked it. Other features are like this too.
Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
> Personally I don't trust telegram because of their funding source.
You could say the same for Signal (before Signal Foundation was created this year) or Wire (created by the people who created Skype) too.
> Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
The “secret chats” are always end-to-end encrypted. The normal chats are encrypted only in transit and not end-to-end. But secret chats are also tied to a single device (currently only phones), unlike Wire, which offers end-to-end encryption and synchronized conversations across devices.
You could say the same for Signal (before Signal Foundation was created this year) or Wire (created by the people who created Skype) too.
> Lastly, to my knowledge, end-to-end encryption is not enabled by default, neither for private messaging or groups. That's just a no-go for any chat application for me.
The “secret chats” are always end-to-end encrypted. The normal chats are encrypted only in transit and not end-to-end. But secret chats are also tied to a single device (currently only phones), unlike Wire, which offers end-to-end encryption and synchronized conversations across devices.
>Wire (created by the people who created Skype) too.
Wire is also Open Source.
>The “secret chats” are always end-to-end encrypted.
Secret Chats come with too many drawbacks and other message applications seem to do perfectly fine. As you mention, only one device.
>The normal chats are encrypted only in transit and not end-to-end
That is TLS and not E2E encryption which is also a total no-go for me.
Wire is also Open Source.
>The “secret chats” are always end-to-end encrypted.
Secret Chats come with too many drawbacks and other message applications seem to do perfectly fine. As you mention, only one device.
>The normal chats are encrypted only in transit and not end-to-end
That is TLS and not E2E encryption which is also a total no-go for me.
They're not going to. They're trying to follow the example of WeChat and build tons of other features on the identity layer created by messaging.
Remember, it's not a mandatory thing, you can continue to use telegram just like whatsapp.
But telegrams apps and Bots are growing exponentially and the developers unnecessarily keeping a basic work flow outside telegram, which is painful.
But telegrams apps and Bots are growing exponentially and the developers unnecessarily keeping a basic work flow outside telegram, which is painful.
I can't help not to trust telegram with my data, just gut feeling. You cannot use their service without giving your telephone nr. Now they like to have your ID's too. How can they honestly advertise "anonymus chat"? And the double ICO, over a billion fetched. So much money and data, where does that lead to?
I have a similar distrust of Telegram just because of where they started. (and I admit that isn't logical) But I think I trust someone with lots of data AND lots of money than someone who only has lots of data.
I wouldn't remember a time where telegram claimed anonymous chat. Sure encrypted chat, private chat, not collaborating with fbi for chat history are good things.
But telegram never advertised anonymity as a takeaway.
But telegram never advertised anonymity as a takeaway.
Wonder if this was influenced in part by the fact that Telegram is the messaging service used by most ICO organizers. Could help in the KYC process that is becoming more commonplace.
The unintented consequence of this will be that now any website can easily demand real life ID. Ordinary, non-financial websites (think Reddit, Twitter, Hacker News) will require ID to log in, to protect against spam and make the community safer.
This implements the dream of authoritarian governments that internet access should never be anonymous. Russian government officials have long wanted to establish a similar authentication system.
Is Pavel with us or against us?
This implements the dream of authoritarian governments that internet access should never be anonymous. Russian government officials have long wanted to establish a similar authentication system.
Is Pavel with us or against us?
Many people don't use Telegram and presumably most sites can't afford to alienate that many people.
Telegram has a history of including fairly obvious backdoors in their products https://habr.com/post/206900/
Why should anyone trust them for identification or for storing sensitive documents?
(And no, that DH behavior cannot be explained away as a simple mistake)
Why should anyone trust them for identification or for storing sensitive documents?
(And no, that DH behavior cannot be explained away as a simple mistake)
I feel that your post is being a bit dishonest, as it ends with the following:
> UPD: The story ended well. Vulnerability is corrected, documentation and applications are updated, treasure hunters of bugs are motivated, which has already yielded results (1, 2). It is necessary to pay tribute to the developers of Telegram, who immediately reacted to the article.
It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
Durov and Telegram have more or less shown their mettle; there was no money or profit in standing up to Russia, but they went ahead and did it anyways when it would have been easier to buckle. Yes, it has flaws in its implementation, but so far they've proven that when push comes to shove, they're willing to fight for their politics and to keep on fighting against such regimes. Once this changes, sure, it's fine to lay into them, but right now it really looks like they're true to their word.
> UPD: The story ended well. Vulnerability is corrected, documentation and applications are updated, treasure hunters of bugs are motivated, which has already yielded results (1, 2). It is necessary to pay tribute to the developers of Telegram, who immediately reacted to the article.
It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
Durov and Telegram have more or less shown their mettle; there was no money or profit in standing up to Russia, but they went ahead and did it anyways when it would have been easier to buckle. Yes, it has flaws in its implementation, but so far they've proven that when push comes to shove, they're willing to fight for their politics and to keep on fighting against such regimes. Once this changes, sure, it's fine to lay into them, but right now it really looks like they're true to their word.
> It's hard to say that it's not a mistake when the author of the article itself describes their response as "immediate".
It is an obvious backdoor.
They justified XORing in arbitrarily string into the key you have established with DH with the fact that your phone may have bad random number generator. But it obviously gains you nothing. If the server is honest, then it does not read your secret chat anyway. And if the server is malicious or compromised, it knows the string.
So even if it is possible to overlook the possibility of XORing in the difference of keys and evading MITM detection, it is very unlikely that no developer (for example, someone who coded it into the server or one of the clients) have seen that it gains you nothing in any scenario you can think about.
When users started to asking developers for the explanation in the comments, W_K (main developer of the protocol, brother of Pavel Durov) stated that they "don't know" who added this feature in its current form. Shortly after, he stopped using his account or answering any questions at all: https://habr.com/users/W_K/
Upd: regarding the remark in the end of the https://habr.com/post/206900/ that "the story ended well", Telegram team is responsive etc.
Keep in mind that they paid this guy. Adding such updates to articles and publicly confirming that the bug was fixed is almost surely a part of the bug bounty agreement.
It is an obvious backdoor.
They justified XORing in arbitrarily string into the key you have established with DH with the fact that your phone may have bad random number generator. But it obviously gains you nothing. If the server is honest, then it does not read your secret chat anyway. And if the server is malicious or compromised, it knows the string.
So even if it is possible to overlook the possibility of XORing in the difference of keys and evading MITM detection, it is very unlikely that no developer (for example, someone who coded it into the server or one of the clients) have seen that it gains you nothing in any scenario you can think about.
When users started to asking developers for the explanation in the comments, W_K (main developer of the protocol, brother of Pavel Durov) stated that they "don't know" who added this feature in its current form. Shortly after, he stopped using his account or answering any questions at all: https://habr.com/users/W_K/
Upd: regarding the remark in the end of the https://habr.com/post/206900/ that "the story ended well", Telegram team is responsive etc.
Keep in mind that they paid this guy. Adding such updates to articles and publicly confirming that the bug was fixed is almost surely a part of the bug bounty agreement.
None of this addresses the fact that there's no other realistic explanation for this besides an intentional backdoor.
[deleted]
This looks rad. Unfortunately, I won't be able to use Telegram Passport. I can't even read this post without a proxy because my government actively blocks Telegram without a publicly given reason.
I wish they'd spend more time figuring out how to get around the domain fronting problem.
Then again I'm rambling.
I wish they'd spend more time figuring out how to get around the domain fronting problem.
Then again I'm rambling.
I wonder if its using the same "roll your own encryption" that the chat app is
Their messaging application had horrible security in past, and there have been many discussions on HN about Telegram vs Signal. Why would I trust them for ID when their messaging was suspicious....
Please, provide sources if you’re willing to say something like that.
Have you read the article you linked? Nothing in it is remotely closed to what one would call “horrible security”.
I'd more happy if they would implement an option to turn-off link fetching and also ability to use their service without phone number.
As for this Passport - I'm not interested in this feature and I can't see where it would be useful for me. Not mention the security with just their assurances that nobody would have an access to my personal info - it's ridiculous to say least.
As for this Passport - I'm not interested in this feature and I can't see where it would be useful for me. Not mention the security with just their assurances that nobody would have an access to my personal info - it's ridiculous to say least.
If this is to deliver your ID for the purposes of KYC laws, then that’s somewhat sensible, I suppose.
If, however, this is targeted at the providers who are actually collecting IDs as part of their AML compliance strategy, then there’s a much simpler solution here: just become the ID equivalent of a Certificate Authority. Dedup Telegram accounts by using a unique constraint on accounts’ validated ID documents’ extracted creds; and then allow sites to use Telegram for Single Sign-On. Boom—instant surety that each of your users is a real person, and not fifty bots laundering one person’s money; and no need for anyone besides Telegram to actually see your ID (i.e. a much lower chance of identity theft.)
Plus, if enough sites require SSO through an ID-document verifying identity provider, then even sites that ha d no legal reason to require it can free-ride off the benefit in user-deduplication it provides. Imagine, for example, a Reddit or a 4chan where users are still pseudonymous or anonymous, but where banning a user truly works, permanently, with no routing around it (unless you have the criminal connections required to buy yourself a new real-world identity.)
If, however, this is targeted at the providers who are actually collecting IDs as part of their AML compliance strategy, then there’s a much simpler solution here: just become the ID equivalent of a Certificate Authority. Dedup Telegram accounts by using a unique constraint on accounts’ validated ID documents’ extracted creds; and then allow sites to use Telegram for Single Sign-On. Boom—instant surety that each of your users is a real person, and not fifty bots laundering one person’s money; and no need for anyone besides Telegram to actually see your ID (i.e. a much lower chance of identity theft.)
Plus, if enough sites require SSO through an ID-document verifying identity provider, then even sites that ha d no legal reason to require it can free-ride off the benefit in user-deduplication it provides. Imagine, for example, a Reddit or a 4chan where users are still pseudonymous or anonymous, but where banning a user truly works, permanently, with no routing around it (unless you have the criminal connections required to buy yourself a new real-world identity.)
Companies that deal with money aren't going to use SSO; they want to own their login system.
Even governments are willing to use SSO if it's SSO using entities both they and their customers trust with their money, e.g. major banks. (At least, that's how it is here in Canada with https://securekeyconcierge.com.)
Given that Telegram is already a payment processor (i.e. something people trust with their money), it could serve a similar role, no?
Given that Telegram is already a payment processor (i.e. something people trust with their money), it could serve a similar role, no?
Well done telegram, I'm concerned some weird government might give a hard time before collecting these sensitive details.
While every third party is doing these things everyday, Telegram is under the risk of getting targeted.
While every third party is doing these things everyday, Telegram is under the risk of getting targeted.
No, thanks
The art is very interesting. Reminds me a lot of Fallout :P
Pretty much ripped off Civic https://www.civic.com
Wonder how the price of CVC is impacted today...
Wonder how the price of CVC is impacted today...
It takes a player with some size to move the needle on this one. And likely we'll have a few of these services. Civic still has a roll to play.
Upload all of my non-decentralized identification documents to a decentralized cloud? What could possibly go wrong?
A cryptocurrency, now this? How long before the delicious Telegram™ Steaks™.