How secure are Indian payment gateways?

India has a dearth of good payment gateways – most have obsolete difficult-to-use APIs requiring days, if not weeks, to integrate. They require at least a dozen documents (most of them need them sent through post) before they even let you inside their walled garden. Additionally, gateways have complicated plans – depending on your initial spending budget you can get a deal for 3% or otherwise end up paying 5%. Of course, you can also haggle. Above that most of them have a monthly/yearly maintenance fee. It’s a sad state of affairs – and part of the reason is because of the government policies making it very difficult to accept payments easily.

I was very excited when Flipkart’s Payzippy launched recently. (NB: I wrote this post a while ago, but I waited while I contacted the gateways about the security issues before publishing). As I was skimming through their API document, I discovered they were using MD5 which is not considered cryptographically secure anymore. I looked deeper and found a few other security measures which, as a payment gateway, they should have taken. When I looked at other payment gateways, they had similar problems (some even much worse) and so I compiled a list of Indian payment gateways I could find and research about.

First, some layman technical info.

How payment gateways work

Indian payment gateways are asynchronous; the user is first redirected to the gateway where he/she enters his/her card details, and then redirected to the mandatory 3-D Secure/Securecode password verification. These redirects happen through the user’s browser. To verify that a transaction received by the gateway is associated with the right user and originated from the merchant – the merchant attaches a message authentication code (MAC) of the transaction which is transmitted to the gateway along with the transaction details. The MAC generation algorithm is gateway specific. Gateway at its own end will recompute and verify the MAC to make sure data hasn’t been tampered with and then proceeds with assessing the rest of the transaction. After it verifies the transaction it redirects back to the merchant with the status of the transaction and the MAC of the status so the merchant can verify the request originated from the gateway. These “handshakes” should be tamper proof, or bad things can happen.

Not following along? Here’s a drawing to help you understand:

Message Authentication Code Flow

Message Authentication Code

The sender (merchant) has a secret key (shared with the gateway) and uses a predetermined MAC algorithm to generate a MAC string which is included in a hidden form field while redirecting him/her to the receiver (gateway).

A bit about hashes

Why are MACs needed? They are used to ensure data integrity during redirects. MACs need to be tamper proof – otherwise a user could change the transaction amount in transit from merchant to gateway, or modify a failed transaction to look like a successful one. A naïve approach to implementing simple MACs is to use a common hashing algorithm (like SHA1 or MD5) with a shared secret key which is then appended to the data transmitted.

# Method 1: Key as a suffix
mac = hash(message + key)

# Method 2: Key as a prefix
mac = hash(key + message)

Both these approaches have flaws:

  1. When using key as a suffix with a collision prone hash algorithm like MD5 an attacker may modify the message in such a way that the MAC doesn’t change.
  2. When using key as a prefix (in addition to the previous vulnerability) an attacker could use length extension attack to add more information to the message.

MACs like these depend on the collision resistance of the underlying hashing algorithm for security. One right way to preserve and validate integrity is to use HMAC which uses a nested hash calculation to make the hashes tamper proof. HMACs are meant for verifying integrity; using a hash function isn’t.

Security best practices

I chose a few selected security practices which can result in possibly serious vulnerabilities. Of course, this is not an exhaustive list.

Merchant login page shouldn’t be on HTTP

Serving login pages over HTTP is insecure; it’d be trivial to redirect user to a fake login page, or modify the page in transit and give user a modified form to submit data to.

Use HSTS

Using the HTTP Strict Transport Security (HSTS) header a site can tell the browser to always use HTTPS for that domain in the future. None of the gateways I researched were using HSTS. Most of them are using 301 redirects which are stored in the browser cache. But 301 redirects are URL specific, while HSTS is domain specific. i.e. 301 redirects a single page, HSTS redirects a complete domain. With HSTS (after the first visit by a user) the browser will never contact the site using HTTP again on any of the site pages. If a site isn’t using HSTS, the user cookies can be stolen by directing the user to visit a non HTTPS page while logged in or by redirecting them to a modified login page.

Secure cookies

Cookies should be marked Secure, which tells the browser to transmit the cookie only when the request is HTTPS. So, even if a user opens an HTTP page (which shouldn’t exist), their cookie is never transmitted in clear text to the server. If the secure parameter doesn’t exist, an attacker could eavesdrop on a user’s session when an HTTP page is opened. Having access to the merchant’s cookie, the attacker could steal user data, reset keys or even worse.

Hash based authentication

I explained MACs earlier in the post. While the above-mentioned security practices involve a malicious third party, this one just involves a malicious user. If a gateway is using a weak MAC generation algorithm, a user could spoof a request with a “transaction succeeded” message which will tell the merchant that the user has paid.

Not relying on “security through obscurity”

Security through obscurity may work in some cases, but it does not work in case of payment gateways at all. Firstly, this information (handshake algorithm, for example) is available through other means (eg: through e-commerce software code) and secondly, merchants, both existing and past, using the gateway have that information already.

Payment gateways tested

