Suresh Thapa / Programmer / Web

Saturday, March 01, 2008

Black Hat vs. White Hat vs. Grey Hat SEO

Let’s face it: as long as there is a logical-sounding, convenient (useful) label floating around, it will get used and mis-used. That is the story of “Black Hat SEO” and “White Hat SEO”. They are poor quality labels, poorly-defined (in practice), yet so easily “understood” and so convenient that they persist… year after year.

Personally I believe that these labels are good for Google, and bad for SEO practitioners. I believe that by labeling SEO as “black” or “white”, Google gains an opportunity to influence the popular perception of SEO in it’s favor, where otherwise it would not have such an opportunity. Of course Google has used this to its advantage many times (such as the times it has cautioned web site owners not to trust SEOs, because they may employ Black Hat tactics…F.U.D.). As I have said before, there is only one color of SEO worthy of effort, and that’s Green SEO.
So while it is unfortunate that we have to accept these labels, we do have to accept them because our clients think they understand them. Therefore, it is also essential that we properly define them.

That’s really quite easy to do, especially when you start with the definition of “Black Hat” SEO:

Black Hat : techniques or tactics which have been defined by Google as in violation of the Google “Quality Guidelines” (see “Quality Guidelines, which outline some of the illicit practices that may lead to a site being removed entirely from the Google index”) . The Black Hat label applies to those methods specifically mentioned n the “Guidelines”, other methods and/or tactics or circumstances mentioned by Matt Cutts in his blog, in Matt’s comments on others’ blogs, or just about anywhere anyone from Google says anything that strongly suggests Google took action against a site for some specific reason. Black Hat SEOs know what they are doing is defined as BAD, and do it anyway for specific reasons (not usually including “get banned”). I like to think of Black Hat SEOs as opportunists. They see an opportunity to gain, and take it, managing the associated risk. Please don’t confuse ignorant SEOs with Black Hat SEOs… the ignorant ones are those who execute on Black Hat (evil) tactics without managing the risks (either out of ignorance or folly doesn’t matter to me here).

White Hat: techniques or tactics which can be defended as NOT being contrary to the spirit of Google’s expressed quality desires, by citing Google’s own published guidelines, Matt Cutts’ blog posts, or comments posted in other places, or just about any other Google communication. I like to refer to White Hat SEOs as “conservatives” of the SEO world… where things are viewed as BLACK or WHITE (GOOD or BAD), and the letter of the Google god is taken verbatim as TRUTH. Yes, there is a bit of a timeline problem with that approach (if Matt said it was bad in 2002, is it still bad?) but that’s just the tip of the White Hat iceburg.

Grey Hat (or Gray Hat): Since the color gray is between black and white, logically Grey Hat SEO sounds like a label for the middle ground. But it’s not. Because White is pure white and grey is a shade of black, we have confusion. Some say Grey Hat is NOT White Hat and is just a shade of Black Hat. So let’s step away from the coor wheel and define Grey Hat as the practice of tactics/techniques which remain ill-defined by all that published material coming out of Google, and for which reasonable people (not White Hat SEOs, mind you, but “reasonable people”) could disagree on how the tactics support or contrast with the “spirit” of Google’s published guidelines.

Updated 06/2007: In response to comments, and recent emphasis by Google on “webmaster intent”, I would say Gray Hat includes all areas where you feel you need to have some plausible deniability in place for your actions. Personaly I don’t believe in gray hats… but for the Definitive Guide, let it be defined.
So here we have the Definitive Definition of Black Hat vs. White Hat vs. Grey Hat. In summary, Black Hats know they are taking risks, defying some of Google’s expressed behavior guidelines. White Hats will only do what Google says is ok, and Grey Hats will try things which they believe are ill-defined by Google, without first asking permission.

According to Google, White Hat SEO is good, Black Hat SEO is bad, and most Grey Hat SEO is risky (ill-advised — see note below).

To the Black Hat SEO, White Hat SEO is non-competitive, Grey Hat SEO is a safe bet, and Black Hat SEO is the only thing that will beat good Grey Hat SEO.

To the Grey Hat SEO, White Hat SEO is effective only for SERPs where there are no Grey Hat or Black Hat SEOs, Black Hat SEO is for high-risk, high-yield opportunities, and in most cases, the term “SEO” means either Black Hat SEO or Gray Hat SEO. The rest is just good web mastering.

