I didn't mean to stir it up again, but it bothers me to leave so many misstatements & petty attacks unanswered in my own thread, so here we go:
Message 1:
[About Equilibre.io] They will still need to provide credentials and confirm the signing request in the target wallet, [...].
False Equilibre.io signing interface doesn't ask for user public keys.
Users have to wait for at least 3 browser redirects and provide credentials, so each operation takes 10-20 seconds instead of one click as before. That's maybe ok for Equilibre [...]
False There's no configuration under which Equilibre.io requires 3 browser redirections + providing credential for tx signing.
As for all other questions... Looks like you completely missed some of my points, as your answers do not address most of them at all.
Unbacked accusation That sentence is dropped as it. We'll never know which point wasn't answered, and I believe there wasn't any.
And I checked NiceTrade.co. I must say that it's the worst login form I have ever seen.
Insulting Dexter is the first dev to use sep10 in production and deserves kudos for that. The first step is rarely perfect.
Forcing a user to save a public key separately (where? in text file?) and copy-pasting it (following your logic, that's a big no-no, as it may break user's privacy by associating a person/device with a Stellar account)
False There's no such thing as forcing users to save public key - federated addresses are supported in the software I mentioned. There's no such thing as copying a pubkeys from text files - most wallets provide a copy-on-click feature.
Reinterpretation I never said that public key should not be copied.
Poor technical understanding There's a difference between public and private keys. Public keys are meant to be shared and can safely be copy/pasted. The idea that an attacker would listen to the clipboard for public keys to break one's privacy is kind of ridiculous at that point.
[about NiceTrade.co] each time when a user needs to log in,
Disinformation it sounds like it happens a lot, while NiceTrade sessions are remembered. You need to log in once per machine, just like Keybase.
Even requesting to sign an empty transaction is better than that, at least it's possible to authenticate a user and retrieve a pubkey in one go.
Poor technical understanding Doing it that way, it wouldn't be possible to authenticate the origin of the login request... In other words, it wouldn't work.
About my statement that copy-pasting is ubiquitous:
[MisterTicot] Many applications have addressed it already in many ways
Nope. I haven't seen any other option across the entire Stellar ecosystem
Denial Here are solutions that have been used to prevent secret sharing, some of them since years:
- Custodial wallet (PapayaBot)
- Pubkey scanning (Stargazer)
- Payment request (StellarKey, Stargazer)
- Keystore (StellarPort)
- Key Encryption + local storage (Stellar Authenticator)
- Key encryption + distant storage (StellarX)
- XDR copy/pasting (StellarLaboratory, Stellar Authenticator)
- Sep7 (Keybase)
- Sep10 (NiceTrade)
- SatoshiPay (Lumenthropy)
- Cosmic.link (PublicNode)
- Payment plugins (StellarPay, SWPlug)
If you need to submit transactions on behalf of an existing account, you need to either request a secret key (at least once) or use delegated signing.
False Submitting transactions on the behalf of the user is not the same as signing transactions on the behalf of the user. The first happens part of multi-signature coordination and doesn't require secret key nor delegated signing. (e.g: StellarGuard)
Given current progress, mature delegated signing tools for Stellar Network will be ready in a year or so (hopefully)
Denial Mature delegated signing tools are ready right now, and Cosmic.link is production-ready since a year and a half. I'll add that no other cryptocurrency project has such a generic tool available yet.
The browser Clipboard API [...] was just an illustrative example for one of a few attack vectors exploiting the potential vulnerability you mentioned without breaking the sandbox
Technically false The browser clipboard API is precisely not an attack vector because it is sandboxed. There are workarounds but at that point, this renders the attack unprofitable.
The Android example, of course, demonstrates much stronger case than, say, Windows XP
Denial Using "of course" about something you couldn't figure out by yourself.
careless Linux user running all processes under the root privileges (btw, why we are overlooking them?)
Because nobody does that.
For the particular case you described, I can agree that "it is orders of magnitude less secure", as you wrote.
Denial Storing secrets in plain text and copy/pasting them around is orders of magnitude less secure in all possible cases.
However, my main point here is that a compromised system (with the malware code in userspace) can't be viewed as secure even with all the delegated signing in place.
Denial In your previous comment, you defined a "compromised system" as one where root access was gained. Now, you redefine it to avoid admitting your point was wrong.
Technical false A malware is typically under the same security restrictions as other software and cannot perform actions that require permissions without asking the user first. Under Android/iOs, only copy/pasting is weak against malware without permission, and most of the alternative ways I mentioned are resistant against malware with permissions.
(Namely: custodial wallet, pubkey scanning, payment request, key encryption + local storage, XDR copy/pasting, sep10, SatoshiPay, Cosmic.link, Payment plugins are resistant. Keystore, key encryption + distant storage and sep7 can be broken under certain specific conditions)
Android Autofill framework and Accessibility API (previously it was used by password managers like LastPass to interact with text input of third-party apps) make it much simpler to steal login/password credentials
False Accessibility API requires permission and both can be broken only when devs leave a hole. Peeking at clipboard is easier, works against all app and is less likely to get spotted as malicious.
And if users are naive enough to install the malware [...]
Denial This statement is meme-epic. Users don't know they are installing malware, that's the very concept. Under Windows, they remove them by dozen using tools such as CCleaner. On phones, most apps intentionally embed malware that shows ads, track users and harvest data for money.
Apps that got spotted mining XMR could as well had peeked at clipboard for private keys. If your "view" of security only includes people who never installed malware, then you'll only have to care about a handful of *BSD users... who can already deal with themselves.
So the app storing user's secret key on the server can be as easily hacked as the one requesting it directly from the user.
Reinterpretation What I previously said was that applications storing encrypted keys locally, such as Stellar Authenticator, are resistant against the attack. Apps that store secrets online & allow to sign in from any client are out of the public key cryptography security model & are indeed weak to credentials stealing attacks.
It's always worth mentioning specific details about the environment and prerequisites in security-related articles.
Denial No it's not: it would inform script kiddies, it would be too complicated for casual readers, and wouldn't be of much use for decent developers as they can figure out by themselves the consequences of a statement such as "the clipboard is readable system-wide".
[MisterTicot] This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.
It would be really awesome to check statistics supporting this claim.
Denial If scammers were the only ones to ask for secrets, few people would get caught. It doesn't take statistics to understand that.
Someone might even say that the intentionally misleading article that purposely omits important facts and attack prerequisites in profit-seeking effort may be viewed as unethical
Denial Security advisories are always written in a concise way (example). They describe a security flaw & devs are expected to be able to infer attacks for that description. For obvious reason, I never intended to describe the attack or provide the code snippets Gleb asked for (sic!).
Gaslighting
- Your friend market secret sharing in his SCF communication.
- I inform users that this is an insecure practice.
- You say that my work could be seen as unethical.
Also, I apologize if any of my previous questions/comments upset or distressed you.
Gaslighting is a form of intentional aggression that is meant to trigger those very emotions. This is offensive regardless of whether or not it succeeds.
Comment 2:
That's exactly what I'm talking about. According to MrTicot, your application security model is flawed by default as clipboard is insecure. I have the opposite view - copy-pasting public or secret key may be a convenient option to login, at least until we have a better way to achieve that.
Re-interpretation I never said copy/pasting public keys was a problem.
Denial You make it sound like we're discussing opinions, but cryptography is rarely a matter of views but a matter of logic. By "security model", I refer to a set of conditions under which a given security feature is guaranteed. For instance, when it comes to asymmetric cryptography:
The identity of the signer is guaranteed as long as he did not share his private key.
Security feature: The identity of the signer is guaranteed.
Set of condition (1): The private key hasn't been shared.
That's how keypairs are meant to be used, this has been settled by scientists & experts more than 25 years ago and I don't think there's any debate going on on that matter.
IF the set of condition is not respected, THEN the security model is broken.
I agree that there are cases where it doesn't matter so much, but wallets in production are not one of these.
If one is looking for a well-implemented usage of cryptographic keypairs, GPG is the way to go. It protects identities, not money, but still: devs were serious and did things "the right way".
I reiterate my belief that cryptocurrency applications which doesn't respect this security model will hit a disastrous fail on their way toward mass adoption.