I included the following payment gateways in my research. Gateways are rated on a scale of 1 to 10. If any payment gateway is missing, leave the name and links in comments and I’ll update the post with my observations. Click on a gateway to directly jump to its review.

EBS
Payu
CCAvenue
Zaakpay
Direcpay
Transecute
Payzippy

Citruspay (Added on 2013/10/02)
Juspay (Added on 2013/10/22)

I tried to contact the gateways about the critical issues over three weeks before publishing this post. I sent a generic email because none of them had specialized email for reporting security issues. However, none of them replied to my later emails regarding their plans on fixing these issues. Clearly, the one who didn’t reply at all don’t care about user security at all, but the others didn’t fare well either.

Observations

The following observations are based on what information I could find – I do not have an account to login and play around with any of them (test accounts are only available to customers). Even their documentation is a closely guarded secret. Thanks to search engines, I found API documentation or integration code for most of them, which I used to figure out how the communication between merchant and gateways was going on.

EBS

The home page of EBS loads unencrypted over HTTP. Their login page is hosted on secure.ebs.in, but it’s also available on HTTP. Cookies are marked secure. HSTS is not implemented.

EBS uses MD5 with hash(key | message), and calls it “secure hash method”, which is really not secure at all. A length extension attack is not effective here though, because the messages have a fixed data structure with separators.

Hash = MD5(secretKey|account_id|amount|reference_no|return_url|mode)

This hash is embedded in HTML form. While redirecting back to the merchant, EBS uses the same key to encrypt data with RC4.

Let’s talk about RC4 first – RC4 is a stream cipher. Stream ciphers create a pseudorandom stream, called keystring, based on the key. This keystring is bitwise XORed with the plain text to generate the ciphertext (and if XORed with the ciphertext gives back the plaintext because of the way XOR works). Stream ciphers have one very important requirement – the same key should never be used twice to encrypt messages.

RC4 is also susceptible to bit flipping attacks. For example, EBS redirects back to merchant with a string containing “0” or “1” depending on whether a transaction succeeded. Even if a transaction fails at EBS’s end the user can just flip a bit to change 0 to 1 and the merchant will receive the transaction as valid. If you had to take away one thing from this post, remember this – “Encryption is not authentication“.

EBS’s implementation of RC4 is also broken. RC4 has weak encryption for the initial part of keystream. It’s recommended that the first few thousand characters be discarded to prevent leaking the key. But EBS encrypts the message without discarding any part of the keystream.

Lastly, this whole message encryption is an optional feature which is disabled by default.

To sum up, possible vulnerabilities in EBS:

  • Secret key can be cracked easily, or a transaction state can be modified
  • Spoofing gateway responses and requests
  • Redirect user to a fake login page.

Source: Integration manual (the manual is in the zip), “Secure hash validation manual

Gateway response: Only initial response, no follow up from their end.

Grade: 1/10

Payu

Payu redirects user to the secure site after which all connections and links are encrypted. Login page is not available over HTTP. Payu doesn’t use 301 redirects. Every time a user opens payu.in, HTTP page is loaded first. No HSTS implemented. Cookies are marked secure.

PayU uses trivial MACs – SHA512 (key | message | salt) which has no known collisions. Although it’s quite likely in the future. Their hash exchange protocol is also resistant to length extension attack – during communication the hashes are computed for the message in normal and reverse order.

Possible vulnerabilities:

  • Redirect user to a tampered login page.
  • MAC is secure for now but needs to be future-proofed

Note: After I published this post, a PayU engineer replied and said that verifying a transaction is a necessary requirement for merchants who provide services before receiving funds.

Grade: 8/10

Source: Integration document

CCAvenue

Home page opens on HTTP. Login page also links to HTTP which then redirects to SSL page. A fake login page can be presented. Luckily, cookies are marked secure so at least existing sessions are safe from sniffing. No HSTS is implemented.

CCAvenue uses Adler checksum – before writing this I had never even heard of it. Adler is an ancient checksum based on the sum of ASCII values in a string. The callback from gateway to merchant uses Adler again making a request easily tamperable. The return request has a character Y or N pointing to if the transaction succeeded among other details. Changing N to Y is simple – use the difference of (Y – N) and modify the checksum.

After I contacted CCAvenue, they told me that they do not use Adler32 anymore and instead use encryption. I couldn’t find any information about their new protocol, but “encryption is not authentication”.

Possible vulnerabilities:

  • Spoofing gateway responses and requests
  • Redirect user to fake login page

CCAvenue already has a poor track record in security – they were broken into in 2011 with an SQL injection.

Grade: 1/10

Gateway response: Migrated away from Adler32

Source: Integration document, Sample implementation

Zaakpay

Zaakpay redirects to secure page with a 301 redirect, but no HSTS here either. Cookies are marked secure. Zaakpay is the only gateway I researched which uses HMAC for verification. And is the only gateway to not have a “secret integration document” available only to customers.

Possible vulnerabilities:

  • Redirect merchant to a spoof site on first load

Grade: 9/10

Source: API documentation (with sample codes)

Direcpay

Login form exists on the home page which is served on HTTP which then submits to a HTTPS . Cookies are not marked secure. No HSTS.