To the White Hat SEO, Black Hat SEOs are cheaters who need to be reported to Google, Gray Hat SEOs are quitters who need to be reported to Google (just in case it might get them penalized and dropped from the SERPs), and White Hat SEOs are good people worthy of reciprocal link exchanges (especially third-party exchanges), raving blind testimonials, and unconditional support.

I hope that helps clear up some of the confusion, and we can all move on from here. I suppose a good first step would be to gather every word ever uttered by Google on SEO, and update each item for the today tomorrow today (every day?), so we can know exactly what is Black or White. Then we can write down every other possible approach to web design, including those not yet invented, and make a big comprehensive list. We can then set up a meeting with Matt Cutts to label them as either Black or White. Whenever he has to “ask the right people at Google and get back to us”, we will label the item as Grey. That way we, as an industry, can use these new definitive definitions of Black/White/Grey to our advantage and clear up the confusion once and for all. If we are successful, we can publish an book, listing the Black Hat, White Hat, and Grey Hat SEO tactics everyone can use. Or better yet, just list the White Ones (since by definition, non-White tactics will be ill-defined or ill-advised).

We can call is the SESO Book, for Search Engine Sub-Optimization Book. Possibly we can do away with SEO altogether, in favor of SESO. We might even be able to get Google to pony up some of that AdWords/AdSense profit to support an Association. Maybe an Association for Sub-optimal Search Engine Services?

I may be projecting a bit far ahead here, but even with such an excellent industry catalog of tactics and techniques, I suppose there will still be an item or two that eludes a static assignment of risk as pertains to Google’s “SERP-busting sledgehammer of Justice”. Perhaps something that changes, or an item which isn’t easily labeled outside of its context. It could happen. So for those who really need to work with those edge circumstances, we can simply lump them together into a category called “competitive webmastering”.

Note: Google includes a threat statement in it’s Webmaster Guidelines that alludes to Grey Hat SEO as ill-advised, and indirectly calls it “spam” : “It’s not safe to assume that just because a specific deceptive technique isn’t included on this page, Google approves of it. Webmasters who spend their energies upholding the spirit of the basic principles will provide a much better user experience and subsequently enjoy better ranking than those who spend their time looking for loopholes they can exploit…If you believe that another site is abusing Google’s quality guidelines, please report that site… spam reports we receive are used to create scalable algorithms that recognize and block future spam attempts.” — emphasis added.


Ref: http://www.johnon.com

Labels: , , ,

Friday, February 01, 2008

Google Checkout Notification API - Outlines

Notification API:

Responding to Notifications:
- Using HTTP response codes to indicate successful or failed processing:

- Using a notification handshake to confirm successful processing:
check the box that says, "Require notification acknowledgments to specify the serial number of

the notification."


##############################################################
New Order Notifications:
inform you of new orders that have been submitted through Google Checkout.

- shopping cart :
list of items, expiration date for the shopping cart

- order-adjustment :
shipping method, shipping cost, taxes charged, coupons and gift certificates, if you implemented

the Merchant Calculations API

- buyer-billing-address :
billing addresses for the order

- buyer-shipping-address :
shipping addresses for the order

- order-total :
- Order total by adding the price of the items, shipping charges and taxes, and then subtracting

adjustments for coupons and gift certificates.

- buyer-id :
- ID that Google uses to uniquely identify a user

- buyer-marketing-preferences :
- Whether the buyer would like to receive marketing emails from you


##############################################################
Risk Information Notifications:
Includes financial information such as the customer's billing address, a partial credit card

number and other values that help you verify that an order is not fraudulent.

Note: Before shipping the items in the order, you should wait until you have also received the

new order notification for the order and the order state change notification informing you that

the order's financial state has been updated to CHARGEABLE.

Risk-information:
- Contains information about the buyer that can be used to detect the risk, including the

possibility of fraud, associated with an order. Below are the subtags:

Billing-address:
- Address1, address2?, city, company-name?, contact-name, country-code, email?, fax?, phone?,

postal-code, region

Avs-response:
Y - Full AVS match (address and postal code)
P - Partial AVS match (postal code only)
A - Partial AVS match (address only)
N - no AVS match
U - AVS not supported by issuer

Buyer-account-age:
- Identifies the age, in days, of the buyer's Google Checkout account.

