Live data from Hacker News

New startup sells coffee through SSH

terminal.shop

301–310 of 430 posts

Re: New startup sells coffee through SSH

#301

Earlier quoted context omitted.

The full command you want is: ssh -a -i /dev/null terminal.shop to disable agent forwarding, as well as to not share your ssh public key with them, but that's just a little less slick than saying just: ssh terminal.shop to connect.

1. Why is this something that would be enabled by default. 2. Can't you disable agent forwarding in a config file, so as not to have to clutter the command line?

I think it’s disabled by default on all distros I’ve used. You could add an entry to /etc/ssh_config or ~/.ssh/ if you want.

(It’ll still offer public keys by default in the exchange, but that’s “just” a privacy issue, not a privilege escalation problem.)

Re: New startup sells coffee through SSH

#302

A lot of people don't know that before Amazon started, there was a company out of Portland, OR called Bookstacks selling books via a telnet interface. In the early days, Bezos was quite worried about their potential to get "there" first (wherever "there" was going to be). It was a fairly cool interface, at least for 1994. [ EDIT: worried to the point that we actually implemented a telnet version of the store in paral…

> selling books via a telnet interface.

Were people just that trusting back then, or had they figured out some kind of pre-SSL way of securing things?

Re: New startup sells coffee through SSH

#303

Earlier quoted context omitted.

They mention in the faq that they use Stripe - https://www.terminal.shop/faq . Stripe does offer integrations that are not natively using their widgets. Ultimately, the PII data is stored at Stripe. PS: I work at Stripe but I don't really work on the PCI compliant part of the company.

Interestingly Stripe started life as /dev/payments and I seem to remember the first iteration was an agent on your server that literally processed card payments when you wrote the details to /dev/payments

I thought /dev/payments was their second name. Weren't they /dev/creditcard or something like that first?

Re: New startup sells coffee through SSH

#304
post #279

Are the beans any good, what kind of roast?

"Dive into the rich taste of Nil, our delicious semi-sweet coffee with notes of chocolate, peanut butter, and a hint of fig" and "medium roast"

Oh, is that in the email or something?

I searched Nil blend coffee but only got results about sports teams.

I wonder if it is white-label or something.

Re: New startup sells coffee through SSH

#306
post #301

Earlier quoted context omitted.

1. Why is this something that would be enabled by default. 2. Can't you disable agent forwarding in a config file, so as not to have to clutter the command line?

I think it’s disabled by default on all distros I’ve used. You could add an entry to /etc/ssh_config or ~/.ssh/ if you want. (It’ll still offer public keys by default in the exchange, but that’s “just” a privacy issue, not a privilege escalation problem.)

[deleted]

Re: New startup sells coffee through SSH

#307
post #251

Earlier quoted context omitted.

Check for yourself with ssh -v -i /dev/null terminal.shop vs ssh -v terminal.shop What you're looking for is that there is no line that says something like debug1: Offering public key: /Users/fragmede/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Upon further testing, the full command you want is: ssh -a -i /dev/null -o IdentityAgent=/dev/null terminal.shop to forcibly disable a local identity ag…

For a cool example (deanonymization), see https://words.filippo.io/dispatches/whoami-updated/ (discussed at time: https://news.ycombinator.com/item?id=34301768 ). Someone has crawled public keys from GitHub (tbh I was surprised that GitHub publishes them) and set up a database.

> You can make a search for all users, which will tell you there are 97,616,627 users at the time of this writing, but you can only fetch at most 1000 results from a search, and they don’t come in any clear order, so you can’t just make the next search start where the previous one left off (or I didn’t figure out how).

> What you can do though is request accounts created in a certain time range. If you get the time range right, so that it has less than 1000 entries, you can paginate through it, and then request the next time range.

This reminds me of when I tried to add a google drive storage backend to camlistore/perkeep (because I had nearly-unlimited free quota at the time). One of the things a perkeep blobserver needs to be able to do enumerate all the blobs it has, in order. You can send millions of blobs to google drive without issue, but you can't directly paginate a search for them in sorted order.

You could just issue a search for all blobs under your perkeep drive folder, keep paginating the result until you run out of pages, and then sort in memory, but there's really no way of knowing how many blobs you're going to end up with and you might blow out your blobserver's memory.