And you thought CCAvenue using Adler was bad? For encryption/decryption – ahem – DirecPay uses doubly encoded Base64. As if doing it twice makes it any more secure. Let me quote from their verbiage (in their documentation):

Transaction parameters will be accepted from the merchant website in an encoded format to ensure that no data is tampered and transaction is processed in a secured fashion.
The script for encryption / decryption logic of transaction parameters can be downloaded from the link:
http://www.timesofmoney.com/direcpay/downloads/dpEncodeRequest.zip

I wouldn’t put it past them to be unable to stop basic SQL injections.

Well, I’ll assume there’s no authentication.

(Note added on 2013-10-11: Direcpay’s response on using Base64 is that they have been migrating their customers to an API with encrypted communication since December 2012, however not all the merchants have moved yet. Newer merchants will use the new API. Nevertheless, my view on this is that using encryption may be better than Base64, but it’s still not the most secure way of doing things.)

Possible vulnerabilities:

  • Redirect users to a spoofed login page
  • Sniff already logged in user cookies.
  • Free for all – spoof gateway responses and requests

Incidentally, Google India uses DirecPay for AdWords but they get to use a special API which uses PGP for communication. Indiatimes Shopping (DirecPay is owned by Times group) also gets a special API which uses something completely different.

Grade: 0/10 (Remember this is on a scale of 1 to 10)

Gateway response: None

Source: Integration document

Transecute

Transecute login loads over HTTPS directly on a different domain (secure.transecute.com). HTTP is inaccessible (404) on that domain. No HSTS is implemented. At least cookies are marked secure.

I couldn’t find Transecute’s integration document. I found an Opencart forum post with their integration code in PHP according to which it uses MD5 with (message|key)

Possible vulnerabilities:

  • Modify text such that MAC hash remains same
  • Redirect users to a fake login page during initial load

Grade: 6.5/10

Gateway response: No follow up after initial response

Source: Integration code (archive link), Opencart forum post with same code

PayZippy

The newest kid on the block. At least it’s well designed. HSTS is not implemented. Home page redirects from HTTP to HTTPS. Cookies are not marked secure so cookies can be sniffed the first time user opens the HTTP page.
Hash is complicated in PayZippy’s case – it’s up to the user to choose either MD5 and SHA1, but it’s still MAC(message | key), which can be tampered with. Their (official?) Magento extension is also using MD5 by default.

Possible vulnerabilities:

  • Modify text such that MAC hash remains same
  • Redirect users to a fake login page during initial load

Grade: 6.5/10

Gateway response: No follow up after initial response

Source: Magento integration, Integration document received in email

Citruspay

Login page is served over HTTP, which submits to HTTPS. Cookies are marked secure. No HSTS.

CitrusPay is the second gateway which uses HMAC for verification.

Possible vulnerabilities:

  • Redirect user to a fake home page

Grade: 7.5/10

Source: Integration document, Sample integration code

JusPay

The homepage of JusPay opens on HTTP, with no redirects. The merchant site is a subdomain (merchant.juspay.in) linked on the home page. It’ll redirect to HTTPS, but there are no 301 redirects. Cookies are tagged secure.

JusPay has 2 solutions for acccepting payments:

  • IFrame checkout –  a JusPay page is displayed in a frame at the merchant’s site and the user can enter their details.
  • Inline checkout – The user enters the credit card details on the merchant’s site itself

Both are different from how other gateways are doing things. The CC details are input on the merchant site directly. In the IFrame, the data goes directly to JusPay, and in Inline the data goes to merchant’s server which then communicates to JusPay (server to server). I hope they have a strict requirement of HTTPS on merchant checkout pages.

JusPay is not using any MAC. That works for inline checkout because their communication happens server to server, i.e. the user can’t tamper with the traffic. On return from JusPay, payment status verification is mandatory, which should provide security for IFrame. But none of their integration handled that verification, it’s up to the merchant write that piece of code. It might be an issue if the merchant just checks the final status of the transaction and doesn’t check the amount and other details, which could have been tampered with.

Possible vulnerabilities:

  • Redirect user to a fake home page.
  • IFrame option might have issues depending on how the merchant handles the payment reconciliation.

Grade: 6.5/10

Source: Demos on their merchant site, integration code

Conclusion

I didn’t grade on some things – XSS, CSRF, iframe embedding, vulnerable software, server misconfiguration – you get the idea. Those are, in many cases, result of bugs. Bad design decisions aren’t bugs though. Overall this post should give a good idea if you are looking for a payment gateway to choose from. It’s great that Zaakpay is doing many things right. Now only if they could redesign their UI.

None of the gateways use HSTS – which I consider a huge security issue in some of them when coupled with other issues. HSTS is not perfect – there’s the first page load which can still be tampered with, but it’s better than 301 redirects and infinitely better than serving all pages on an insecure channel. And it’s not at all complicated to set up.

MD5 is the favourite method among many gateways – Transecute, PayZippy and EBS use it. It’s surprising that developers still believe that MD5 for something this important and sensitive is appropriate.