Cvn-response:
M - CVN match
N - No CVN match
U - CVN not available
E - CVN error

Eligible-for-protection:
- Indicates whether an order is eligible for Google Checkout's payment guarantee policy.

Ip-address:
- Buyer's IP address

Partial-cc-number:
- Contains the last four digits of the buyer's credit card number.


##############################################################
Order State Change Notifications:
- Signal an update to an order's financial status or its fulfillment status

- Notify you that an order's financial status or its fulfillment status has changed
The notification identifies the new financial and fulfillment statuses for the order
as well as the previous statuses for that order.

For example:
- If you send Google Checkout a request,
Google will respond through the Order Processing API
to inform you that it changed the order's status to CANCELLED.

Financial-order-state:
- identifies the stage of the payment process where the order is located.

- Valid financial states include
- REVIEWING : default financial state for all new orders.
- may issue cmd
- CHARGEABLE : may issue cmd
- CHARGING: indicates that Google is in the process of charging the customer.
- No cmd
- CHARGED : you have fully or partially (amount) charged the customer for an order.
- may issue cmd
- PAYMENT_DECLINED : Google's effort to authorize or charge the customer's CC failed.
- may issue cmd
- CANCELLED : either the buyer or the merchant canceled the order.
- buyer's credit card is declined
- buyer can cancel an order within 15 minutes of placing that order.
- CANCELLED_BY_GOOGLE : Google may cancel an order if the CC authorization fails
and the customer does not provide a new CC within 72 hours.

- Financial commands:
Enable you to authorize or perform credit card transactions for an order.
- charge-order
- refund-order
- cancel-order
- authorize-order

Fulfillment order state:
- Enables you to track orders through the fulfillment process
and to convey the fulfillment status to the buyer.

- Valid order's fulfillment states:
- NEW : Unless, one item in the order is either not yet shipped or backordered.
- if all of the items in the order are either shipped, cancelled or returned.
- if you reset the shipping status of any items in the order.
- PROCESSING :
- DELIVERED : if all of the items in the order have either been shipped,
returned or cancelled.
- may use cmd
- WILL_NOT_DELIVER : if all of its items have been cancelled.
- may use cmd

- API commands : used for either line-item shipping or order-level shipping API integration.

A) Line-item shipping commands:

ship-items:
specify shipping information for one or more items in an order.
- use merchant item IDs to identify the items in your order.
- identifies the carrier responsible for shipping the item
- you have the option of also providing the order tracking number for the shipment.

backorder-items:
items are out of stock.
- use merchant item IDs to identify the items in your order.

cancel-items:
items that are being removed from an order
- initiated by the merchant or by a request from the buyer.

return-items:
items that were shipped and sent back to the merchant for a replacement product or a refund.

reset-items-shipping-information:
you remove the shipping status associated with one or more items
and return those items to the not yet shipped state.

add-merchant-order-number:
instructs Google Checkout to associate a merchant-assigned order number with an order.

send-buyer-message:
instructs Google Checkout to place a message in the buyer's Google Checkout account.
- element indicates that Google should email the customer


B) Order-level shipping commands:

process-order:
instructs Google Checkout to update an order's fulfillment state from NEW to PROCESSING
- This cmd is optional.

deliver-order:
instructs Google Checkout to update an order's fulfillment state from
either NEW or PROCESSING to DELIVERED.
- You would send this cmd after the order has been charged and shipped.

add-tracking-data:
- instructs Google Checkout to associate a shipper's tracking number with an order.

cancel-order:
instructs Google Checkout to cancel a particular order of states CHARGEABLE or PAYMENT_DECLINED
- If the customer has already been charged,
you must refund the customer's money before you can cancel the order.

add-merchant-order-number:
instructs Google Checkout to associate a merchant-assigned order number with an order.

send-buyer-message:
instructs Google Checkout to place a message in the buyer's Google Checkout account.
- element indicates that Google should email the customer


C) Archiving commands:
Manage the list of orders in your Merchant Center inbox.
Archiving commands do not have any impact on an order's status

archive-order:
instructs Google Checkout to remove an order from your Merchant Center Inbox.
- using google-order-number

unarchive-order:
instructs Google Checkout to return a previously archived order to your Merchant Center Inbox.
- using google-order-number


##############################################################
Amount Notifications:
Google defines a set of notifications that report info about financial txns for an order.

