https://www.buskill.in/#demo*Watch the BusKill Explainer Video for more info youtube.com/v/qPwyoD_cQR4*You attach the kill cable to your body and if the connection between you to your computer is severed, then your device will lock, shutdown, or shred its encryption keys. It’s designed to protect high-risk users’ data. Data could include private keys (eg theft of cryptocurrency assets), contacts of correspondence (eg sources of a journalist – such as whistleblowers), etc.
I’ve paid myself nothing so-far. The price just barely breaks-even for the business. There’s one-time costs like a few grand for a CNC’d injection mold and assembly jig, but also certification fees, product boxes, cardstock paper for documentation inserts, printing fees, artist commissions, packaging materials, warehousing, shipping, other logistics fees, etc.
All of this is explained in-detail in “The Finances” section here.
I prefer open-source hardware to be designed using common off-the-shelf items that are easily found everywhere in the world. Unfortunately, the one vendor of a USB-A magnetic breakaway couplers decided to EOL their product shortly after I published a guide on how to build your own BusKill cable. After we published, they all got sold-out, and we had to go to manufacturers for a custom component.
Prices would drop dramatically if we could do production runs (and actually sell) >10,000 units at a time. Currently we only sell a few cables per month. If you want to help, please tell all your security-conscious friends about BusKill :)
Theft of high-risk users’ data. Data could include private keys (eg theft of cryptocurrency assets), contacts of correspondence (eg sources of a journalist – such as whistleblowers), etc.
For more information, see the Who Uses BusKill? section of the documentation.
Sorry, this is misinformation. Graphical CAPTCHAS can be trivially defeated by bots, as the lemmy devs have said.
If you want to slow the bots down, a hashcash implementation like mCAPTCHA would actually work and the lemmy devs already said they'd accept a PR for this.
Yeah, once they document how to use it, I hope they also publish an PSA telling all users to disable their existing keys and migrate to using Restricted API Keys
I consider "support" for this as having it documented. It's not a boolean "on" / "off". To "support Restricted API Keys" would mean that they document the minimum set of permissions required (which is a long list of properties, each set to "none" or "read" or "write").
Indeed, I'm very happy to see they've changed it from 'low-priority' to 'high-priority'. Hopefully they'll update the documentation with the permissions needed for Restricted API Keys soon.
I'm curious if any security engineers have covered this incident.
Stripe does support generating Restricted API Keys. With "Restricted API Keys" you're able to mint a key that can live on your e-commerce website that has permission to accept payments but does not have permission to modify your merchant account's payout methods (eg adding a new "Instant Payments" debit card to the merchant account as this attacker did).
Unfortunately, I've asked WooCommerce to support Restricted API Keys 1 year ago, but they marked it as "low priority"
I'm curious if any security engineers have covered this incident.
Stripe does support generating Restricted API Keys. With "Restricted API Keys" you're able to mint a key that can live on your e-commerce website that has permission to accept payments but does not have permission to modify your merchant account's payout methods (eg adding a new "Instant Payments" debit card to the merchant account as this attacker did).
Unfortunately, I've asked WooCommerce to support Restricted API Keys 1 year ago, but they marked it as "low priority"