> Some online streamers have been hacked as of late using AI models trained to steal their passwords using the sounds of them typing on their keyboards
do you have any sources for that?
I've only seen this mentioned from research results recently but no real world exploitation reports.
Years ago when I saw a paper on that topic, I tried recording my own keyboard and trained a ML model to classify keystrokes. I used a SVM, to give you an idea of how long ago this was.
I got to 90% accuracy extremely quickly. The "guessed" keystrokes had errors but they were close enough to tell exactly what I was typing.
If I could do that as an amateur in a few hours of coding with no advanced signal processing and with the first SVM architecture I tried, it must be relatively easy to learn / classify.
Also, if the goal was to guess a password you wouldn't necessarily need it to be really accurate. Just narrowing the search space could get you close enough that a brute force attack could do the rest.
ykcs11 allows you to use the native SSH agent (or even no agent at all for individual ssh invocations) with an ssh key on a yubikey using their pkcs11 provider.
When you see a guide containing a 7 step manual to do something that should be simple, it's worth taking a step back and consider the question if you can make this valueable security feature more easily accessible.
Side-loading so-names into your security critical apps is probably something you should be more critical of as well.
are you extending this to the usage of yubikey-agent and ssh-tpm-agent as well?
both variants, whether it's using a PKCS11 provider using a standardized interface, or using a completely custom SSH agent, will need to deal with secret material.
although I'm no expert on the inner workings of SSH, I'd expect there to not be much difference between having the OpenSSH agent interface with ykcs11 (which is also open source and can be reviewed) and using an alternative agent with piv capabilities that was found on github.
>both variants, whether it's using a PKCS11 provider using a standardized interface, or using a completely custom SSH agent, will need to deal with secret material.
`ssh-tpm-agent` is not dealing with secret material. That is delegated to the TPM and we are only in the business of telling the TPM to sign stuff for us. Yubikey-agent does create a private key on the machine before inserting it into the yubikey.
I would not call these two things equal and there are a difference to what the potential impact is.
>although I'm no expert on the inner workings of SSH, I'd expect there to not be much difference between having the OpenSSH agent interface with ykcs11 (which is also open source and can be reviewed) and using an alternative agent with piv capabilities that was found on github.
> No, as they never get loaded into the ssh binary and are external programs communicating over an interface.
my understanding is that the same would apply if you use ykcs11 in the OpenSSH agent instead of using it directly in `ssh`, which would make this a comparison between (OpenSSH agent + YKCS11) vs e.g., ssh-tpm-agent.
from the qualys report you linked:
> Note to the curious readers: for security reasons, and as explained in
the "Background" section below, ssh-agent does not actually load such a
shared library in its own address space (where private keys are stored),
but in a separate, dedicated process, ssh-pkcs11-helper.
additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.
> `ssh-tpm-agent` is not dealing with secret material.
while the agent is certainly not accessing the private key directly, as long as you can access the agent and make it sign whatever you want, this will still be a very valuable vulnerability, with the only downside (compared to non-HSM keys) that you won't have persistent access to the private key, only temporary access for signing.
this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.
> There is a separation of concerns here though.
when you compare (OpenSSH agent + YKCS11) to ssh-tpm-agent, they're both separated from the main `ssh` process and communicate through the SSH agent API.
PKCS11 allows you to use `ssh -I /path/to/lib.so` directly, which there doesn't seem to be a comparable alternative for in ssh-tpm-agent, so I'll ignore that feature for now.
>additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.
You are not going to see similar exploits available in a program written in Go, it would result in a crash. Not an actual code execution issue.
So you are removing attack surface by not loading shared libraries, and quite a bit of attack surface considering it's not written in C.
> this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.
Allowing better UX would also allow people to utilize better and more secure defaults. The PKCS11 stuff is general unfriendly and using it correctly as a result gets harder.
This isn't only about attack surface, but also enabling more user friendly tooling.
note that this is technically against their TOS if not using paid accounts:
> One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine)
and Jack Dorsey happens to have put up a 1 billion sats bounty to """Create a “complete” Nostr-based suite of git tools, such that projects like bitcoin-core are sufficiently confident to move away from GitHub."""
Well, to be fair, some of the most vile hateful stuff I've ever seen in my life was posted on Facebook-powered comment sections under news articles, next to real names and pictures of smiling grandparents holding their grandchildren
It's a really tough situation. I want both at the exact same time. But since that's not possible, I lean towards anonymity. Stuff that's published on the internet is out there forever. Because of automated tools that exist now and that will only get better in the future, it will be easy to surface.
And it's hard because there's so many ways someone could make connections that aren't immediately obvious. For example, I used to have my home's IP address set as a subdomain of the same one I use for email (for VPNing in). But later I thought about it and realized that anyone could easily look at the DNS records for my domain and know more than I really want them to.
If you really were on the web since before gnu/Linux you would never have expressed it that way...
You'd say you were around when you dialed into BBSes.... Like those who actually were on the "web" before gnu/Linux.... Do you actually understand what you claimed with that?
Quick edit: just in case it's not clear enough
"First released on September 17, 1991, by Linus Torvalds"
"By Christmas 1990, Berners-Lee had built all the tools necessary for a working Web"..."In 1991 the Commercial Internet eXchange was founded"
Unless you were friends with Tim it's literally impossible....
That's one of my favorite parts of reddit. Accounts are just pseudonyms, and you can generate as many as you want. I personally generate a new one every few months, which helps keep too much identifying data from building up over time.
That's a term of service that I'm not too worried about. I'm not going to cry if they terminate those two accounts (main account is paid, so that's not in violation). And I'm not doing anything unusual or abusive with the accounts so I'm not worried they'll take action anyway.
