I have card numbers in format like 123456xxxxxx7890. How can i test if it's regular card or any other service like ApplePay/GooglePay/etc?
Just boolean answer yes/no is more than enough for my needs. Is there any logic? Or database?
I've tried to look up at binlist.net service but it doesn't detect it unfortunately (shows wrong banks for 10 card IINs that i have).
we will never know if the card is regular card or applepay /google pay card
applepay/gpay generates a unique card number for each original card and we cannot obtain the original card details from it
According to the iBeacon spec, iBeacons have to broadcast 0x004C as the company ID in the advertisement's manufacturer data. 0x004c is Apple's company ID as assigned by the Bluetooth SIG.
I'm confused by this because other than the company ID, there doesn't seem to be any other data that definitively identifies a BLE device as an iBeacon. The next two bytes fixed to 0x02 and 0x15 and the rest is configuration dependent.
At one point I figured that if the first four bytes of the mfg data are 0x4c 0x00 0x02 0x15, then it is an iBeacon. Then, I found iBeacons that used other company ID's. I have Nordic Semiconductor iBeacon samples, for example, that use 0x59 0x00, which is Nordic's company ID.
Even if I look to make sure the 0x02 and 0x15 are where they are, and that the device is unconnectable, and the mfg data is the exact length, this doesn't seem to be definitive.
How to definitively identify an iBeacon?
You can see the byte sequence of an iBeacon transmission in my answer here.
The bottom line is that the exact header (including the company code) must be as specified for iOS to interpret an advertisement as an iBeacon transmission and to return the results using iOS CoreLocation APIs. If a different company code is used, it will simply not be detected by these APIs. Even though different companies manufacture beacons meeting the iBeacon specification, the all use the Apple company code.
The fact that some chip manufacturers give example code using different company identifiers (e.g. Nordic Semiconductor 0x59 0x00) may just be a way of getting around intellectual property restrictions. Apple insists that those who market their products as iBeacon compatible sign an agreement saying they will not disclose the specification. Nordic may be attempting to comply with this agreement by changing the company identifier in its sample code. Regardless of the reason, the fact remains that iOS devices will not interpret such a transmission as an iBeacon packet with an unexpected company code.
Since there is no standard defining a "beacon", different manufacturers have their own advertisement formats. Therefore you will have to make up a list of advertisement patterns you want to snap up. Each company defines what their data means so just looking at the first 2 bytes in the manufacturer data does not work since some company might use the prefix 0x02, 0x15 for something else.
You can download the iBeacon specification here (requires accepting licence agreement).
The specification states that the Company ID:
Must not be used for any purposes not specified by Apple.
Using these 2 bytes for their intended purpose of identifying the manufacturer is acceptable. Using these 2 bytes to broadcast additional information would probably fall outside of the licence agreement.
The information contained in the spec should be enough to help you. If you see a length of 0x1A, and 0x02, 0x15 in their respective places, it is most likely an iBeacon packet.
So I'm trying to write a small applet which reads a serial number from a smart card using the javax.smartcardio library. Smartcard is connected with bit4id reader, and right now I successfully connect to the smartcard and read basic infos such as ATR and protocol (T=1).
I did some research about it (for example: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#table9)
But I'm not getting which specific list of command APDUs should I send to the card to get that serial.
Is there an "easy way" to do that, without reading tons of papers and manuals?
I guess I would need some datasheets to know how data is stored inside the card, right? or can i send some kind of command APDUs to retrieve this info from the card too?
Right now I only receive SW=6986 responses (not valid command)
Any advises, even only on the workflow, would be strongly appreciated!
There is no one way to read a smart cards serial number. "smartcard" is an ISO/IEC standard defined in the 7816 specification. Many industries use this standard like Mobile SIM, Bank Cards and Digital Signature Cards.
The implementation of the standard is different across industry with some industries advancing this basic standard with there own additional APDUs etc. like 3GPP/GSMA standard in the Mobile SIM case or the EMV standard in banking.
Anyhow, assuming that this card is smart-card ISO/IEC 7816 compliant you could possibly assume that it uses file base storage for card data. You could use the "SELECT" command (defined in 7816-4) to try to access all available files and print there information. i.e. files are identified by two bytes like 3F00 you could select from 0000,0001,0002....FFFF then if you get a successful select (status word 90) then read the contents and print it. Doing this you may be able to identify which file has the "serial" then you would only need to read this file going forward.
The above is not "easy" but may be a nice challenge and learning experience.
I was wondering is there a particular organisation you have to contact with regards to reserving a manufacturer ID for a bluetooth beacon? For instance, if we wanted to start mass producing them, ensuring no one else uses a particular ID?
Any advice would be appreciated.
Why yes there is. You must be member of the Bluetooth SIG. See here for more information and a list of current Manufacturer IDs.
As an addition to the previous answer regarding Bluetooth SIG and Company ID,
I will add a few things:
Company IDs are assigned by the Bluetooth SIG. In order to get one, your company must first become a member of the Bluetooth SIG. The entry level membership (adopter level) is free.
Once you are an adopter member, you can submit a request to get a Company ID (also free).
The company ID is necessary if you want to use the Manufacturer specific data field in order for example to have custom data in the BLE advertisement frames.
If you plan an building a 'simple' beacon product following, you might not need a Company ID. For Apple's iBeacon format for example, the frame format should use the Apple's company ID as well as their beacon format (see for example this page explaining the ibeacon format : http://www.warski.org/blog/2014/01/how-ibeacons-work/). I belive the Google Eddystone beacon format also do not require beacon manufacturer to have their own company ID.
Possible Duplicates:
Best practices for taking and storing credit card information with PHP
Storing credit card details
Storing Credit Card Information
I need to store credit card numbers within an e-commerce site. I don't intend on storing the whole credit card number, as this would be highly risky. I would like to store at least the first five digits so I can later identify the financial institution that issued the card. Ideally, I would like to store as much of the credit number as I safely can, to aid any future cross-referencing etc.
How many digits, and which particular digits, can I safely store?
For example, I imagine this would not be safe enough:
5555 5555 555* 4444
Because you could calculate the missing digit.
Similarly, this would be safe, but not be as useful:
5555 5*** **** ****
Is there a well accepted pattern for storing partial credit numbers?
The Payment Card Data Security Standard states that if you are handling cardholder data, then you are subject to the constraints of the PCI DSS (which is very comprehensive and a challenge to comply with). If you want to store part of a card number, and don't want to have to deal with the Standard, then you need to make sure that a) you store NO MORE THAN the first 6 and last 4 digits; b) you don't ever store, process or transmit more than this. That means that the truncation has to be carried out before the data enters your control.
Given that you are talking about an ecommerce site, I think you'll have to deal with the PCI DSS sooner or later (since if you're not taking full PANs, you can't process transactions). Realistically, then, you should avoid storing more than the first 6 and last 4 digits of a PAN; the Standard then does not 'care' about this data, and you can store it in whatever form you see fit. If you store, say, the first 7 digits, then Requirement 3 of the Standard kicks in (and you start having to really understand key management in encryption).
I hope that this is of use.
March 2013 Edit:
A very pertinent resource is the PCI Security Standards Council, an organisation founded in 2006 by five of the biggest global Credit Card brands (AmEx, Visa, MasterCard, JCB International and Discovery) and which is the de facto authority on Security matters for the Payment Card Industry (PCI).
This organization publishes in particular the PCI Data Security Standard, currently in its version 2.0 edition which covers issues such as the management of complete or partial credit card numbers. This document if freely available but requires a simple registration and acknowledgment of license terms.
The following is the original, c. 2009 answer, mostly correct but apocryphal.
A common practice (whether legal or not I do not know) is to store the last 4 digits, as this may be used to help the customer confirm which of his/her credit cards were used for a particular transaction.
Without significantly improving the odds of a malicious person guessing the complete number, one can store the first 4 digits which are representative of the financial institution which issued the card, as mentioned in the question.
Do NOT, save many more digits than these 8 digits because otherwise, given the LUHN-10 checksum, you may provide enough info to make guessing the complete number more plausible (if still relatively hard, even with insight from the series used by a given issuer, in a given time period, but one should be careful...)
To make this whole thing safer, technically and legally, you may consider only storing such info if the customer explicitly allows it. You should also consider masking this info with a simple hash for storing in the database.
Also, what you can / should store following a particular transaction, is the transaction ID supplied by the Credit Card Processor, at the time the transacton is submitted. This ID is the key that allows locating most (all?) of the info you would even need, would there be any issue with a particular transaction. This type of info can typically be queried from a secure web site maintained by the Processing company, along with some aggregate reports which may include a grouping by card-type (Amex, Visa...) if that is why you are thinking of storing the first four.
If you don't need to store the whole credit card number, why do you need to store it at all? If you want to save the financial institution that issued the card, why don't you store the financial institution that issued the card?
Your specific question is answered in sec 3.3 of the PCI/DSS document.
First six and last four are max for display. Customer (paper?) receipts are more restrictive. Those with a legitimiate need to know can see full card data.
My recommendation is to contact your merchant provider and see what options are available to you. A number of the modern transaction gateways have "vault" features where sensitive information is stored at the provider and you simply reference customers by a token number when you want to bill them or check account information.
Along the same lines use of transaction specific tokens can be used to reference needed data stored on the providers system.
However I can't stress enough the importance of reading and understanding PCI DSS. Simply punting secure storage does not magically obsolve you from being subject to PCI compliance requirements!! This is only possible when your system never touches full card data.
The accepted pattern is don't store them at all.
In certain jurisdictions you may be breaking the law by storing them or any part of them.
You could instead, store a one-way (and therefore unrecoverable) hash of the credit card number.
The credit card companies have a standard for this. You'll probably find it buried somewhere in the terms of service of your payment processor that you will obey this standard. It answers you questions. You can find the standard here
Here in Canada, the usual way is to store the first 4 digit ( to identify the financial institution) and the 4 last digit to identify the credit card.
But be sure that you didn't break any laws.