GoFuckYourself.com - Adult Webmaster Forum - View Single Post - The Epass/Paypal Alternative I have been hinting at for years has arrived.

djscrib · 10-09-2007, 12:35 AM

In regards to the XMLAPI.

SSL pretty much nullifies man in the middle attacks so that's not the "hole" in the xml api format. The hole is that the code on your server, needs to contain your username/password. The more likely scenario is that a hacker cracks into your code and grabs the file with that info. They now can log into your account and send themselves money for example. An access key that is only usable for the XMLAPI is much less sensitive if it does indeed get compromised. I just see this as an issue with a lot of adult webmasters not being security gods.

The two other advantages, is companies that contract out their development again don't have to give their account number to consultants. (You'd give a consultant your ePass id, but not your PayPal username and password to set up your site).

And the advantage that I'm interested in personally, it allows software providers of shopping cart solutions or other services to perform billing on behalf of verified charge customers safely.

For example say I have a downloadable video service where I handle everything for 3rd parties. You simply have to give me your VerifiedCharge info, and purchases are automatically credited to your bank account. This same scenario holds true for shopping carts and the link. If the info required is a token, then you're probably fairly willing to grant me access to that. (This is what Paypal does for shopping cart integration). If the info is your username/password that grant full access to your account, it seems like a large safety risk.

Anyhow, just a thought which I think would add some business options and beef up your security.

To implement simply add a field called "xml-token" to the database for each merchant. When the merchant account is created auto-generate a GUID and insert it. Display this GUID to the user and give them the option to re-generate it.

When an XML API request hits your server, have them pass the username/xml-token instead of username/password. Your code instead of doing a username/password lookup in the db, you lookup username/token.

Oh one last thing.

In your API I can simply pass username/password pairs to your service until the XML returned says OK. Thus if I know your username, I can make guesses at your password via an automated password guesser program until I find it. Once I have that, I can go to town on your account. Some studies have shown that average passwords can be cracked with dictionary attacks in a matter of minutes. GUID's on the other hand are effectively impossible to guess.

Anyhow I just had my access to the XML API approved so I'm gonna go test drive it.

Service looks great so far!

10-09-2007, 12:35 AM
djscrib Confirmed User Join Date: Mar 2004 Posts: 147	In regards to the XMLAPI. SSL pretty much nullifies man in the middle attacks so that's not the "hole" in the xml api format. The hole is that the code on your server, needs to contain your username/password. The more likely scenario is that a hacker cracks into your code and grabs the file with that info. They now can log into your account and send themselves money for example. An access key that is only usable for the XMLAPI is much less sensitive if it does indeed get compromised. I just see this as an issue with a lot of adult webmasters not being security gods. The two other advantages, is companies that contract out their development again don't have to give their account number to consultants. (You'd give a consultant your ePass id, but not your PayPal username and password to set up your site). And the advantage that I'm interested in personally, it allows software providers of shopping cart solutions or other services to perform billing on behalf of verified charge customers safely. For example say I have a downloadable video service where I handle everything for 3rd parties. You simply have to give me your VerifiedCharge info, and purchases are automatically credited to your bank account. This same scenario holds true for shopping carts and the link. If the info required is a token, then you're probably fairly willing to grant me access to that. (This is what Paypal does for shopping cart integration). If the info is your username/password that grant full access to your account, it seems like a large safety risk. Anyhow, just a thought which I think would add some business options and beef up your security. To implement simply add a field called "xml-token" to the database for each merchant. When the merchant account is created auto-generate a GUID and insert it. Display this GUID to the user and give them the option to re-generate it. When an XML API request hits your server, have them pass the username/xml-token instead of username/password. Your code instead of doing a username/password lookup in the db, you lookup username/token. Oh one last thing. In your API I can simply pass username/password pairs to your service until the XML returned says OK. Thus if I know your username, I can make guesses at your password via an automated password guesser program until I find it. Once I have that, I can go to town on your account. Some studies have shown that average passwords can be cracked with dictionary attacks in a matter of minutes. GUID's on the other hand are effectively impossible to guess. Anyhow I just had my access to the XML API approved so I'm gonna go test drive it. Service looks great so far! __________________ Vidlock DRM Service - Add DRM to your website today http://www.vidlock.com Coming Soon - Vidpass