7 ms·

> They rewrote the site's code, they say, to log every user's password, rather than store them as encrypted hashes. They tweaked a feature designed to automatic

> They rewrote the site's code, they say, to log every user's password, rather than store them as encrypted hashes. They tweaked a feature designed to automatically encrypt messages with users' PGP keys, so that it secretly logged each message's full text before encrypting it, which in many cases allowed them to capture buyers' home addresses as they sent the information to sellers. The site had been set up to automatically removed metadata from photos of products uploaded to the site; they altered that function so that it first recorded a copy of the image with metadata intact. Yeah, you probably should not do your PGP-encryption server-side...

sloppycee 9y ago
Client-side encryption (on the web) isn't any more secure; as they could just modify the JS code to log the plaintext.
- sannee 9y ago
  Having JavaScript enabled when buying drugs over the internet isn't exactly the smartest idea anyway.
- kolpa 9y ago
  > modify the JS code https://news.ycombinator.com/item?id=16554286 https://news.ycombinator.com/item?id=16554286
- lucb1e 9y ago
  > isn't any more secure It's definitely more secure. But depending on your level of paranoia, yeah, it's often not enough. Doing things in the browser shows customers that it's done properly and verifiably. It also makes attack way more public than being able to do it quietly server-side. I wish people applied security client-side more often. I mean, if the server is compromised, you're fucked, regardless of whether you applied your crypto in js or on the server. But if it is done client-side, at least there's a chance that you notice you're fucked.
  - rndgermandude 9y ago
    >Doing things in the browser shows customers that it's done properly and verifiably. So customers are skilled enough to check the (webpacked together with other stuff and minified) JS code running in their browser before they run it? Even if this was actually feasible, it would be still orders of magnitude easier to just do GPG in a terminal. And don't forget that, according to the article, we're talking about a crowd where even a lot of the long-standing big sellers are not smart enough to remove GPS meta-data from their product pictures. >It also makes attack way more public. You can still serve different (malicious) JS to a select bunch of your users who are least likely to notice and kinda spearfish with that. E.g. it's entirely feasible to just bug new first customers you fingerprinted as using default Tor Browser installs (most likelihood they are tech newbies too). Even if users make sure the code they run is verified, how do users make sure the public key they are encrypting with is the public key of the party they intent and not a key the (rogue/police) operators of the website put there themselves, doing a good old active MITM key switcheroo? It's not like there is an independent web of trust in the realm of a tor drug market that you can check for that information. Even if the public keys of the big players (most of which would be sellers) are widely known, the key of Joe Newcustomer is not, so you can at least eavesdrop on communication directed to him by replacing his key with your own, look what the seller is writing and also at all those "Joe Newcustomer wrote: >" lines too, and nobody will ever notice until the police knocks on their doors.
    - lev99 9y ago
      > So customers are skilled enough to check the (webpacked together with other stuff and minified) JS code running in their browser before they run it? Checking code before it runs is possible. What is much easier is watching the network traffic on the web browser and examining it for sensitive material. It's an order of magnitude better to know that a security breach has _just_ happened than to find out much later, possibly when that information is being leveraged against you. > spearfish Almost all significant criminal activity leaves some trace. The buyer, by nature, has more trust in the seller because the buyer must pick up a package a specific location in a date range. The seller would be the most significant market players (spearfish targets), but give up less information in each transaction. The best way to attack would be watching for user mistakes (gps meta-data), social engineering, and zero days.
wlesieutre 9y ago
You shouldn't do it in a web browser at all, client or server side. They can start off doing it client side and then silently switch to doing it server side. I've admittedly never used PGP, but I would think if a website at any point has access to your private key and could transmit it back to their server, you're doing it wrong. I suppose it's a question of your threat model. Do you trust the website to not do that? Given that FBI is willing to take over and continue operating websites that distribute child porn, the default answer to that question ought to be no. You have no way of knowing if someone else has taken a server over. Maybe a browser extension would be a good way to do PGP encryption for websites, keeping the key out of their reach but allowing a one-click encryption right in the browser.
- vilhelm_s 9y ago
  Indeed, it's common advice that users of Darknet markets should not have Javascript turned on at all, since it increases their attack surface. (e.g. https://darknetmarkets.org/agora-comments-on-recent-bitcoin-stealing-private-message-javascript-attack/ https://darknetmarkets.org/agora-comments-on-recent-bitcoin-...)
  - stingraycharles 9y ago
    Isnt that the default of the Tor browser as well ?
    - 4ad 9y ago
      No, it isn't, which is insane.
      - dmix 9y ago
        Yes it is. It wasn't for the first couple years but they turned it on a few yrs back. Last time I used Tor browser JS was disabled by default... I'd be surprised if that wasn't the case.
        9y ago
Buge 9y ago
That quote doesn't say there is any server-side PGP. It could have been happening in javascript in the browser.
DINKDINK 9y ago
>you probably should not do your PGP-encryption server-side PGP-encryption server-side is meaningless, even if it was done client side, there's a MITM. Eve can replace public keys (though at the risk of exposing her MITM if people are double checking their own public keys listed on the site against their client side public keys) >They tweaked a feature designed to automatically encrypt messages with users' PGP keys, so that it secretly logged each message's full text before encrypting it Unless this is Wired's way of saying a MITM as described above.
- Buge 9y ago
  >PGP-encryption server-side is meaningless It's not meaningless, it prevents past messages from being compromised by a future breach. Future messages are still compromised, but past messages are secure. By your logic you could say that forward secrecy is meaningless. But yet security professionals recommend that you use a TLS key exchange with forward secrecy.
  - DINKDINK 9y ago
    I said: If there’s a MITM, server side PGP is meaningless. I didn’t say that server-side PGP has no security value in all domains.