a) Charge Amount Notifications:
Sent after successfully charging a customer for an order.
- GC > Settings > Preferences > "Automatically authorize and charge the buyer's credit card."

b) Refund Amount Notifications:
Sent after successfully executing a order processing command.

c) Chargeback Amount Notifications:
Sent when a customer initiates a chargeback against an order
and Google approves the chargeback.

d) Authorization Amount Notifications:
Sent in response to a successful request for an explicit CC reauthorization.

Labels: , , ,

Tuesday, January 01, 2008

Recommended payment gateways



Payment gatewayReal-time solution priceGateway feeMonthly minimumRateTrans. feeTech support feeOptionsMerchant account
Wells Fargo $99 $29/month n/a 2.14-2.97% $0.30 None Visa, MC, AMEX US only
Payment Express Included in gateway fee $30 per month, 50 free transactions. N/A Independent bank charge N/A Included in gateway fee Visa, MC, AMEX, Bankcard, Diners, EFTPOS, Farmers, JCB and many more Australia, Malaysia, New Zealand, Pacific Islands, Singapore
2checkout $49 $0.00 $0.00 5.05% $0.45 None Visa, MC, Discover, AMEX Intl
viaKLIX Rates vary Rates vary Rates vary Rates vary Rates vary Free 24/7 coverage Visa, MC, AMEX, Discover US only
NetBilling N/D N/D N/D 1.5% $0.15 N/D Visa, MC, Discover, AMEX, ACH Intl
USAePay $50 $7.50 n/a n/a $0.00 $0.00 Visa, MC, AMEX, Discover, Diners, JCB, Check Selected countries
DirectOne AU $0.00 AU $395.00/yr AU $0.00 0.0% AU $0.45 AU $0.00 Visa, MC, BankCard, Amex, Diners, JCB Australia
Google Checkout None None N/A 0%-2% 0-$0.20 Free Visa, MC, AMEX, Diners US only
PayPal None None None 2.9% $0.30 None Visa, MC, Dicover, AMEX Selected countries
Ogone € 297.47 €30.99 - €197.60 / month N/D As determined by bank € 0.86 - € 0.20 N/D Visa, Mastercard, American Express, Diners Club, JCB and more Europe
LinkPoint (Card Service International) $499 $30/month $15.00 2.38% $0.25 None Visa, MC, Discover, AMEX US only
Protx specialises in processing secure online credit and debit card transactions and is one of the UK's most competitive payment service providers (PSP's) n/a £20/month (under 1000 transactions per quarter) n/a 0.0% 10p (only if over 1000 transactions per quarter) n/a Visa, MC, Delta, Amex, Switch, Solo UK only
MultiPay n/a n/a n/a 3.1-3.5% € 0.35 N/D Visa, MC, Eurocard Netherlands
NetRegistry $0.00 $55.00/month As determined by bank 0% None - Flat Rate of $55 per month unlimited transactions Included at no extra charge Visa, MasterCard, BankCard, AMEX, DINERS, JCB Australia
Payzip €100 n/a None 5.50% €0.50 n/a Visa, MC, wire transfer, Payzip account debit Intl
Plug'nPay $399 N/D $20.00 1% N/D N/D Visa, MC, Discover, AMEX US only
PaySystems N/D N/D N/D from 2.3% N/D N/D Visa, MC, AMEX Intl
ePDQ N/D £20/month N/D N/D 1% N/D Visa, MC, Switch, AMEX, JCB UK only
Centipaid $0.00 $0.00 $0.00 3% for trans. over $10 $0.0004-$1.00 for trans. under $10 None Visa, MC, checks, cash, paypal, money orders Intl
PayByCheck $99.95 $9.95/month %0.0 $0.00 $0.94-$1.36 N/D Checks Intl
ECHO is a Merchant Processor and Secure Payment Gateway. Features: Payment Gateway software and service is included with their low fees. Process all credit cards as well as ACH and Online Checks in Real Time. Virtual Terminal for Credit Cards and Checks. Online Reporting. 24/7 phone support. Recurring Payment Manager (RPM) included. $99 (free to switch) $0.00 $0.00 1.99%-2.54% $0.30 $19.95 (if you process) Visa, MC, Discover, AMEX US only
Cardia n/a NOK 599/month (approx. $97) n/a 0% NOK 3 (approx. 48 cent) NOK 3000 (approx. $484) Visa, MC, Eurocard + Contopronto (mobile payment) Europe
NetBanx N/D £0.00 £10 1%-8% None N/D Visa, MC, AMEX, Diners, JCB, Eurocard, Switch, Delta Intl
MultiCards $95-$575 $0.00 $0.00 5.9%-11.9% $0.45 Free support Visa, MC, AMEX Europe
Authorize.Net (AIM) $299 $20 $0 0%-2.4% $0.35 Free support Visa, MC, Discover, AMEX, JCB, Enroute, Diners, eCheck.Net US only
WorldPay $399 N/D $50.00 3.25% (rates vary) $0.40 $50/month Visa, MC, JCB, SWITCH, Delta Intl
eWay $0 $199/year $0 0% $0.50 Free Support Visa, MC, AMEX, Diners, JCB Australia & New Zealand
Payment Resources Int. $99.00 (no app fee) $10.00 $10.00 2.39% AU $0.40 Free training and integration. Visa, MC, Amex, Diners, Disc, JCB, ACH, Check guarantee, Wireless & POS integrated US only

