Quantcast

Jump to content


Neocodex Technology Blog



SSL Implementation on Neocodex

Posted by ShadowLink64, in Neocodex, Store, Programming 17 December 2012 · 474 views

SSL Implementation on Neocodex As mentioned in this news post, Neocodex now uses Secure Sockets Layer (SSL) to protect our users from eavesdropping attacks that may occur from using unfamiliar/insecure networks.

But how did we get it all set up?

Modern-day SSL essentially offers two benefits to the end user:
  • Security: Encrypts the traffic between client and server so that a third-party cannot eavesdrop on the data.
  • Trust: Lets the end user know that the identity of the organization using SSL has been verified.
It is possible to implement the former without the latter using self-signed certificates, but we wanted both of these benefits. Because of this, we needed to be issued a certificate from a reputable Certificate Authority (CA) who could verify our identity.

First we needed to generate a private key on our server (*.key file), and then create a Certificate Signing Request (CSR) using that key. This request is then provided to the CA, and once our identity has been verified, a certificate is provided to us in the form of a *.crt file. Our identity was verified using our domain and IP information, as well as having a valid e-mail address associated with our domain. Many CAs go a step further in their background check, but we simply wanted basic assurance for our users instead of nothing at all.

So now, here's where things get a bit technical. We now needed to give our web server enough knowledge so that if anyone wants to connect to us using SSL (by having https:// in their URL bar), it can take care of all of that for us. The things we needed to provide to our web server are:
  • Neocodex's private key (*.key), and neocodex's certificate from the CA (*.crt) combined into one file with extension *.pem
  • The Certificate Authority's own certificate (ca.crt) -- you can find this publicly available on their website.
In lighttpd, this can be done with the following code (inside lighttpd.conf):
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.ca-file = "/path/to/ca.crt"
ssl.pemfile = "/path/to/neocodex.pem"
}

Now, some complications arise when you want to enable SSL on multiple domains. We run a separate site that we sell Neocash from, and so we generated a *.pem file for that domain as well. But, we need to tell lighttpd to use the correct pem file for each domain. This technique is called Server Name Identification, and is implemented in lighttpd the following way:
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.ca-file = "/path/to/ca.crt"
ssl.pemfile = "/path/to/neocodex.pem"

$HTTP["host"] =~ "neocodex.us" {
ssl.pemfile = "/path/to/neocodex.pem"
ssl.ca-file = "/path/to/ca.crt"
}

$HTTP["host"] =~ "otherdomain.com" {
ssl.pemfile = "/path/to/otherdomain.pem"
ssl.ca-file = "/path/to/ca.crt"
}
}
Notice that we reference neocodex.pem twice -- we have to give lighttpd a default pem file to use if neither of these domains are requested, so we use neocodex's certificate if all else fails.

And that's it! After restarting lighttpd, any requests made to https://www.neocodex.us/* are encrypted using a 256-bit algorithm. :p


Troubles processing Neocash orders

Posted by Hydrogen, 31 October 2012 · 433 views
bugs, neocash, store
In our billing system, we have transactions and invoices. Invoices wrap transactions so that you can have multiple transactions within one invoice. Recently, we have been seeing some neocash orders get stuck while processing. All of these invoices have had just one transaction within them. After the user pays for their item, the transaction is marked as paid but the invoice is still left pending. I know of at least 8 neocash card sales that suffered from this issue. This was very confusing for the user and very embarrassing for Neocodex. We pride ourselves in the quality of our service so when we say that neocash orders are delivered instantly and they are not, that's something to be taken really seriously. In all situations where this affected a member, we sent them a PM explaining the issue and manually approved the invoice so that they would get what they paid for. It just wasn't instant.

Today, with the help of the support team at Invision Power Services, we think we've finally figured out what the problem was. Back in late August, we blogged about how we had implemented the immediate neocash delivery system. As it turns out, the code for this system had a slight bug in it. At certain points in a program, things can go horribly wrong and the program needs to catch those states and handle them correctly. That's a great idea except when the code to handle the problem ... has a problem :p. That's what happened here :p.

We believe we have fixed the issue now so all transactions should be working properly again. This issue only affected a few users out of the many that purchase from us and we contacted each of them right away to work with them in getting them what they paid for. However, we wanted to let you know what was going on in case you were curious :).