Perkeep blobs are identified by blobrefs, SHA sums of the contents of the blob, so they look like sha-[0-9a-f]{64}. Google drive lets you search for files with a name prefix, so you can search for like /perkeep/sha-* and see if the result has a pagination token (indicating that there are more than 1000 results), and if so then you search for each of /perkeep/sha-0*, /perkeep/sha-1*, ... , /perkeep/sha-f*, each time checking to see whether there are too many matches. When there's not too many matches, you've found the prefix length that will let you fetch a bounded number of blobrefs, emit them to the perkeep client, and then release the memory before fetching more.

  /pk/sha-\*          1000+ results (non-empty pagination token)
    /pk/sha-0\*       1000+ results (non-empty pagination token)
      /pk/sha-00\*    1000+ results (non-empty pagination token)
        /pk/sha-000\*  193  results,
                       sort these in memory and emit to client
        /pk/sha-001\*  179  results,
                       sort these in memory and emit to client
        ...
        /pk/sha-fff\*  223  results,
                       sort these in memory and emit to client
I didn't end up landing the patch before I lost interest, partly because it was pretty much the first golang I had tried writing. It was fun working out the above details, though.

Re: New startup sells coffee through SSH

#308

I can't test this due to the product being out of stock, but I wonder what their approach to PCI compliance is. Processing credit card data has a high compliance burden if you're unwilling to use a secure widget made by an already-authorized provider like Stripe. That's for a good reason, most web and mobile apps are designed such that their backend servers never see your full credit card number and CVV. You can't do…

The FAQ says they use Stripe for orders and don't even have their own DB in which to store purchase data, so PCI compliance should be a non-issue

PCI compliance is never a non-issue.

Even if you're using a third party provider that handles both credit card entry and processing, you need to comply with some subset of the PCI/DSS requirements.

In the case of terminal.shop it's not even true, since they can see the credit card number on their side, even if all they do is to forward that number to Stripe and forget about it.

For small and medium-sized merchants, PCI/DSS classifies different types of handling through the concept of which SAQ (Self-Assessment Questionnaire) you have to fill in. Different SAQ have different subset of requirements that you need to fulfill. For e-commerce use cases, there are generally 3 relevant SAQs, in order of strictness:

- SAQ A: Applicable when the merchant redirects payment requests to the payment processor's page or shows an iframe that is hosted by the processor. This is the level required for Stripe Checkout or Stripe Elements.

- SAQ A-EP: Applicable when the merchant handles input on the browser, but sends the data directly to the processor without letting it pass through the merchant's server. This is equivalent to the classic Stripe.js.

- SAQ D: Applicable when the card data is transmitted, stored or processed on the merchant's own server, even if the merchant just receives the card number and passes that on to the payment provider. Stripe calls this type of usage "Direct API Integration" [1].

The level of compliance required for terminal.shop should be SAQ-D for Merchants, which is quite onerous. It covers almost all of the full set of PCI/DSS requirements.

But even if a merchant just uses Stripe.js, the PCI SSC still cares about the possibility of an attacker siphoning card data from the merchant's site through an XSS vulnerability.

And even if the merchant is using an iframe or a redirect (with something like Stripe Checkout or Stripe Elements) there is still the possibility of hard-to-detect phishing, where an attacker could replace the iframe or redirect target with their own site, made to look exactly like Stripe.

---

[1] https://docs.stripe.com/security/guide

Re: New startup sells coffee through SSH

#309

Earlier quoted context omitted.

The full command you want is: ssh -a -i /dev/null terminal.shop to disable agent forwarding, as well as to not share your ssh public key with them, but that's just a little less slick than saying just: ssh terminal.shop to connect.

Honestly the only thing that you need is -a (and only if you made the bad choice to do agent forwarding by default). Sending your pubkey (and a signature, because the server pretends to accept your pubkey for some reason?) isn't a security risk and you're (in theory) going to be providing much more identifying information in the form of your CC... (And as the siblings mentioned this won't work to prevent your key fro…

I agree with you, but there are those that take an extreme stance on privacy and I'm willing to oblige.

Re: New startup sells coffee through SSH

#310

Earlier quoted context omitted.

They mention in the faq that they use Stripe - https://www.terminal.shop/faq . Stripe does offer integrations that are not natively using their widgets. Ultimately, the PII data is stored at Stripe. PS: I work at Stripe but I don't really work on the PCI compliant part of the company.

The fact that the card number data is stored at Stripe doesn't matter that much. As parent commenter says, the card numbers are still visible on terminal.shop's network because it all goes over their SSH connection. For most websites that use the Stripe widget, the website owner can never see the full card number, because the credit card number entry fields are iframed in on the page. That means website owners in thi…

it's been a while since I did the full pci compliance rigamarole, but I don't recall it being that difficult. you basically just answer a bunch of questions correctly about how you are transmitting and storing the data using sufficient encryption and then they run some automated pen tests on your site and then you are done.
Post reply on HN