anovikov 9y ago
If users still went to the webpage, and used whatever that webpage offered them, what could help them? Client or server side, they were pwned.
- gcb0 9y ago
  unless they knew beforehand to not enter plain text messages there. ever.
deleted 9y ago
[deleted]

sloppycee 9y ago

Client-side encryption (on the web) isn't any more secure; as they could just modify the JS code to log the plaintext.

sannee 9y ago
Having JavaScript enabled when buying drugs over the internet isn't exactly the smartest idea anyway.
kolpa 9y ago
> modify the JS code https://news.ycombinator.com/item?id=16554286 https://news.ycombinator.com/item?id=16554286
lucb1e 9y ago
> isn't any more secure It's definitely more secure. But depending on your level of paranoia, yeah, it's often not enough. Doing things in the browser shows customers that it's done properly and verifiably. It also makes attack way more public than being able to do it quietly server-side. I wish people applied security client-side more often. I mean, if the server is compromised, you're fucked, regardless of whether you applied your crypto in js or on the server. But if it is done client-side, at least there's a chance that you notice you're fucked.
- rndgermandude 9y ago
  >Doing things in the browser shows customers that it's done properly and verifiably. So customers are skilled enough to check the (webpacked together with other stuff and minified) JS code running in their browser before they run it? Even if this was actually feasible, it would be still orders of magnitude easier to just do GPG in a terminal. And don't forget that, according to the article, we're talking about a crowd where even a lot of the long-standing big sellers are not smart enough to remove GPS meta-data from their product pictures. >It also makes attack way more public. You can still serve different (malicious) JS to a select bunch of your users who are least likely to notice and kinda spearfish with that. E.g. it's entirely feasible to just bug new first customers you fingerprinted as using default Tor Browser installs (most likelihood they are tech newbies too). Even if users make sure the code they run is verified, how do users make sure the public key they are encrypting with is the public key of the party they intent and not a key the (rogue/police) operators of the website put there themselves, doing a good old active MITM key switcheroo? It's not like there is an independent web of trust in the realm of a tor drug market that you can check for that information. Even if the public keys of the big players (most of which would be sellers) are widely known, the key of Joe Newcustomer is not, so you can at least eavesdrop on communication directed to him by replacing his key with your own, look what the seller is writing and also at all those "Joe Newcustomer wrote: >" lines too, and nobody will ever notice until the police knocks on their doors.
  - lev99 9y ago
    > So customers are skilled enough to check the (webpacked together with other stuff and minified) JS code running in their browser before they run it? Checking code before it runs is possible. What is much easier is watching the network traffic on the web browser and examining it for sensitive material. It's an order of magnitude better to know that a security breach has _just_ happened than to find out much later, possibly when that information is being leveraged against you. > spearfish Almost all significant criminal activity leaves some trace. The buyer, by nature, has more trust in the seller because the buyer must pick up a package a specific location in a date range. The seller would be the most significant market players (spearfish targets), but give up less information in each transaction. The best way to attack would be watching for user mistakes (gps meta-data), social engineering, and zero days.

wlesieutre 9y ago

You shouldn't do it in a web browser at all, client or server side. They can start off doing it client side and then silently switch to doing it server side. I've admittedly never used PGP, but I would think if a website at any point has access to your private key and could transmit it back to their server, you're doing it wrong. I suppose it's a question of your threat model. Do you trust the website to not do that? Given that FBI is willing to take over and continue operating websites that distribute child porn, the default answer to that question ought to be no. You have no way of knowing if someone else has taken a server over. Maybe a browser extension would be a good way to do PGP encryption for websites, keeping the key out of their reach but allowing a one-click encryption right in the browser.

vilhelm_s 9y ago
Indeed, it's common advice that users of Darknet markets should not have Javascript turned on at all, since it increases their attack surface. (e.g. https://darknetmarkets.org/agora-comments-on-recent-bitcoin-stealing-private-message-javascript-attack/ https://darknetmarkets.org/agora-comments-on-recent-bitcoin-...)
- stingraycharles 9y ago
  Isnt that the default of the Tor browser as well ?
  - 4ad 9y ago
    No, it isn't, which is insane.
    - dmix 9y ago
      Yes it is. It wasn't for the first couple years but they turned it on a few yrs back. Last time I used Tor browser JS was disabled by default... I'd be surprised if that wasn't the case.
      - 9y ago

Buge 9y ago

That quote doesn't say there is any server-side PGP. It could have been happening in javascript in the browser.

DINKDINK 9y ago

>you probably should not do your PGP-encryption server-side PGP-encryption server-side is meaningless, even if it was done client side, there's a MITM. Eve can replace public keys (though at the risk of exposing her MITM if people are double checking their own public keys listed on the site against their client side public keys) >They tweaked a feature designed to automatically encrypt messages with users' PGP keys, so that it secretly logged each message's full text before encrypting it Unless this is Wired's way of saying a MITM as described above.

Buge 9y ago
>PGP-encryption server-side is meaningless It's not meaningless, it prevents past messages from being compromised by a future breach. Future messages are still compromised, but past messages are secure. By your logic you could say that forward secrecy is meaningless. But yet security professionals recommend that you use a TLS key exchange with forward secrecy.
- DINKDINK 9y ago
  I said: If there’s a MITM, server side PGP is meaningless. I didn’t say that server-side PGP has no security value in all domains.

anovikov 9y ago

If users still went to the webpage, and used whatever that webpage offered them, what could help them? Client or server side, they were pwned.

gcb0 9y ago
unless they knew beforehand to not enter plain text messages there. ever.

deleted 9y ago

[deleted]