I make and sell BusKill laptop kill cords. Monero is accepted.

https://michaelaltfield.net/

  • 28 Posts
  • 19 Comments
Joined 2 years ago
Cake day: June 12th, 2023
  • maltfield@monero.townOPtoCybersecurity@sh.itjust.works•Why OAuth MUST share access token with 3rd party?!?English
    3·
    3 months ago

    https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html

    I haven’t seen it. Thanks for sharing!

    afaik, it doesn’t cover this use-case (where the Resource Server [Stripe] just uses the wrong flow – forcing us to expose our access keys to a third party).

    But, curious, it lists 0 attacks for the OAuth Flow that Stripe should be using here = Client Credentials Flow.

    Edit: ahhhhh, this paragraph is elucidating

    The Authorization Code Flow is one of the most widely used OAuth flows in web applications. Unlike the Implicit Flow, which requests the Access Token directly to the Authorization Server, the Authorization Code Flow introduces an intermediary step. In this process, the User Agent first retrieves an Authorization Code, which the application then exchanges, along with the Client Credentials, for an Access Token. This additional step ensures that only the Client Application has access to the Access Token, preventing the User Agent from ever seeing it.

    I confirmed that Stripe is using the Authorization Code Flow

    curl https://connect.stripe.com/oauth/token \
-u sk_test_MgvkTWK1jRG3olSRx9B7Mmxo: \
-d “code”=”ac_123456789” \
-d “grant_type”=”authorization_code”

    …but it does appear to be using the wrong OAuth Flow type. They give the token to us in the end. There’s no need to expose it to a third party.

    So I guess “choosing the wrong flow type” would be a valid addition to the “attacks” section under Authorization Code Flow

  • maltfield@monero.townOPtoCybersecurity@sh.itjust.works•Why OAuth MUST share access token with 3rd party?!?English
    3·
    3 months ago

    Thanks. It’s a good guess, but that’s not the case.

    The developers confirmed that the only place the OAuth access tokens are stored is on my server. Of course, the dev’s server (which sees the [non-expiring!] access keys for >800,000 Stripe Accounts!) would be a ripe target for someone malicious. But it’s not designed to store the keys there. All subsequent connections to the Stripe API are done directly between my server and Stripe’s server (with no intermediary “platform”). The token is only exposed to the dev server when OAuth flow is first established. Then the dev server (effectively a MITM, by design) sends it down to my server for storing and future use.

    PCI compliance on my server isn’t an issue because all sensitive payment information is tokenized.

    The reason this is done is because Stripe doesn’t allow the redirect during the OAuth flow to be dynamic. It must be a predefined value that’s hard-coded into the app.

    For security purposes, Stripe redirects a user only to a predefined URI.

    That’s why Stripe forces you to expose your access tokens to the developer’s servers.

    I’d still appreciate if someone with more experience with OAuth than me knows if this is common. Seems like a very bad design decision to require users to transmit their bearer tokens through the developer’s servers.

    Update: It looks like you’re describing their “Platform” option. In 2025, there’s 3 “authentication types” for Stripe Apps, as documented here

    1. Platform
    2. OAuth 2.0
    3. Restricted API Keys

    In this case, I’m talking about OAuth 2.0 (Stripe Connect), not “Platform”

  • maltfield@monero.townOPtoOpen Source@lemmy.ml•BusKill Warrant Canary #7 Published
    1·
    1 year ago

    You definitely can do that, but if you’re afraid that you might stand-up and forget you’re using it, then you probably shouldn’t.

    It’s probably enough to just use the default trigger that locks your screen. Or, once you get comfortable with it, set it to shut down your computer. Most people don’t need to shred their FDE keys, unless they’re facing torture.

    In fact, we make it difficult to use “destructive” triggers (like the LUKS Header Shredder that wipes the FDE header) and intentionally do not include the ability to switch to it in the app. To use it, you have to do a lot of extra work. So most users don’t have this issue.

  • maltfield@monero.townOPtoOpen Source@lemmy.ml•BusKill (FOSS Dead Man Switch) v0.7.0 released 💾
    61·
    2 years ago

    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 :)