PCI-DSS is useless. Every gateway has PCI DSS certification when they are clearly not secured at all. PCI-DSS deals with how credit card data is handled – which they might be adhering to. But when it comes to handling transactions PCI-DSS says nothing about that.

What I found disappointing was that the gateways (except Zaakpay and to a lesser extent Payu) do not seem to be taking security seriously and have not been upfront about these flaws to their customers. Security should be a priority, rather than an afterthought. Bad security choices made consciously while designing the system encourage bad security practices throughout the rest of the system. Furthermore, by keeping their security practices unpublished, they have avoided the kind of public scrutiny which could have caught these design flaws long ago.

Epilogue

Before I wrap up, timing attacks are worth a mention – since all gateways are using MACs some way or the other, all of them are vulnerable to timing attacks. None of the integration code I read had special protection against these. A timing attack works on information leaked by lazy comparison between two strings. Consider these two comparisons for example:

# Comparison 1
python -m timeit '"abcd" == "abce"'
10000000 loops, best of 3: 0.0329 usec per loop

# Comparison 2
python -m timeit '"abcd" == "qwer"'
10000000 loops, best of 3: 0.0293 usec per loop

Note the time difference between comparison 1 and 2. Using this time difference it’s not difficult to compute the right hash (without knowing the key at all) one character at a time. It’s not practical in many cases because there’s too much noise – but if a merchant is running a site on a shared host things become quite a bit easier. The search range is very small – there are only 16 hexadecimal characters. If you are a merchant with a gateway using MACs – make sure to use a comparison function which doesn’t do lazy comparison.