As always, if you have any questions or concerns, please feel free to contact us by PM or by email at [email protected]eocodex.us.


Sphinx search engine now being used to power Neocodex's search

Posted by Hydrogen, in System Administration 16 September 2012 · 384 views
sphinx, speed, search
Sphinx search engine now being used to power Neocodex's search Currently, Neocodex stores 1,325,357 posts by users in 88,522 topics. Under any measure of the term, I would say that our website has evolved into a large forum. We consistently have over 300 users online at any given time and many more using our autobuyer constantly sending data back to our item database. Such high activity can put quite a strain on our website to perform efficiently. As traffic increases, you might notice that forum responsitivity start to decrease and our server load start to increase :p. I've certainly been noticing that in the last few weeks. That is why I spent a bit of time today installing the Sphinx Search Engine on Neocodex servers.

The Sphinx Search Engine is an open source search engine which indexes database content (topics and posts in our case) and allows you to query them at a later time in a very efficient way. Invision Power Board, our forum software, is now using Sphinx in order to search through our topics and posts to find you the topic that you are looking for. This change allows our forum software to offload the task of finding the topics and posts in question to another process, allowing the forum to only serve you the content.

Invision Power Services have a pretty good tutorial on how to set up Sphinx for your server. Rather than me just reproduce their instructions here, you can read about how to do it on their site.


Dealing with fraudulent charges

Posted by Hydrogen, in Store 09 September 2012 · 1,102 views

As most of you must have seen by now, we have just banned user emotoyol from using our site. Through a series of strange events, we discovered that the user had used stolen credit cards on our site to purchase two and a half years of advanced membership at once. In this blog post, I'll explain what happened, how we resolved it, and what we've done to make sure it never happens again.

What happened
Neocodex admins receive notifications from multiple data sources whenever someone makes a purchase on our website. I personally receive emails and push notifications on my phone. By now, we've gotten to know our most frequent customers and are diligent about correcting any mistakes in purchasing. Some of you have received a PM from me when you didn't get the coupon discount that you deserved or accidentally paid twice for a product that you only wished to pay once for. In all of those situations, we've resolved the issue quickly and efficiently so that everyone can be on their way.

On September 2, 2012, Neocodex admins received a notification that one user, emotoyol, had purchased $157 worth of advanced membership in five minutes. Mostly everyone purchases one month, three months, or six months at a time. In case you are wondering, $157 equals about two and a half years of advanced membership! As I always do when I see something weird, I contacted the user about the transaction.

Posted Image

As you can see, the user read the PM on September 7, 2012 last, but never responded. In a bit of a strange series of events, we discovered that this user had stolen the credit cards used in making these purchases. Our Facebook page started receiving posts by two people, one of which was the person who had his credit card stolen. They were both, understandably, pretty angry about the situation.

Posted Image

I got in touch with the Facebook user who had his credit card stolen by email and we discovered that the issue was a lot larger than just his credit card. I discovered from the credit card processor's logs that emotoyol, while living in Malaysia, had used a credit card from the United States of America, Denmark, and Greece, all within five minutes to purchase advanced membership from our site.

How we resolved it
We have refunded all of the payments received by emotoyol back to their originating credit cards. In addition, we have banned emotoyol from our site based on account, IP address, and hardware ID.

Neocodex admins are currently working to resolve this issue with Stripe (our credit card processor). So far, we've only sent an email to Stripe informing them of the issue. Being the first time I've ever had to deal with fraudulent activity, we've deferred to them on what the best plan of action is. We may be contacting the local authorities regarding this user and will provide whatever information is necessary to help with the investigation.

What we have done to make sure it will never happen again
The ability to purchase such large quantities of advanced membership at once was due to a bug in our e-commerce system which allowed users to upgrade to and from deprecated packages that were still set to have infinite amounts of stock instead of the zero stock that they should have had. That bug has been fixed in our system and should not occur again.

Furthermore, we have implemented extra fraud checks by purchasing a subscription to Maxmind.net. Maxmind analyzes transaction information and returns a fraudulence score back to our servers which can help us determine whether or not a transaction should be reviewed or declined. These fraud checks run in addition to the fraud checks that are run by Stripe (our credit card processor) and Paypal, depending on which payment method you choose.

