71–80 of 169 posts
Earlier quoted context omitted.
Not that hard (I've written Firefox extensions that run external programs), but what would you gain over SSL client certs, which are already supported?
I have an SSH key and use it routinely. I've never used SSL client certs.
What about this solution? https://www.grc.com/sqrl/sqrl.htm
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for…
I am not sure about this. First, there is a built in MITM attack here. First time you connect to sshd, the server has no idea who you are. I suppose this could be mitigated by using HTTPS as the out-of-band channel for verifying client and server fingerprints. Second, ssh keys are somewhat limited. You can only have one public key for a private key. You cannot embed identity info in the public key. I would much rathe…
That's not a problem if you signup by first connecting to the sshd and getting a custom signup URL.
I am not sure about this. First, there is a built in MITM attack here. First time you connect to sshd, the server has no idea who you are. I suppose this could be mitigated by using HTTPS as the out-of-band channel for verifying client and server fingerprints. Second, ssh keys are somewhat limited. You can only have one public key for a private key. You cannot embed identity info in the public key. I would much rathe…
This always sounds like a NSA shill argument to me. Sure, you can MITM, but then, you HAVE to MITM on the very first request of every user to make that work. That's much more expensive than vacuuming up passwords server side with gag orders.
>Second, ssh keys are somewhat limited... You cannot embed identity info in the public key.
That's ridiculous. Who would want to? You are looking for an authorization solution. SSH is for authentication.
Earlier quoted context omitted.
SQRL is vulnerable to phishing and spoofing attacks due to the lack of mutual authentication. I can send you a phishing email with a link to a webpage that looks like PayPal, on mynastydomain.com, and then display an actual PayPal QR code to you. There's no complete solution to this all the time you're passing tokens with an unauthenticated association over an air gap. The IP binding proposal is a just a disaster for…
@nly How does this system prevent me from setting up a website that looks like Paypal and giving you the address of my ssh server?
Btw i'm not liking this SSH solution either, I was just pointing out that's still better than SQRL, which is awful in that it has exactly 1 advantage (it protects users against password reuse) and many nuanced flaws.
I've worked in support of computing clusters that are widely used by researchers. By far the most common problem people had with using these systems was grokking ssh keys. Masters and PhD Computer Science people are routinely baffled by them, provide their private keys instead of their public keys, or provide both, etc. People in general just don't get public/private key pairs. Any solution that requires any awarenes…
"You send him a copy of your lock which he uses to lock a package and return it to you. Then only your key can open it!"
You immediately fix the problem of people sending their key, because people know keys are important and shouldn't be handed out to just anyone.
The PKI people are brilliant. Their communication skills, not so much.
...hard for first-time users to get right:... The private key being unlocked and available via ssh-agent.
For this to be convenient for daily use, ssh-agent is essential, and that could expose naive users to compromise. I know enough to disable ForwardAgent in my personal config by default and generate site-specific keys for hosts I can't trust, but that's beyond most ordinary users and even many of the technical professionals I deal with.
It's a shame PGP was the target of so much persecution when it came out. Maybe by now we would have worked out the key exchange problem and would all be enjoying personally encrypted communication on the Internet. I sometimes feel that any attempt to move beyond passwords without realizing that ideal is doomed to failure.
This is brilliant. Here a full-fledged solution: the same way every OS supports users, it should support identities attached to the user account (~/.ssh). Upon OS installation / user creation, it would prompt the user to either generate new identity, or import existing one (from a flash drive, from a cloud, etc.). This would be the key pair. And the browser would automatically use this, without any terminal session o…
Gee, I guess only I can drive my car. If only there were some way to share my car with my spouse. Like having a second set of keys or something...
Would this become more usable if it was natively supported by the web browser? Couldn't the browser take care of generating the keys and whatnot?