*) "N/D" = "Not disclosed"
*) "n/a" = "Not available"

Labels: , , , , , , ,

Thursday, November 22, 2007

Software Engineering Definitions

  1. Project Manager is a Person who thinks nine women can deliver a baby in one month.
  2. Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.
  3. Developer is a Person who thinks it will take 18 months to deliver a baby.
  4. Team Lead is a person actually knows how many men and women required to deliver the baby, but will not tell anyone.
  5. Client is the one who doesn’t know why he wants a baby.
  6. Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
  7. Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.
  8. Documentation Team thinks they don’t care whether the child is delivered, they’ll just document 9 months.
  9. Quality Auditor is the person who is never happy with the PROCESS to produce a baby.
  10. Designers don’t care…they just want the woman!!
  11. Tester is a person who always tells his wife that this is not the Right baby.

CRON JOBS

The CRON Command is in the Following Format:
[ Minute - Hour - Day - Month - Weekday ] - Command

The COMMAND, can be broken down in:
[PATH OF PHP] [ARGUMENTS] [PATH OF PHP SCRIPT]

So the COMPLETE CRON command can be written as:
[ Minute - Hour - Day - Month - Weekday ] [PATH OF PHP] [ARGUMENTS] [PATH OF PHP SCRIPT]

The timing is spedified using * symbols:
* * * * * => Execute every minute
0 * * * * => Execute every Hour
0 0 * * * => Execute every mid-night
0 0 0 * * => Execute every Month
0 0 0 0 * => Execute every Weekday

Since this is a UNIX command, You will have to Mention the PATH of PHP:
PATH TO PHP : /usr/local/bin/php
~OR~
PATH TO PHP : /usr/bin/php