Conclusion
This was the first time we've had to deal with truly fraudulent payments on Neocodex. As with all firsts, I can truly say that I've learned a lot in the last two hours :p. While we have refunded all transactions, I sincerely hope that we can get the money back to the people it belongs to. Credit card fraud is serious business and this was a strange situation to wake up to on Sunday morning :p. The investigation is still ongoing, but I believe that the changes we have made will protect us in the future from getting into this situation in the first place.


How We Implemented The Immediate Neocash Code Delivery System

Posted by Hydrogen, in Programming 26 August 2012 · 831 views
neocash, programming, products
How We Implemented The Immediate Neocash Code Delivery System Neocodex has recently started to sell Neocash cards through its store with immediate delivery. In this blog post, I want to take you through the history of how we got here, and how we implemented the immediate delivery solution that is custom to our website, and unique to all Neocash delivery services on the internet.

On April 16, 2012, Pyro699, one of the admins on our site offered to purchase Neocash for our members. The system was completely manual. Users would post in the thread, and Pyro699 would go to the store to buy the Neocash card for the user. The delivery would be made through a PM. The whole process would take a few days, depending on how long it took to go to the store at a convenient time. In the three months that the service was available, Pyro699 sold $215 worth of Neocash cards, plus a small fee.

On July 31, 2012, we evaluated the Neocash selling system that Pyro had set up and saw that it had generated quite a bit of sales. We decided to make things a bit more official and move the service into our store. The process was still the same, however: Pyro699 would go to the store whenever an order was generated and deliver the Neocash code through the PM system, manually. The service was available for three weeks and we sold 4 $10 Neocash cards, and 8 $25 Neocash cards, for a total of $240 plus our fee.

On August 19, 2012, we wrote a simple plugin to take things one step further and introduced a system that would deliver the Neocash card codes immediately without requiring users to wait for us to go to the store. It required us to keep an inventory of Neocash codes on hand and write a custom trigger for our e-commerce software, IP.Nexus.

To get an idea of what a custom action looks like, we've reproduced some of our code here:

<?php

/**
 * Externally instantiate the IPS API
 */
define('IPS_ENFORCE_ACCESS', TRUE);
define('IPB_THIS_SCRIPT', 'public');
require_once('/var/www/html/forum/initdata.php');
require_once(IPS_ROOT_PATH . 'sources/base/ipsRegistry.php');
require_once(IPS_ROOT_PATH . 'sources/base/ipsController.php');

class custom_actions_neocash {
    public function onPurchaseGenerated($member, $package, $invoice, $purchase) {
        /*
         * settings -- we might want to change these
         */
        $this->from_member_id = 34316; // pyro
        $this->low_stock_value = 1; // how many items remaining in our inventory constitutes a low stock alert?

        /*
         * Instantiate the IPS registry
         */
        $this->registry = ipsRegistry::instance();
        $this->registry->init();

        if(!$this->messengerFunctions) {
            $classToLoad = IPSLib::loadLibrary(IPSLib::getAppDir('members') . '/sources/classes/messaging/messengerFunctions.php', 'messengerFunctions', 'members');
            $this->messengerFunctions = new $classToLoad($this->registry);
        }

        /*
         * Set up a shorthand for the database connection
         */
        if(!$this->DB) {
            $this->DB = $this->registry->DB();
        }

        /*
         * Which package did the user purchase?
         */
        switch($package['p_id']) {
            case 8: // 1000 neocash
                $value = 1000;
                break;
            case 9: // 2500 neocash
                $value = 2500;
                break;
            case 15: // 1500 neocash
                $value = 1500;
                break;
            default:
                $this->send_out_of_stock_pm($member['member_id'], 'unknown package');
                return;
        }
    }
}

?>

A lot of the code has been omitted for brevity. All it does after what has been shown is pull the Neocash code from the database and send a PM to the user. To understand how to do this, you can consult the IPB API:


The system has some work left to do. If you didn't notice, purchasing multiple Neocash cards at the same time might not work yet. Furthermore, we have to make sure that the number of cards reported to be in stock is updated at every transaction, just in case. We don't want to report that there are cards in stock when there aren't.

While there is some work to do with the system, the basic framework is there to support immediate delivery of Neocash card codes :). Hopefully this post gives you a bit of insight about what it took to get a product from start to (almost) finish on Neocodex :). Expect more posts about the technological backend of Neocodex to follow :D.





Search My Blog

Recent Comments

Latest Visitors