By PayID seems poised to solve a problem plaguing the cryptocurrency community since the very first Bitcoin was mined by Satoshi Nakamoto – the requirement to input the long and cumbersome sequence of numbers found with most cryptocurrency account addresses. These addresses resemble the strange sequence of numbers found in ipv6 addresses in length and complexity, which no reasonable computer scientist would ever expect an average user to memorize or input accurately.
One of the basic questions at the heart of a system like PayID would be: how do you design a payment protocol that leverages multiple different blockchains while preserving user privacy and security to a reasonable extent? If the solution is too restrictive and private, it stifles commerce options, and if the protocol is too open, it can put users at risk.
The assumption when a user sends a payment to a merchant storefront with crypto, or even with a credit card, is that there will be an exchange of personal information. With crypto, that is typically only an account address which does not explicitly have personally identifiable information attached to it. However, if the user expects the shipment of a product or service, they would be interacting with a merchant storefront as a person and would require shipping information, email, or other personally identifiable data depending on what type of product is being purchased.
Transmission and storage of this kind of information has risks, even with reputable entities. In traditional online-based merchant storefronts like Amazon, that information can be leaked or stolen by malicious actors or entities. An example of this can be found with the breach of the Newegg storefront, where malware authors were able to compromise Newegg’s payment servers and capture customer credit card information as they attempted to order from their storefront.
The risks with a cryptocurrency transaction using a system like PayID are different but of a similar nature. If a merchant’s self-hosted PayID server is compromised or customer database hacked, the attacker would not be able to send payments or extract funds from either the customer or the merchant unless they also managed to capture their private keys, but they may be able to correlate a cryptocurrency address to a user’s personally identifiable info. A merchant storefront shouldn’t be invoicing and storing a client’s wallet address with personally identifiable info as the client only needs to know where to make the payment, and the merchant only needs to know that the payment has been made, but once a customer makes a payment, can an attacker that has compromised a PayID server now find that corresponding transaction in the merchant’s crypto transaction history? It would seem that the attacker would be able to do this, and with an online storefront like a hypothetical flower merchant, they’d be able to figure out the customer’s address through their shipping information and tie that physical address to a cryptocurrency address. This isn’t a unique risk to PayID. Anytime a user makes a purchase from a storefront using a cryptocurrency transaction on a public ledger, they expose the wallet address and the amount of crypto stored there to a merchant or receiver.
If a merchant like Newegg (the very same mentioned above that had their storefront infected with credit card stealing malware) is using a PayID service hosted by an exchange or bank, even if their storefront gets hacked the PayID service should operate independently and the merchant’s payment pull request would arrive on a consumers device without the transaction addresses being recorded. Nevertheless, depending on the severity of the breach, the attacker may be able to determine user information regardless. The whitepaper indicates that an attacker cannot remap payment addresses associated with a PayID without also having access to the private keys, but if an attacker compromises the Newegg servers, as they have done previously, I don’t see why they wouldn’t be able to serve up a different PayID window that points to their own server. I’m assuming that the merchant PayID transaction would make use of some of the identity verification features mentioned in the PayID whitepaper to give the consumer some indication of who they’re paying when the payment pull request arrives, which mitigates these risks somewhat, assuming the user notices that the payment request is not coming from Newegg. Of course, none of this is an explicit flaw with PayID. If the merchant cannot secure their own servers, there’s nothing that would protect a consumer from theft or fraud. With PayID’s identity verification system, there should be some indication that the payment is not going to Newegg, which is more of an indication than consumers who transacted with Newegg’s infected servers had previously received.
If a user has a high crypto net worth, a major breach would put them at risk once attackers attach a name and a home address to a high net worth crypto address. With a traditional card information capture, an attacker usually can’t see your full account balance with just a bank or credit card number. There’s less risk of stolen funds with crypto, but more risk of a certain kind of privacy-related breaches. Hypothetically, if we combine a customer database leak (including personally identifiable info like a shipping address, purchase receipt, etc.) with a passive mapping of a merchant’s associated crypto addresses revealed through PayID requests, it may be possible to associate customer crypto addresses with user identities if the attacker manages to correlate these purchases with cryptocurrency transfers sent to a known merchant account that matches with a receipt leaked in a database breach.
The PayID whitepaper recommends a few strategies to mitigate these risks.
With address rotation, each request from one PayID wallet to another would return a different cryptocurrency address. If a merchant used a single Bitcoin address for all of their transactions, their whole BTC storefront history would be trivially available, and if any corresponding invoicing and customer information was stored in plain text and breached, transactions could be tied to crypto addresses and personally identifiable information by scanning a merchant’s known crypto addresses for a currency amount and date. The PayID protocol also has a system by which it can restrict requests of information to whitelisted users, and I suspect there might be a system in place to ensure that a merchant can limit these PayID requests to registered users of their storefronts if they wish.
The Ledger Nano already rotates Bitcoin addresses when the app generates a receive address, but for non-custodial wallets used with cryptocurrencies like XRP, it’s not clear to me how address rotation would be done in a cost-effective manner, as the initial XRP setup fee would make having multiple addresses cost-prohibitive. I’m also not certain how big of an issue this would be for users of exchanges whose XRP are typically obfuscated by the sheer volume of transactions on exchange wallets. As far as I know, there is no elegant way to view the balance associated with a destination tag.
The best solution for a database leak or other similar scenarios might be not to make trivial transactions using a wallet address that holds the majority of your crypto net worth. For XRP, when using PayID, it seems that one can achieve greater security from XRP address to user identity risks using exchanges rather than non-custodial wallets.
Obviously, PayID data is not being transmitted in plain text across the internet:
If the TLS connection fails, the server drops the transaction. This encryption would make passive attempts to listen and gather data improbable. The PayID Whitepaper also indicates that the PayID protocol uses port 443 for traffic and can blend PayID transactions and requests with your traditional encrypted web traffic (which also takes place on Port 443). Because of this, it would be more difficult to tell normal web traffic and PayID traffic apart.
Overall, PayID seems to be a reasonable mixture of security, privacy, and ease of use. There are always risks when using a public blockchain, but with the proper steps, merchants and consumers can protect themselves from major privacy breaches. Of course, the more this is automated for the consumer, the better. This automation is what makes PayID such an elegant solution for users of a wide variety of cryptocurrencies. PayID stands as an easy to use and reasonably secure payment methodology.