Disclaimer: This post is for informative purposes only. I don’t condone the use of any of the vulnerabilities highlighted here for any unlawful use.

  1. I feel the post is harping too much on the ‘theoretical aspect’ of the vulnerabilities. HSTS being a must for Payment gateways is fundamentally flawed . It supposedly makes the browser to remember that site X has to be accessed over https only and never on http, which is the default that browsers apply when someone omits https while typing in the URL bar.

    Payment Gateway Redirections are always triggered by the merchant, and the merchant would never send the user to http but directly to https. Where does HSTS come into play for the user?

    Also, the fact remains that HSTS will really only work when a site makes it into the pre-loaded list of HSTS sites in the browser, otherwise the first connection is inherently insecure.

    • MD5 is known to have been broken in a few seconds using a regular computer. A collision attack exists that can find collisions within seconds on a computer with a 2.6 GHz Pentium 4 processor (complexity of 224.1)

      And you think this is theoretical?

      • Go ahead, break it in a few seconds then :). Then you can blog about it.

        I don’t think theoretical is the same as impossible, just that I would want to see more practical examples, as pointed with the HSTS example.

        • This is an extraordinarily trivial response for a situation that deserves a more measured understanding. Just simply because someone can’t break a proven “weak” cryptographic standard does not in any way make that standard “strong”!

          In that sense, why stop at MD5 and not claim that even the good old substitution and Vigenère ciphers are as great at securing things, just because *you* can’t break them.

          Allow me to introduce you to false equivalency. Oh you’ve met. I’ll let you two catch up then.

      • Maybe I’m wrong but what good does it do to break the merchant key if the merchant properly reconciles his account?

        As long as the key cannot be used to change any merchant account setup parameters, I don’t think it is of any major consequence if proper reconciliation is done by the merchant before delivering product/service.

        • You are right, if the merchant is verifying each and every transaction, having access to the key doesn’t do much good, but it’s still not a good sign. In that case, why not just discard the MAC altogether and just rely on the reconciliation for verifying a transaction? Unless it’s a compulsory requirement, there will always be outliers who might not be following the recommendation.

    • Vulnerabilities do not happen only when the user is making a payment. Communication over an insecure channel could involve eavesdropping on the merchant’s cookies or modifying the HTML. Unless you are using an extension which changes the behaviour, browsers default to http when no protocol is specified. The first connection in HSTS is always insecure, but any subsequent connections will always be encrypted.

      How HSTS helps – eavesdropping on a connection is more likely when a merchant logs into their account from a shared connection often (think sslstrip or Firesheep, which automates this attack vector for anyone to perform). HSTS will also warn you if the DNS of a gateway is hijacked.

    • I’d definitely agree with Qasim here. While HSTS can be implemented for an additional layer of security, it is not a must. Properly implemented 301 redirects have no inherent weakness.

      • The limitation of 301 redirects, compared to HSTS, is they are not permanent and global. To be precise, HSTS is not permanent either, but it can be valid for a long time by setting max-age to a big value. With HSTS, any non HTTPS link a user opens is converted to HTTPS automatically. 301 redirect in itself might not be that bad, but with a non secure cookie it’s easier to sniff them. And, of course, with HSTS you don’t have to worry about any incoming links on other sites linking to the HTTP site if your user has visited the gateway before.

        As I mentioned in the post, HSTS is not perfect, but gateways should try to follow the latest security practices.

  2. Nice article.
    These vulnerabilities are mostly due to the fact that the payment information is flowing through browser. The risk can be highly reduced by having another server to server(mutual auth) communication between merchant site and PG in parallel to browser redirect. That can act as a source for validation. Further, both PG and merchant site can use this server to server communication to update the state of transaction rather than relying on browser redirect data. i feel that can be a Grade: 10/10.

    • If I understand right what you wrote, it will not be feasible at all. A parallel connection will require twice the server resources at both ends, not to mention it’ll need to have an open port at each end for communication with the added complexity of maintaining some client/server software.

      An HMAC is not tamperable and is better than any complex setup.

      • In Payments, security is of more importance than the server resources. server resources are cheap. And the complexity depends on the architecture and data flow. This is the strategy behind India launch of world’s biggest ecommerce website and its working very well.
        HMAC is good but the big players in PG space have serious security flaws as you mentioned and they are quite inflexible to changes. This is used as an alternative to avoid major changes in the PG platform and still be highly secure.
        just trying to bring another perspective.

        • The key to securing a system properly is not by adding an extra layer of complexity. It’s always better to use well researched protocols and algorithms for security.

      • Most of the payment gateways allow you to get the transaction details via a server to server API call. This can be used to verify the transaction parameters (amount, transaction status etc…). While this is not compulsory, it is always an recommendation specially for merchants who deliver online services (like recharges etc)

  3. Thanks for the informative post. It was really interesting.

    I used stripe for integrating payments from US customers at istream, and the integration hardly took me an hour. I didn’t go much into the details of their security at that time, but looking at the documentation now looks like they have followed all the best practices. Kudos to stripe

    • While writing this post, I looked at Stripe as one of the examples of how to do things right. They have got a really great API and I’d love to see them here, but with the way current Indian law is structured, I don’t think they’ll be able to do that anytime soon.

  4. Hi Gagan

    I congratulate you for putting in good effort, and your post is already popular.

    However, you are entirely missing the point here. Look closely at what Peeyush is saying. You have completely ignored the server to server communication which happens between merchant and payment gateway. This communication makes any such fraud impossible. You can see the PayU integration document, wherein PayU provide APIs for verifying a payment.

    You need to revise your security ratings in this context. Otherwise, your visitors are being misled.

    Disclosure: I work at PayU.

    • I might have missed Peeyush’s point, I assumed he was asking for a decoupled communication system for authorizing transactions. He did not mention what sort of communication it might use.

      Before I revisit the ratings, I’d like to know: Is the server to server communication for verifying payments a requirement or optional?

      • Yes, Peeyush might not have a direct experience of working with a PG. But his idea was in the right direction.

        That verify payment call is optional or required depends on the business type. For businesses which take action only when funds have been settled, it is optional. However, for merchants which start giving product/service before reconciliation, it is a requirement.

        • One more clarification. Is it a strictly enforced requirement in the way that merchants can’t use your gateway at all in that case? Does the merchant have to declare their type of business before they can start using your gateway?

          • Yes, merchants always have to declare their type of business. Its anyway a risk assessment requirement.

            Furthermore, whenever a merchant goes onboard, our integration team works with them to ensure the right integration. We have many of the largest online recharge merchants, the category most susceptible to such fraud. All such recharge merchants use our verify payment API. But in case of billing merchants, you will appreciate that it is not absolutely important, because they will settle the bill only when they get funds corresponding to a particular account.

            I am strictly speaking about PayU enterprise(www.payu.in), and not about PayU Paisa(www.payupaisa.com), which is an altogether different offering from PayU.

            Hope this clarifies.

          • Thanks for the clarification! I wonder if any of the other gateways have a similar requirement.

            I’ve also updated the PayU section.

  5. Thanks for a little bump.

    But what I really meant is that we are 100% secure. Or at least, we can’t congratulate ourselves till we are.
    Even if a fraudster manages to redirect to another domain, verify payment API ensures that the merchant knows no such real transaction happened. As Peeyush said, if server to server communication is there, it guarantees a score of 10/10.

  6. Sorry, I should have made my intention behind the new rating clear. While, I’m convinced of the fact that payment fraud is not feasible, there are still other issues if a merchant’s credentials are compromised. Sensitive data like order history, customer information or actions like processing a refund – can be done by an attacker. As of now, PayU is using ephemeral 302 redirects which are not cached at all.

    Additionally, PayU’s security practices are still a secret.

  7. Good job Gagan.

    I actually came across a fraud using the weakness in the PG where a client of mine lost a few thousand rupees. Of course, once we pointed it out they changed the security. I will try and obtain further details and post it here for others to be aware.

  8. 1. Our login pages are transmitted over HTTPS only. We are not using HTTP for the starting point of authentication.

    2. We are not using HSTS because we use the same domain (www.ccavenue.com) for transactions as well as for hosting the content. If we use HSTS which is the server side header that directs browsers to permanently communicate with this site over HTTPS then the content pages too would be served over HTTPS which is a clear overhead on our systems.

    3. We use secure cookies, which means that the plain-text cookies are never transmitted over an unencrypted channel for unauthorized access by third parties.

    4. The only point that you strongly advocated in the article is the MAC to ensure the integrity of plain-text transaction parameters making hops from web server to web server during browser-centric transactions. You have emphasized the use of message authentication code (MAC) using strong hashing algorithm which is desirable only in case we exchange plain-text parameters. The channels between CCAvenue and Bank are secured by some means or the other (e.g. some banks have encrypted kits while other have AuthQuery for verification) but the channel between merchants web server and CCAvenue PG is now compulsorily encrypted with a new encryption methodology (which we cannot discuss in the open) as well as AuthQuery for successful transactions, which definitely handles the risk of frauds in the backdrop of weak MAC like checksum.

    5. If merchants are using our new encrypted integration, there is no need of any MAC in first place as the data integrity is at risk only if someone breaks our new encrypted encryption which is theoretically impossible and if someone hypothetically breaks our new encryption integration then as a backup, merchants have integrated our post transaction AuthQuery that once again verifies the transaction server to server.

    6. Our above mentioned integration kit is available to all our merchants since the last two years or more. Most of our merchants have integrated with our new encryption kit as well as the post transaction Auth Query, but there are still some old merchants with not so significant transactions still using our old Adler checksum mechanism. Since there are thousands of merchants, it takes a whole lot of efforts to get them to integrate our new encrypted kit.

    Gagan, To conclude, we definitely do not accept 1/10 on Information Security front. Maybe you can set up a telecall with any of our IT security team members to help you better understand our processes and systems.

    • Hi Vishwas,

      First of all, many thanks for replying. Then again, It seems as though some of your answers are contradicted by yourself and by what I see while making payments to merchants using your gateway.

      “the channel between merchants web server and CCAvenue PG is now compulsorily encrypted with a new encryption methodology (which we cannot discuss in the open)”.
      The word “compulsorily” here is definitely not true. I can see the payment data in my browser on many websites which have integrated with CCAvenue.
      I think Gagan is definitely right in this regard that as long as it is not a requirement, there will be merchants who do not use it and therefore be susceptible to risk.

      May I also ask what this new encryption methodology is and why you cannot discuss it in open?

      “the data integrity is at risk only if someone breaks our new encrypted encryption which is theoretically impossible ”
      Or Is it that if somebody knows the encryption being used, it can be attacked and broken.

    • Thanks for the comment, Vishwas.

      My reply to your points in the same order:

      1, 2. Your competitors in this space – Zaakpay, PayU and Payzippy are able to provide HTTPS for their full site. Full site HTTPS is not an overhead when security is important. Your homepage links to: http://mars.ccavenue.com/…, which then redirects to https://mars.ccavenue.com/…, which is what I’ve mentioned in the section about CCAvenue.

      3. Yes, I’ve already mentioned the part about secure cookies in the post.

      4. Just to be clear, I’m not talking about an MITM attack when I mention insecure MAC. If you are encrypting your payload to prevent tampering from a third party it is not really needed since you are already sending data over an encrypted connection. A malicious user could themselves edit the details in the middle of transmission to change the transaction parameters, which is where the need for a strong MAC comes from.

      5. I think you are confusing theory and practicality here. Let’s say you are using AES. It can be broken theoretically, if you try all possible combinations provided you’ve enough time. It’s practically impossible to do so though. I’ll assume the encryption you are using falls into this category. If you are confident of your encryption being unbreakable, you should disclose the details to the public because it’ll only help to assure them of your security practices. In any case, I’d like to mention again, “encryption isn’t authentication”.

      6. I’m really surprised it has taken over two years to migrate. As they are your customers, you should be able to force them to move away from antiquated protocols especially when you are charging a yearly maintenance fee.

  9. Appreciate your efforts in educating merchants by comparing payment gateways on an extremely crucial criterion for choosing a gateway which is the security aspect. At the same time, such reviews could be fairer if sufficient amount of information is made available to you, on the basis of which you could make your judgement and post your comments and evaluation on your blog – the current content is misleading and incomplete. I also feel that there are some very loose and unfair comments in your evaluation of DirecPay as a gateway, i.e. your comment about SQL injection etc is downright dismissive, as is your assumption that there is no authentication!

    Addressing your specific observations about DirecPay:
    1. Cookies are not used for session handling. Cookies are also not used for any client information storage. Merchant login is over https.
    2. The merchant integration document being referenced is an old document. All integrations are a combination of encoding and encryption by issuing keys unique to each merchant – these keys are managed by Direcpay. Since December 2012 all merchants are being migrated to the encrypted integration and a majority of them have done so. However the migration has dependencies on the merchant because of which there may be some older merchants who have not yet migrated. These merchants have been advised to have strong reconciliation processes to avoid tampering of information when it is in transit between merchants site and DirecPay, and are being encouraged to migrate to the encrypted integration methods. New merchants are not allowed to integrate with older encoding method of integration.
    3. SQL Injection – This is prevented by appropriate policies at the network level by use of WAF, as well within the application.
    4. Base64 is not used for authentication. Merchant traffic is encrypted as explained in 2 above, and integration with the banks follows the banks encryption standards as per their integration guidelines. There is a real time server to server validation in place as well.
    5. We cannot comment on your observation on merchant specific implementations. All integrations are secured.

    Do reach out with any follow-up queries you may have on this. It is in our interest as well to secure the site for merchants and we appreciate your effort. You have also written that there was no response from DirecPay – we regret the lack of response from our side. However since we couldn’t find any record of your request for information. do send across the details of your attempts in communicating with us and we will ensure that responses are prompt and proper in future.

    • Sorry about the delay your comment took to appear here, it was picked up by the WordPress spam filter and I just noticed.

      My comment about DirecPay was based on the fact that you had implied in your previous documentation that Base64 is authenticated (tamper proof) encryption, but Base64 provides neither encryption nor authentication. About the points you raised:

      1. Your login page was in a JS popup on your home page (which is not served on a secure channel) when I last checked in August. It seems to have been changed now, and that’s one good step, although the rest of your site (including the home page) is available on HTTP. As for cookies, your merchant pages do use cookies (sessions also use cookies under the hood), and your site cookies are currently not restricted by the type of connection they are sent over.

      2, 3, 4 While an encrypted communication is not as easy to tamper with as Base64, it isn’t ideal. Encryption ensures privacy, not integrity. Repeating my point about encryption I used to reply to CCAvenue – your connection is already encrypted with HTTPS, doing it again doesn’t help. But I can’t comment on the specifics without knowing the details.

      The new API is a recent development which is why I didn’t find any information related to it earlier. I’ll update the post with the fact that you had already been trying to move your customers to a new API, but I can’t change the rating until all merchants move away from Base64 and I find out which encryption you are using and can evaluate it. The part about SQL injection was meant as a light remark and I didn’t mean to imply you were vulnerable to one.

      5. If some merchants are getting an extra secure API, why not everyone else?

      Regarding my emails to DirecPay, I sent an email to contact@ twice, once on 2013-08-05 and later on 2013-08-19.

      Thanks for participating in the open discussion and I look forward to evaluating your new scheme.

      • With respect to your comment “The new API is a recent development which is why I didn’t find … ” – it is not a new API, and the merchant integration details are shared with all prospects. If you have been collecting data from August and still didn’t find this I suppose there is some confusion as these integration methods have been available for quite some time. I will get someone to send across the integration documents to you.
        Since December 2012 we are actively pushing merchants to the more secure integration methods than their existing ones primarily with the intent of offering them the highest levels of security. However there may be merchants who don’t have developers in-house and hence changing to a PGP/merchant key based authentication system which would require them to invest in development time is a possible deterrent – we have little control on that aspect. Enforcing such merchants to integration methods based on authentication or dropping them is a business call – but we do ensure that such merchants are made aware of the risks and educate them on the importance of daily reconciliations,

  10. Hi Gagan,

    Firstly, Kudos to you for having taken the time and effort to evaluate the prevailing security measures adopted by the various Payment Service Provider in India, I do believe that a lot more can be done to make the entire online payment ecosystem smarter, seamless and secure.

    At EBS (and from this point on I will speak only from our perspective), we have people in place to evaluate, recommend and fix what needs immediate action and what can wait, and while there are certain issues which we are in the process of addressing, I would like to highlight that the core transaction, happens on a server to server connection where the actual authentication happens which is basically impenetrable (unless you have someone on the inside). The browser to browser request which is seen simply displays the acknowledgement.

    A few other points which I would like to highlight are:

    1) A secure login page for merchant does exist.

    2) We also have Status API for payment verification.

    3) Since we are aware that the Secret key can be cracked easily, or a transaction state can be modified, we have already developed Secure HASH validation (SHA1, SHA2.) and have implemented it in the new version of our payment page. We are already in the process of moving all merchants to this integration, and we will recommend them to use SHA1 or SHA2 Hashing Validation instead of RC4.

    4) Currently our gateway does provide verification API, so if there are any modifications made in request/response, we can find it and immediately categorize the transaction as failed.

    5) As far as redirecting the user to a fake login page goes this is exactly the reason why we have SSL certificates for the main login page from a reputed party like VeriSign. This issue is mostly related to user education. Any reputed SSL vendor will check the business’ real background. In any login page, all users need to look at the domain name, check for an SSL/HTTPS connection and also verify the certificate if there is any doubt whatsoever. So, in summary, if a redirect even occurs, the page will not contain our certificate and SSL.

    Regards
    Nishanth Chandran
    MD – EBS

    • Thanks for taking the time to reply, Nishanth.

      About the server to server communication – your integration code does not appear to include anything related to it, so I’m not clear on how it works.

      Other points:

      1) Your homepage is available on secure.ebs.in over HTTPS and links to it, but it doesn’t redirect to the HTTPS if the user opens secure.ebs.in directly.

      2) I’m not sure if this status API is compulsory, or how it works. I also cannot find any reference to it in your integration code.

      3) It’s great to know that you already recognize the security limitations and have been working on migrating customers away. However, as I mentioned in my post, using a vanilla hash function is not a good idea. In general, hash functions rely on the fact that it’s not easy to find two messages which can collide to the same hash. Although collisions have not been found for SHA1 yet, newer applications are advised to refrain from using it. Additionally, they are vulnerable to length extension attacks. Simply put, you shouldn’t use H(message) as a MAC.

      4) See response to 2

      5) The redirection to a spoofed login page can happen before the user even touches your SSL page. Another issue here is that your login page is accessible over HTTP. If any of your merchants are used to opening that page directly, they might not notice a missing SSL certificate.

  11. Thanks a lot for the details you have given on this post. Could you also give your views on wepay and juspay?

  12. Hi Gagan,

    I’m Esak & I manage technology @ EBS, sorry we have not been able to revert to you sooner, but please note our feedback to your last post, dated 2013/10/10.

    1) Your homepage is available on secure.ebs.in over HTTPS and links to it, but it doesn’t redirect to the HTTPS if the user opens secure.ebs.in directly. (Gagan)

    -> This was part of our development roadmap and has now been implemented.

    Point 2) I’m not sure if this status API is compulsory, or how it works. I also cannot find any reference to it in your integration code

    -> You can download EBS Transaction API V1.1 Manual to understand how this works (https://support.ebs.in/app/index.php?/default_import/Knowledgebase/Article/View/456/8/ebs-transaction-api-v11-manual)

    Point 3) Gagan – It’s great to know that you already recognize the security limitations and have been working on migrating customers away. However, as I mentioned in my post, using a vanilla hash function is not a good idea. In general, hash functions rely on the fact that it’s not easy to find two messages which can collide to the same hash. Although collisions have not been found for SHA1 yet, newer applications are advised to refrain from using it. Additionally, they are vulnerable to length extension attacks. Simply put, you shouldn’t use H(message) as a MAC.

    -> I do believe that this is at par with the industry standard and most players are using the same method but as, Nishanth has mentioned earlier, we have a team in place to evaluate and recommend, how our technology road map should evolve, so I guess you shall just have to wait and see how we improve on this parameter.

    Point 4) about the server to server communication – your integration code does not appear to include anything related to it, so I’m not clear on how it works.

    -> The Manual should give you more insight on this.

    Point 5) The redirection to a spoofed login page can happen before the user even touches your SSL page. Another issue here is that your login page is accessible over HTTP. If any of your merchants are used to opening that page directly, they might not notice a missing SSL certificate.
    -> Point 1 should cover this issue.

    Do let me know in case you require any more information.

    Regards,

    Esakkimuthu E
    President – Technology
    E-Billing Solutions Pvt Ltd.

    • Good to know you have added a redirect to https on your login page. As for the transaction API, I do understand how it works now – however I didn’t find any reference in the PDF if it is mandatory for the merchant to use the API.

      As for using SHA1 as a MAC, I do not agree with the answer that it’s “industry standard”. Industry standards usually aren’t best practices, and SHA1 as MAC certainly doesn’t fall into that category.

  13. I am just a nursery student in d field of these technical terms. All I know is that I wish to go for a payment gateway for my online handicrafts portal. Now, first I have 2 questions:

    1. Should I go for a free payment gateway?? Will that be of use, since I am just a starter in d online business?? If yes, then which??
    2. Else, which will be d best payment gateway for me? Someone suggested Billdesk..howz tat?

    Since I dont understand these technical terms, I only want to know in nutshell as to which would be d best for me…

    Hoping for a real quick reply from all you intellectuals.

    Thanks!

    A not-so-intellectual being

  14. Hi, Do we have any payment gateway which supports peer-to-peer payments. Similar to card-to-card money transfer. It will be great if we know any such gateway which can be used from server side (like having any cloud service or API exposed).
    I have reviewed many gateways which provides support for such P2P transactions like PayPal, but they dont support INR transactions of such sort. Do you know any payment gateway which can help.

  15. Could not find any payment gateway api which offers server to server integration like payment gateway in US does. For example authorize.net , PayPal , they all give real server to server integration which is 100 %secured. In Indian payment gateways I see most of them gives ability to submit post request using HTML form . Such APIs looks childish and not matured even though E-Commerce is pretty old in India now.

    • Payzippy was offering server to server integration API I guess , but Flipkart recently decided to shut down Payzippy.

  16. The worst payment gateway, First of all i waited for 40 days for the CC/D cards to get activated, they told me that it is activated but i was not able to receive payments through CC/D cards. They gave me the reason that UGI gateway is not working properly on my site and they will install SBI gateway, they asked me to wait another 45 days. There customer service some where in chennai is pathetic, they don’t know what is happening just gives false info that they will resolve within 24 hours, which never happened and they try to speak with false accent as if they r in some foreign country. After 45 days of waiting at last they are saying that now UGI gateway is working fine on your website and no need of SBI gateway. I feel like i have been cheated and robbed. When I try to contact the person to whom I gave Rs. 30,000 as the set up fee, I m getting answers that the person left the job. I am really frustrated. I will advice guys not to try this worst service.

  17. I plan to buy something online and the merchant use CCAvenue. Since you give CCAvenue a rating of 1/10, does that mean I should not put my credit card details online. Is CCAvenue insecure in your opinion? Thanks.