infosechandbook

8 ms·

1.
by infosechandbook 5y ago
> You can save XMPP account IDs in any mobile address book. ... while the rest of the XMPP account remains on the XMPP server, inaccessible. There is no benefit as you can also store other primary IDs like phone numbers in your address b
2.
by infosechandbook 5y ago
Just one question as the rest was discussed numerous times before: > At least with XMPP, I can point the same client to some other server and potentially continue a conversation with someone somewhere else, with the exact same OMEMO&#x2F
3.
by infosechandbook 5y ago
You just wrote it is "silly" to compare XMPP with Signal while constantly doing it yourself. > Signal admins too can ship you an app Or I could just use my own Signal client since it is open-source and there are several working
4.
by infosechandbook 5y ago
Yes, Quicksy from the Conversations developer who bragged about copying main features of WhatsApp and Signal. Another one is Kontalk, https://www.kontalk.org/ . Both XMPP clients require a phone number, and both present the
5.
by infosechandbook 5y ago
> I can link a raspberry pi anywhere in the world to my XMPP server with a few lines of Python and some libraries. Once again, "I, as a tech-savvy person, can operate my highly-customized XMPP setup everywhere", while ignoring
6.
by infosechandbook 5y ago
> The Signal protocol is neither an open (you cannot propose changes or extensions in an open process) nor has it been submitted to an standards body. Who defines "open standard" in the first place? There is no global definitio
7.
by infosechandbook 5y ago
> Comparing Signal with XMPP is silly. Could you please add your statement to any other comments by XMPP proponents that state "XMPP is better than Signal because ..."? Plus, could you also consider this for all of your own com
8.
by infosechandbook 5y ago
> If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experiment
9.
by infosechandbook 5y ago
> claiming XMPP is either the best ... Unfortunately, this seems to be the starting point of most discussions on XMPP. Somebody claims that XMPP solves all problems, and is secure and private. Or they present a highly-customized, non-def
10.
by infosechandbook 5y ago
> Signal operators can also inject messages to people. Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spo
11.
by infosechandbook 5y ago
> Have you read the joinjabber.org security FAQ i linked? Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ. > we were tired of FUD spread by articles l
12.
by infosechandbook 5y ago
> How many of your contacts who use Signal used their real phone number? Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be manda
13.
by infosechandbook 5y ago
> disclosed to the server admin Please read the article before and after these items. The first finding isn't about the server admin but about external parties such as law enforcement (not the user, not the admin). The reason for th
14.
by infosechandbook 5y ago
Nobody claimed that they look the same. As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then
15.
by infosechandbook 5y ago
> I already responded to your "admin in the middle" article here And we already responded here: https://news.ycombinator.com/item?id=29106376 , and here: https://infosec-handbook.eu/news/202
16.
by infosechandbook 5y ago
> Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone n
17.
by infosechandbook 5y ago
> How should that be possible if OMEMO is enabled (which is the default in more modern clients)? See https://infosec-handbook.eu/articles/xmpp-aitm/#t5 TL;DR: XMPP clients can't distinguish between legitim
18.
by infosechandbook 5y ago
> What would be your alternative? A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosy
19.
by infosechandbook 5y ago
> XMPP is as secure as Signal nowadays, it implements the same encryption scheme Signal enforces E2EE, you can't disable it. If XMPP supports E2EE depends on the XMPP clients and servers, so it isn't enforced and can be disable
20.
by infosechandbook 5y ago
The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security featur
21.
by infosechandbook 5y ago
The guide is outdated if you rely on the latest version of OpenSSH. You must update such guides with every new version of OpenSSH. Adding legacy configuration to your OpenSSH config files can even result in a false sense of security (e.g.,
22.
by infosechandbook 5y ago
> Almost none of the XMPP clients use plain text connection nowadays. Everything shown in the article works with or without TLS enabled. It doesn't matter. The server-side party sees cleartext XMPP packets passing the server. > a
23.
by infosechandbook 5y ago
Excellent example for what we mean: Our article doesn't discuss anything about "What is needed to register for service X." Discussing this is perfectly valid; however, it isn't about the article.
24.
by infosechandbook 5y ago
> If you recommend X instead of Y, it seems reasonable to discuss not only the downsides of Y but also how X is better or worse in comparison to Y. Indeed. One should mention upsides and downsides of a solution. In our opinion, many &quo
25.
by infosechandbook 5y ago
> I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password
26.
by infosechandbook 5y ago
> the user isn't really in control of who can see this information Server-side parties (e.g., the admin) can see the status information without adding somebody to the group. It is in cleartext, passing the server.
27.
by infosechandbook 5y ago
Hi, authors here (Again, as we already have had the pleasure a while ago). > The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are uniqu
28.
by infosechandbook 5y ago
Hi, authors here. > I don't understand why the infosec-handbook.eu article appears posted on november 1 2021. It was published in August 2018 We fully revised this and other articles as mentioned on our website. The article itself c
29.
by infosechandbook 5y ago
Hi, authors here. We recommended alternatives back in 2019 when we published this article originally. Unfortunately, people then started to discuss why all of these alternatives were much worse according to them, distracting attention away