Looking at these docs, I see a valid property in the return. I've been struggling to find answers on what exactly this means. The docs say
Boolean which indicates if the phone number is in a valid range that can be freely assigned by a carrier to a user.
Likely helpful context: we're looking to enhance our validation by:
Ensuring a phone number is actually registered to a human and active.
Ensuring the area code and first 3 digits are actually possible combinations.
Ensuring duplications/known fakes aren't passed in. Ex: 555-5555
In this case, the valid property satisfies your 2nd and 3rd needs. A valid phone number is one that a carrier could assign to a user, but doesn't necessarily have to be assigned. This does mean that the area code and following number are possible, and that fake numbers are not possible.
To verify the number is real and belongs to a user, the best thing to do is to verify by sending it a message or calling it and verifying a given code.
Related
maybe some of you know Googles 2-Factor-Authentication; first Google generates a constant password (eg. "abcd").
If you login, you're asked for a pin, an app can generate that or you can use one of 10 preset pins. The interesting part is, that you don't have to use one pin, the app generates a random one without using network access.
How is that done? I know how to do it with one specific pin, but how could you use several "random" pins?
Thanks,
Marc
This is made possible by systems like HOTP (hash-based OTP). The RFC explains how it works in detail, but in short:
The server generates a random secret key and shares it with the OTP generator.
Both server and OTP generator initialize a counter to 0.
When the user requests a new key from the OTP generator, it increments the counter, calculates the HMAC of it using the shared key, and encodes part of the hash in a specified way, resulting in a numeric code.
When the server receives an OTP code, it performs the same calculation, accepting it if it matches. If it does not, it tries again with several other (larger) counter IDs in case the user skipped one or more IDs.
Pre-generated lists of OTPs are simply produced as described above, ahead of time.
I believe that Google does it by computing multiple pins that it thinks you could use, and is willing to accept any of these that match.
This is an important usability feature, because it means that if someone fails to login once using 2-factor, they can try to login another time and still be OK.
Quick question that I can't find an answer to...
How do you find what the number of the phone running Windows Phone 7 is?
For example, in the UK the number would start with 447*. I need this information to send to our server so it can send the user a text message when something has happened.
As far as I know, phone number is not available via the API.
Do you mean the phone's actual number or the country code? +44 is the UK international code. If you mean the phone number, I don't think this is possible. In Mango, you can get the Mobile Operator. Mobile operators tend to have their own first few digits, so you could store a table of those and check it against the operator returned. It may not be wholly accurate, but might be useful if you can get a list of numbers of prefix major operators.
It is not available with the API, nor any private methods.
This is also not in the Mango release as far as I am aware.
Its not available directly; but if you definitely need the phone number and you are providing a useful service that the user is interested in, then just ask the user to provide their phone number.
You can validate if the user has entered the number along with country code by looking at the location and determining the country code from a lookup table/ web service.
I am trying to create a unique CD-KEY to put in our product's box, just like a normal CD-KEY found in standard software boxes that users use to register the product.
However we are not selling software, we are selling DNA collection kit for criminal and medical purposes. Users will receive a saliva collection kit by mail with the CD-KEY on it and they will use that CD-KEY to create an account on our website and get their results. The results from the test will be linked to the CD-KEY. This is the only way that we will have to link the results to the patients. It is therefore important that it does not fail :)
One of the requirements would be that the list of CD-KEYs must be sufficiently "spread" apart so that there is no possibility of someone entering an incorrect CD-KEY and still having it approved for someone else kit, thereby mixing up two kits. That could cost us thousands of dollars in liability.
For example, it cannot be a incremental sequence of numbers such as
00001
00002
00003
...
The reason is that if someone receives the kit 00002, but registers it as 000003 by accident, then his results will be matched to someone else. So it must be like credit card numbers... Unless a valid sequence is entered, your chances of randomly hitting a valid number is 1 in a million...
Also, we are selling over 50,000 kits annually to various providers (who will generate their own CD-KEYS using our algorithm) so we cannot maintain a list of all previously issued CD-KEYS to check for duplicate. The algorithm must generate unique CD-KEYs.
We also require the ability to verify that the CD-KEY is valid using a quick check algorithm, so that we can inform the user if the code he enters is invalid. This leaves out many hashing or MD5 algorithms I believe. And it cannot be a 128 bit because, who would take that time to type it out on the computer screen?
So far this is what I was thinking the final CD-KEY structure would look like
(4 char product code) - (4 char reseller code) - (12 char unique, verifiable CD-KEY)
Ex. 384A - GTLD - {4565 - FR54 - EDF3}
To insure the uniqueness of the KEYS, I could include the current date (20090521) as part of the source. We wont generate unique keys more than once a week, so this value changes often enough for the purpose of unique initial value.
What possible algorithm can I use to generate the unique keys?
Create the strings <providername>000001, <providername>000002, etc. or whatever and encrypt them with a public key, and that's your "CD-KEY" that the user enters. Decrypt the CD-KEY with the private key and validate that when decrypted you get a valid string with a valid provider name.
Credit Card numbers use the Luhn algorithm you might want to look at something similar to that.
I use SeriousBit Ellipter link for software protection but I don't see any reason you could generate a group of unique keys each week and us the library to verify the key validity when entered into your web site. You can also encode optional services into the key allow you to control how the sample is processed from the key (that's if you have different service levels).
As it uses an encrypted method of key generation in the first place and it's relatively cheap, it's certainly worth a look I would say.
I finally settled for a cd-key of this form
<TIMESTAMP>-<incremented number>-<8 char MD5 hash>-<checksumdigit>
I used the mod 11 ISBN checksum digit algorithm.
Generate GUID and catenate a random number to it. GUID is guaranteed to be unique and random number will make it improbable to hit a code accidentally. Just don't modify the GUID in any way or you might compromise the uniqueness.
http://msdn.microsoft.com/en-us/library/aa475087.aspx
If you read this thread before - forget everything I wrote, I must have been drunk when I wrote it. I'm starting over:
I'm currently working on a project where we will be using some sort of algorithm for validating user input. There are three parties to consider;
Client - Browsing our web pages
Company - We, handling the Client requests
3rd Party Company - Handling Client messages
On our web pages we will show the Client some information about a product. If he/she wants more information about the product he has to contact the 3rd Party Company and state the products code (not unique per se, but not common either). In return the Client will receive some other code from the 3rd Party Company which he should input on our web page, where we will validate the code for approval.
The best would be if we, the Company, had no interaction with the 3rd Party Company. Pure encryption is out of the picture because it generates a string that is too long. We are doing this by SMS, so the codes has to be short.
What I've come up with so far:
For every product I generate a somewhat unique code (it doesn't matter if it's unique or not really) in base 16 (0-f). The Client who wants more info about the product sends a SMS to the 3rd Party Company stating the products code. In return the Client receives the same code, but the digits are multiplied (possibly by 2) and converted to base 36. On top of that a last character is added to the code, a control number, to make the code valid for the Luhn algorithm in base 36. The user enters the received code and we, the Company, validate it on the server side against the product code (validate against Luhn, divide by 2 and switch back to base 16).
Does this sound reasonably safe and appropriate? Is it a valid way to send messages by three parties, when two of them shouldn't need to communicate?
Sorry for the edit, but my mind must have been elsewhere when I wrote the first post.
I think you are confusing things, if you use the Luhn algorithm, for example, it'll just return True or False on the checksum. The sample code you gave seems to indicate that you want to have some checksum result (ex. 12345) that can be hashed from two different values. This problem would be more difficult.
How will the third party create this value? Will you give them some Javascript code for them to execute, or some other language? Couldn't you have a shared secret key and they could symmetrically encrypt the value with that secret key, you could have them prefix the part they encrypt with some known value so you could verify it quickly.
Their code:
to_send = encrypted(shared_key, 'check' + code)
Your code:
unencrypted = decrypt(shared_key, to_send)
if not unencrypted.startswith('check'):
return False # failed check
OK, so you want no interaction between the other application and your application. And you would like to limit the codes to 6 characters. Here are my thoughts:
Use 10 characters, that will make brute-force attacks harder;
Use all Latin letters and digits - that will give you 36 possible character values;
Why not use some big number library and simply multiply your code (taken as a Base36 number) by some ludicrously large value (say, 2048 random bits). Then convert it to Base36 and take the last 10 digits. Or maybe first 5 and last 5. Or maybe some other combination dependant on the original code. I've no idea how cryptographically strong this will be (probably not much), but the effort to crack the code will doubtfuly be smaller than simply paying for the service.
Alternatively you could salt (prepend some secret string) your code and then calculate MD5 of it. Return the MD5 (or some N characters of it) to the user as your code. This should be pretty cryptographically OK, although I'm no expert. By converting the MD5 result to Base36 you could increase the strength of this algorithm.
Why a "checksum"? Can't the 3rd party run any little utility that you give them? All you need is a 5-digit encryptor that the 3rd party can run on their computer, feed the product code into, and send the 5-digit result to the client as the key code.
The encryptor always produces the same result from the same input.
Then, the client sends you the product code and the key code. You run the product code through an exact copy of that encryptor, and compare that result to the key code.
The security of this system can be enhanced without changing the fundamental architecture.
-Al.
Edit after some clarifications:
I still think that the product code and the matching 3rd party response cannot be constant - otherwise it can be shared will other users, which will thus be able to give the response code without going to the 3rd party.
If the product code is constant, a possible approach is that the 3rd party response depends on both the code and the user's phone number, and so is your validation. This way, each response is both product and user specific.
The specific permutation of the Luhn algorithm isn't too important in my opinion - if someone can crack one variation, he'll probably be able to crack another one.
Original Answer:
In short, I think you can use the Luhn algorithm, if you give the user a one-time ticket, valid for a limited amount of time.
First, if I understand the problem correctly, your product code cannot be constant - otherwise the response created by the 3rd party will always be the same for this product. This means the user will be able to use this code again later, or even give it to another user.
Therefore, I think you should generate and give the user a random new code per his request of information/access to the product. This code should be valid for this product for a limited period of time (an hour, a day, depending on your needs).
The response sent by the 3rd party to the user should be valid only when entered together with the code you provided to the user.
After validation, this code cannot be used until the specified time period is over.
As an option, I think you and the 3rd party can append something like the current date to the code and response pair during computation, so they are not always the same pair.
After long debates with the 3 Party Company we've concluded that the best solution will be if they pass the Clients SMS to me, I generate a new code and send it back to them which in their turn send a new SMS to the Client with the code I generated. Not optimal from my point of view, but at least I can now do it in any way I want.
Thanks for your input thou.
I guess this is a multi-part question. I am building a membership site and want to have the accounts as international as possible.
What is the best way to collect phone numbers on a form that allows for international numbers? I'm not worried about storing them, just collection and validation. What I have now is a drop down with a country list that will add the country code, and then the number itself with validation for us/can/uk based on the country code, and then the extension. These will be stored as strings in 3 fields for cc/number/ext Does anyone have a better, solid solution for this, or perhaps seen one in action anywhere?
Ditto for addresses. What is the best way to go? Address/City/State/Zip/Country or just lines? I would like to be able to sort by these, so a single text field isn't a very good solution, though it is the most flexible.
This is also important because we may be sending actual mail to our members. I am put in mind of a few members I've had for other services that had addresses in countries I had never heard of, that even the woman at the post office couldn't tell if they were formatted correctly.
I want to have geodata in the db, at least country/state, for things like populating a state dropdown after selecting a country, field standardization, etc. Does anyone know of a great database that can be used as the geodata base of an app?
Phone number validation - I'm not sure if I'd spend a lot of time on this. Numbering schemes change quite often (for example, during the time I lived in the UK, the phone numbers for London area codes changed at least once, with another change shortly before I moved there) and in Germany it is (or at least used to be) quite common to increase the number of available phone numbers on a given exchange by taking an old number and tacking an extra digit or two at the end. So any assumption about a given phone number format will change and you'll end up playing catch-up. If you insist on splitting the phone number into international/area code/main number you'll probably find that this is a very country-specific way of representing the information so you'll need an input mask pretty much for every country and specific validation rules. Not to mention that in places like Germany, an area code can have between two and four digits etc...
Regarding postal addresses, the most important suggestion I have is to ensure that you can accept non-numeric post/zip codes, otherwise you won't be able to handle addresses in Canada and the UK (and possibly other places). This is a bit of a hobby horse of mine as I've had a few issues with websites in other countries that simply refused to let me put in a non-numeric post code and I had to resort to faxing over my address information as I couldn't fill in the online application form. In my book that's bad karma if you allow international customers....
Also, assuming the existence of certain parts of the address (state/county, for example) and requiring them is usually more of a headache than it's worth. I'd be tempted to offer the standard house number + street (combine them, different languages put the house number in different places so separating them out is not a good idea IMHO unless you know how to reassemble them correctly, plus sometimes you'll end up with a house name instead of a number), town and zip/post code, possibly with an optional county/state field. If you want to be really helpful to you international audience, offer a free-form, single text entry field for those addresses that don't conform to our "standard" assumptions of how an address looks. And please make them big enough so people with quite long addresses don't run out of space...
There is an international standard for telephone numbers, but it leaves a lot of breathing room. Separators are not mandatory, but are restricted to space, period, and hyphen. Round brackets (aka parentheses) are to be put around digits which are optional depending on where you are dialling from. For example, the area code is optional in some areas. I would provide a text field and let the user enter their number however they want.
For addresses, provide lots of fields and don't restrict too much. House numbers sometimes contain letters. Road types are sometimes written in full, and other times abbreviated. (St = Street, Ave = Avenue, etc.) I would provide drop-downs where possible (state/province), but allow freeform input when you don't have a list. When the user is entering their address, it's ok to validate for security risks, but you might want to leave geographical validation until later. For example, if the user enters a postal code of T8N 4E3 and selects Ontario as their province, the address is not valid because the given postal code is for Alberta. Display a friendly message to the user letting them know that they need to correct their address or contact you if it's correct (possible bug in your code).
Address - just remember not everywhere you got states and ZIP codes. and if you got ZIP codes they can be in diffrent format ([0-9]{2}-[0-9]{3} here). (edit: usually postal address with 2 address lines, city, state (optional), zip code (optional) and country is ok).
So is with geodata - you can make sequential dropdowns with states and cities but guess you won't cover every city. Why not show a piece of google maps and allow the users to click there to mark their position?