These are the Possible Command line Arguments you can use. This will effect the output.
In our case, we will use the -q ( Quiet mode ) argument, which is most commonly used:
-a Run interactively
-b | Bind Path for external FASTCGI Server mode
-C Do not chdir to the script's directory
-c | Look for php.ini file in this directory
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value 'bar'
-e Generate extended information for debugger/profiler
-f Parse . Implies `-q'
-h This help
-i PHP information
-l Syntax check only (lint)
-m Show compiled in modules
-q Quiet-mode. Suppress HTTP Header output.
-s Display colour syntax highlighted source.
-v Version number
-w Display source with stripped comments and whitespace.
-z Load Zend extension .

The Path of the PHP file Must be Complete absolute path.
If your USERNAME is "shoorace", Your path will be:
/home/shoorace/public_html/

I assume you are familier with the PUBLIC_HTML directory. That is the Root folder where you store your html files.

So lets say that "shoorace" wants to execute my script "autotrigger.php" every hour. And it is stored in "public_html/cron/autotrigger.php".
Here, is cron is user created folder, ie not default.

So the Complete CRON command for every hour would be ,
0 * * * * /usr/bin/php -q /usr/home/shoorace/public_html/cron/autotrigger.php


Snapshot for cpanel >
Advanced (Unix Style):

Tuesday, October 30, 2007

Credit Card Validation

Credit Card Validation

What do we actually mean when we say "validate a credit card number"? Quite simply it means that we run a credit card number through a special algorithm known as the Mod 10 algorithm.

This algorithm processes some simple numerical data validation routines against the number, and the result of this algorithm can be used to determine whether or not a credit card number is valid. There are several different types of credit cards that one can use to make a purchase, however they can all be validated using the Mod 10 algorithm.

As well as passing the Mod 10 algorithm, a credit card number must also pass several different formatting rules. A list of these rules for each of the six most popular credit cards is shown below:

  • mastercard: Must have a prefix of 51 to 55, and must be 16 digits in length.
  • Visa: Must have a prefix of 4, and must be either 13 or 16 digits in length.
  • American Express: Must have a prefix of 34 or 37, and must be 15 digits in length.
  • Diners Club: Must have a prefix of 300 to 305, 36, or 38, and must be 14 digits in length.
  • Discover: Must have a prefix of 6011, and must be 16 digits in length.
  • JCB: Must have a prefix of 3, 1800, or 2131, and must be either 15 or 16 digits in length.

As mentioned earlier, in this article we will create a PHP class that will hold the details of a credit card number and expose a function that indicates whether or not the number of that credit card is valid (i.e. whether it passed the Mod 10 algorithm or not). Before we create that class however, let's look at how the Mod 10 algorithm works.

Test Credit Card Numbers

These credit card numbers can be used to test a transaction at ECHO. They are numbers that banks will reject as invalid without problem and are intended for system testing.

These test numbers work just like live accounts, but none of the transactions are actually settled and no money moves. Be sure to use valid data or you will get errors on things like card numbers, checking information, check writer ID info, etc. Please do not use a real credit card with test accounts unless you run a $1.00 transaction. If you do more, your card will have the funds held by each authorization until it expires. The test card will always give a result, the address verification and security code will match regardless of the input values. Furthermore, it will authorize with no expiration date. If you need to see different address verification and security code results, you must use a live credit card. In this case, please use low dollar amounts ($1.00).

Test VISA credit card number: 4005550000000019

Test Credit Card Numbers
Card Type Card Number Number Characters



Master Card 5105105105105100 (16) Characters
Master Card 5555555555554444 (16) Characters
Master Card 4222222222222 (13) Characters
VISA 4111111111111111 (16) Characters
VISA 4012888888881881 (16) Characters



American Express 378282246310005 (15) Characters
American Express 371449635398431 (15) Characters
Amex Corporate 378734493671000 (15) Characters
Dinners Club 38520000023237 (14) Characters
Dinners Club 30569309025904 (14) Characters



Discover 6011111111111117 (16) Characters
Discover 6011000990139424 (16) Characters
JCB 3530111333300000 (16) Characters
JCB 3566002020360505 (16) Characters




Test Credit Card Numbers:
Visa: 4111-1111-1111-1111
MasterCard: 5431-1111-1111-1111
Amex: 341-1111-1111-1111
Discover: 6011-6011-6011-6611




Credit Card Prefix Numbers:
Visa: 13 or 16 numbers starting with 4
MasterCard: 16 numbers starting with 5
Discover: 16 numbers starting with 6011
AMEX: 15 numbers starting with 34 or 37


The Mod 10 Algorithm

There are three steps that the Mod 10 algorithm takes to determine whether or not a credit card number is valid. We will use the valid credit card number 378282246310005 to demonstrate these steps:

Step One

The number is reversed and the value of every second digit is doubled, starting with the digit in second place:

378282246310005

becomes...

500013642282873

and the value of every second digit is doubled:

5 0 0 0 1 3 6 4 2 2 8 2 8 7 3

x2 x2 x2 x2 x2 x2 x2

-------------------------------------------

0 0 6 8 4 4 14

Step Two

The values of the numbers that resulted from multiplying every second digit by two are added together (i.e. in our example above, multiplying the 7 by two resulted in 14, which is 1 + 4 = 5). The result of these additions is added to the value of every digit that was not multiplied (i.e. the first digit, the third, the fifth, etc):

5 + (0) + 0 + (0) + 1 + (6) + 6 + (8) + 2 + (4) + 8 + (4) + 8 + (1 + 4) + 3

= 60

Step Three

When a modulus operation is applied to the result of step two, the remainder must equal 0 in order for the number to pass the Mod 10 algorithm. The modulus operator simply returns the remainder of a division, for example:

10 MOD 5 = 0 (5 goes into 10 two times and has a remainder of 0)

20 MOD 6 = 2 (6 goes into 20 three times and has a remainder of 2)

43 MOD 4 = 3 (4 goes into 43 ten times and has a remainder of 3)

So for our test credit card number 378282246310005, we apply a modulus of 10 to the result from step two, like this:

60 MOD 10 = 0

The modulus operation returns 0, indicating that the credit card number is valid.

Now that we understand the Mod 10 algorithm, it's really quite easy to create our own version to validate credit card numbers with PHP. Let's create our credit card function now.


private bool CheckCCNo(string sInput )
{
///What: This routine will check the validity of a CC no... It will NOT check the account behind it.
///Who: Eric D. Burdo
///When: 6/16/03
///How: bR = CheckCCNo("5412222244447777")
/// this will return True or False, depending on whether the CC passes or fails
///
///The Luhn Mod 10 Algorithm is a means to validate credit card numbers. Note
/// that it validates the *number*, not the *account*. A number can be a valid
/// credit card number but not have an account associated with it. Or the
/// account could be deliquent, cancelled, etc.
///THE ALGORITHM:
/// 1. Starting from the end of the string of digits, double each even (2nd,
/// 4th, etc.) digit. If the result is 10 or more, store it as 2 digits (1
/// and 0, 1 and 8, etc.)
/// 2. Sum the odd digits (starting from the back) and the result digits.
/// 3. The resulting number should be divisible by 10. If so, the original
/// string passes the test.
///EXAMPLE (Credit Card number: 1234 5678 7654 3210):
/// (Back)
/// 0 = 0 => +0
/// 1 * 2 = 2 => +2
/// 2 = 2 => +2
/// 3 * 2 = 6 => +6
/// 4 = 4 => +4
/// 5 * 2 = 10 => +1+0
/// 6 = 6 => +6
/// 7 * 2 = 14 => +1+4
/// 8 = 8 => +8
/// 7 * 2 = 14 => +1+4
/// 6 = 6 => +6
/// 5 * 2 = 10 => +1+0
/// 4 = 4 => +4
/// 3 * 2 = 6 => +6
/// 2 = 2 => +2
/// 1 * 2 = 2 => +2
/// (Front) =====
/// =60 And 60 MOD 10 = 0 so it passes.
///---------------------------------------------------------------------------
int iIndex=0, iCheckSum=0;
bool bOnlyDigits=false, bEven=false;
string sDigits="";

//Validate the input. The string should only contain digits 0-9.
bOnlyDigits = (0 < iindex =" 0;" bonlydigits =" false;" iindex =" sInput.Length">= 0; --iIndex)
{
if (bEven)
{
int iR = Convert.ToInt32(sInput.Substring(iIndex, 1));
sDigits = string.Concat(sDigits, Convert.ToString(iR * 2));
}
else
{
sDigits = string.Concat(sDigits, sInput.Substring(iIndex, 1));
}
bEven = !bEven;
}

//Add up the digits in the string into the checksum.
iCheckSum = 0;
for (iIndex = 0; iIndex < ichecksum =" iCheckSum" ichecksum =" -1;"> 0
}

iIndex = iCheckSum % 10;
return Convert.ToBoolean(iIndex == 0);
}

private string DetermineCardType(string sCCNo )
{

//CardTypes Prefix Width
//American Express 34, 37 15
//Diners Club 300 to 305, 36 14
//Carte Blanche 38 14
//Discover 6011 16
//EnRoute 2014, 2149 15
//JCB 3 16
//JCB 2131, 1800 15
//Master Card 51 to 55 16
//Visa 4 13, 16

try {
switch (Convert.ToInt32(sCCNo.Substring(0, 2)))
{
case 34:
case 37:
return "Card type is: American Express";
//break;
case 36:
return "Card type is: Diners Club";
//break;
case 38:
return "Card type is: Carte Blanche";
//break;
case 51:
case 52:
case 53:
case 54:
case 55:
return "Card type is: Master Card";
//break;
default:
switch (Convert.ToInt32(sCCNo.Substring(0, 4)))
{
case 2014:
case 2149:
return "Card type is: EnRoute";
//break;
case 2131:
case 1800:
return "Card type is: JCB";
//break;
case 6011:
return "Card type is: Discover";
//break;
default:
switch (Convert.ToInt16(sCCNo.Substring(0, 3)))
{
case 300:
case 301:
case 302:
case 303:
case 304:
case 305:
return "Card type is: American Diners Club";
//break;
default:
switch (Convert.ToInt32(sCCNo.Substring(0, 1)))
{
case 3:
return "Card type is: JCB";
//break;
case 4:
return "Card type is: Visa";
//break;
default:
return "Unable to determine credit card type.";
//break;
}
}
}
}
}
catch (Exception e)
{
return "Unable to determine credit card type.";
}
}


Friday, September 14, 2007

mod_rewrite

Sunday, March 19, 2006

RSA Encryption Algorithm

RSA Encryption Algorithm

RSA is a public key encryption algorithm developed by Rivest, Shamir and Adleman. Its
strength lies in the tremendous difficulty in factorization of large numbers. RSA is a block
cipher and the plain text is encrypted in blocks. The plain text and cipher text are integers
between 0 and n-1, for some n, discussed subsequently. Let the plain text block be
represented using a k-bit integer and let 2k be the largest integer that the block can hold, then
2k <n should be true. The integer value that the plain text block represents has to be lesser
than n, otherwise the arithmetic is done (modulo n) which prevents the encryption/decryption
process from being unique.

Step 1: Find two primes p and q randomly, a few decimal digits apart (each of size at least
150 decimal digits). By randomly, we mean by the help of a pseudo random number
generator. If the output of the pseudo random number z is even, we check if z+1 is prime and
if not z+3 and so on. This can be done by a suitable primality test. According to the prime
number theorem, the frequency of numbers near z is (1/log z), so with O(z) tests we can find a
prime>=z.
Step 2: Compute n=p*q.

Step 3: Now choose a random integer e, (0<e<phi(n) ), such that e*d==1 mod phi(n) and
gcd(e, phi(n) )=1. We find d=e-1 mod phi(n) using the extended euclidean algorithm. Since
the inverse is unique, i.e. gcd(e, phi(n) )=1, we are certain that there is exactly one solution
between 0 and phi(n) that satisfies the above equation.
The public key is: (e,n).
The private key is: (d,n).

Step 4: Let M be the plain text and C be the cipher text.

Encryption
f(M) = C =Me mod n

Decryption
f -1(C) = M =Med mod n=Mk*phi(n)+1 = M.

Now, two cases arise
Case 1: If gcd(M,n)=1, then by the corollary of Euler’s theorem, Me*d==M mod n, since that
e*d==1 mod phi(n).

Case 2: If gcd(M,n)>1 and M< n=pq, then M=hp or M=lq (for arbitrary integers h and l).
We have, Mphi(q)==1 mod q (By Euler’s theorem)
Therefore, Mk*phi(p)*phi(q)==1 mod q.
or Mk*phi(n)==1 mod q.
or Mk*phi(n) =1+ cq, (for arbitrary integer c).
or Mk*phi(n)+1 =M(1+ cq) (On multiplying both sides by M)
or Mk*phi(n)+1 =M+ mcq
or Mk*phi(n)+1 =M+ (hp)cq
or Mk*phi(n)+1 =M+ hc(pq)
or Mk*phi(n)+1 =M+ hc(n)
or Mk*phi(n)+1 =M mod n, as required.

Thus, in both the cases, we have the correct decryption.

Note: RSA is susceptible to block replay attacks and a suitable chaining mode such as Cipher
Block Chain(CBC) may be used. All classical ciphers are vulnerable to the man in the middle
attack unless the legitimate communicating parties have a previously shared secret. It is
informative to go through [1] for a comprehensive list of attacks on RSA and [2] is an
excellent guide for writing practical algorithms. Both are easily available for download over
the internet.

An example of the RSA algorithm: We now look at an over simplified example for
illustrating the algorithm.
Let p=3 and q=11, be two randomly selected primes.
n=3*11=33
phi(n)=(3-1)*(11-1)=20

We choose randomly, e such that gcd(e,20)=1. Let e=7, gcd(20,7)=1. Thus there exists an
integer d such that 7*d==1 mod 20 or d=7-1 20,

gcd(20,7)
20=2.7+6
7=1.6+1
Therefore,
1=7-6
=7-(20-2.7)
= -(1).20 +(3).7
So, d=3.
Let the plain text M=2.
Then C=27 mod 33=29.
and M=293 mod 33=2, as desired