I've a web portal where user comes in and post his/her images. Now there's a contest running where people can pool in their photos and whoever has maximum likes on its image wins the contest.
So, the problem that I'm facing is one user can register as many accounts as he/she wants and like his/her own image. This will increase the number of likes on the image and the user will win, not legally but its a fraud.
So, is there any way in which I can restrict a only 1 signup from one computer. OR is there any other better way of handling this, even if I can minimize this behaviour it will be of good help.
One method I thought of is I can ask for user's phone number and can verify using an OTP. What cab be other ways of finding the fraud accounts?
Is there any way in which I can get the unique identity of the system(probably MAC address) in Django request variable via which I can allow only 1 user registration per system?
There's no foolproof way, but you can make it harder for fake users with the following steps:
Show a captcha to prevent automated sign-ups.
Track IP address when users sign-up and try to find patterns e.g. too many sign-ups from a single IP could signal fraud. It's also possible that the IP belongs to an organization and the users are genuine.
Check for suspicious IP addresses (e.g. those through VPN or cloud service providers e.g. AWS). You'll have to use a service that identifies VPN specific IP addresses. Also see : https://security.stackexchange.com/a/85416
If you want to get more technical, you could look at the highest liked photos and see if the users who liked it also liked other pictures. Look for tell tale signs. This could give you a pattern to distinguish fake & genuine likes.
Browser fingerprint
P.S. Phone number verification is also a good option since getting a disposable phone number usually isn't free. There are a few disposable free numbers that you could blacklist (search for free disposable phone number).
It is important to focus your effort on the problem. The problem that you want to solve is that people can like their own images to artificially increase their own score.
To be most effective, target the problem (multiple likes) instead of the side-issue (multiple registrations).
Here are some simple suggestions:
Prevent multiple likes from a single IP on a single image
Set a cookie when a like is given; if the cookie is set, do not accept more likes
Add a CAPTCHA. (This won't prevent multiple manual submissions, but will limit automated ones.)
There is nothing wrong with limiting registrations, but be sure to take steps first that address the core problem.
Related
I'd like to verify phone numbers of user accounts in my Rails 4 app (by simply sending them a four digit pin number which they'll need to enter back into the app) - which services are available and which ones are the least hassle to implement into a Rails app?
I'd like to verify both mobile and landline numbers internationally, though my main areas will be Europe, the US & Canada, Australia and New Zealand (I am based in the UK).
Your title lists three main SMS APIs, so for services available you already have a good understanding. But there are also APIs that focus exclusively on 2FA / Verification. Here is a list of some, worth noting that it tends to be focused on the user side of the equation (things like Google Authenticator).
Since you ask about ease of integration, a 2FA API (instead of an SMS API) may be far easier (you don't need to be concerned about generating a truly random OTP, or using voice fallback if the user does not respond to SMS, etc).
Nexmo (Disclaimer: I work there.) actually offers both SMS / Voice APIs, and a Verify API built on top of those lower level APIs.
With our Verify API (it's going to be similar regardless of the 2FA API) you'd make a call to https://api.nexmo.com/verify/json and pass along number and brand (to identify your app) parameters. The response will contain a request_id, and once the user provides your app with the code, you'll pass both the request_id and code to https://api.nexmo.com/verify/check/json.
So it's 2 simple API calls, and in the interim you associate the request_id with the user's session. Here's a quickstart on that process.
With Nexmo specifically, if enough time passes without the second API call, the code is sent again, this time with a voice call (or, if the number is a fixed line, just starts with voice).
With our SMS API (again, will be similar regardless of the API) first you'll generate a code - which may sound deceptively simple, if security is a concern you'll need to ensure that the generation is truly random.
Then you'll store the code and send an SMS. With Nexmo, that'd be a call to https://rest.nexmo.com/sms/json with the text of your message, the to and the from*. There's also security concern there because you're storing the code on the same server as it validating it. If that's compromised, the verification flow is as well.
Finally, you'll compare the user provided code to the code you stored.
So the least hassle really depends on you. Is it easier to make two API calls and avoid secure code generation / storage (and potentially get voice fallback for free)? Or DIY the code generation and reduce your integration to a single call to an SMS API?
Twilio developer evangelist here.
You absolutely can use Twilio (or any of those other services) to verify phone numbers. There is a good blog post here that explains the steps you can go through to perform a phone verification via SMS.
As you are looking to verify landline numbers too, you might need to add voice confirmation too, where you call a user up and read out the 4 digit passcode instead. That can be accomplished in a similar way, but by making an outgoing call to the phone number which reads out the individual code using Twilio's text to speech <Say> verb.
Let me know if this helps at all. I'm in the UK too, so do reach out if I can help further.
Good Afternoon,
I am hoping someone might be able to help me with a concept. I have a websocket server which pushes JSON messages out to users, I have coded in a number of admin functions for pushing broadcasts out to users, as well as disconnecting users if needed.
One of the things I would like to be able to do though is to come up with a 'near' foolproof way of 'banning' users from connecting to the server if required. This is where I am a bit lost, if I go the cookie route then it is possible that the cookies get cleared and it no longer works, I can't use the session ID either as once they disconnect they get a new session ID, and the IP address is also problematic as many would be on mobile dynamic connection.
Id appreciate any tips on how to best achieve a way of remembering the users so if I ban them, when they go to reconnect I can prevent them.
The server I am running is the supersocketserver whilst the client is HTML5.
Given your current constraints, there is no "foolproof" way to ban a person from accessing your web site.
For privacy reasons, there is no permanent way to identify a given browser. There are cookies, there are IP addresses, there are even some evil "perma-cookies" that attempt to store little pieces of identifying information in lots of places (such as flash cookies and other plug-in data) to try to make it difficult (but not impossible) for users to clear them. As you're already aware, IP addresses are not permanent and are not always tied to just one user either.
And, of course a user can certainly just use a different browser or computer or mobile device.
So, the usual way to control access is to require a user to create an account in your system before they can use your service. Then, if you want to ban a user, you ban that account. Since you will want to prevent the user from just creating a new account, you can collect other identifying information upon account registration. The more info you require and can verify, the harder it is for users to create more and more accounts. This gets to be quite a bit of work if you really want to make it difficult for users to create more accounts because you need to require pieces of identifying information that you can both verify and are hard for a rogue user to duplicate (credit cards, email addresses, home addresses, etc...). How far you go here and how much effort you put in is up to you on how much you want to keep a banned user out.
I am trying to prototype a system that will display a list of choices to a user, and allow them to place an order for the one they select (an over simplification of the prototype, but sufficient to get to the point). I have the users credit card number, billing and shipping addresses, and other contact information, but I can't find any web services that will let me actually purchase something with this information to complete the prototype. I have checked directories such as Programmable Web and Xmethods, but they just seem to point to APIs that let you check for prices and availability, but not actually place an order. Does such a thing exist, or is there some reason (such as security) that I am missing, that prevents such a service from being offered?
The most important thing about online shopping is the security of transmitted information (e.g. credit card data). So the ideal case is to transmit these information directly to the related bank's (issuer of the credit card) payment services, rather than passing it via other service providers. This is what 3-D Secure does.
So when you use a common API this means putting an extra broker between, and passing the secure information to this party which increases vulnerability. Since such a broker cannot use 3-D secure (since it is not the merchant so not possible to make an agreement with the banks) and it should pass the information to online shopping site.
Moreover, an online shoping site can block traffic coming from such an intermediary webservice at any time if you do not make an obligatory agreement and making agreements for each online merchant is practically not very possible.
There is no such free API available the simple reason behind that information like credit card is very secure and confidential and there will security threat on free API's.
here is list of best 10 online payment system
http://sixrevisions.com/tools/online-payment-systems/
and this one who providing live demo
http://www.fastcharge.com/
I think it is possible though I don't know in depth information. I think this is what you see. In next steps you will be redirected to payment gateway of the bank and then you can complete the transactions just by answering some security questions. I think this is a service you should obtain from the bank. And I haven't seen any universal API that can perform the task you have mentioned.
Dialog GSM - Sri Lanka
Anything.lk - Sri Lanka
I'm looking for a United States Address Validation web service, as the title says. Also:
I don't need maps
I don't need Geo coding
I do need:
Validation that an address is real
Address parsing
Google's Maps / Bing Maps seemed good, but won't work for me because of these:
Prohibits use if not plotting points on a map image
Low request limits (100,000 / day) for premium account. I need more like 1,000,000 / day
Does Geocoding, which I don't need, which is resource intensive, which means it's slow
Any suggestions?
Maybe USPS?
https://www.usps.com/business/address-management-products.htm
use FedEx's API. They have an API to validate addresses.
Also:
https://webgis.usc.edu/Services/AddressValidation/Default.aspx
You can try Pitney Bowes “IdentifyAddress” Api available at - https://identify.pitneybowes.com/
The service analyses and compares the input addresses against the known address databases around the world to output a standardized detail. It corrects addresses, adds missing postal information and formats it using the format preferred by the applicable postal authority. I also uses additional address databases so it can provide enhanced detail, including address quality, type of address, transliteration (such as from Chinese Kanji to Latin characters) and whether an address is validated to the premise/house number, street, or city level of reference information.
You will find a lot of samples and sdk available on the site and i found it extremely easy to integrate.
You could, in theory, run desktop software and plug into any kind of API it provides, but then you become responsible for things like uptime, data updates, and associated overhead. You may also run into issues with the software threading model--is it multi-threaded or single-threaded software? You don't want to find that out in production.
There are a handful of web services out there that can verify US-based addresses, including the USPS official web service. The USPS one is very limited in the fields that it returns. For example, if you're looking for the "delivery point" which is used to make a full barcode, the USPS API doesn't return that information. I believe the USPS web service also limits the number of queries that you can perform, although I don't remember the exact limit.
A few things that you'll want to look for in a web service include the price (obviously) as well as geo-distribution of their servers. If a company has all of their servers in one location and that data center goes offline (which can and does happen), you're left out in the cold. If they have multiple physical locations, it can help to prevent unnecessary outages. Also, you'll want to make sure that the service call returns all necessary fields as per your requirements--like delivery point code, barcode, and DPV code (which tells you how deliverable an address is).
Lastly, you'll want to determine how you feel about interacting with the company. When you call them on the phone, are they responsive and concerned about your needs? Or are you talking to some front-line person that can't answer questions and is only able to gather information about your company size and revenue so they can evaluate how big of a fish you are and determine which salesman gets to call you back. Can you talk to the engineers that wrote the web service on the phone or via email?
There are a few choices out there and you'll have to choose the one that best fits your requirements and unique situation. Do a Google search to find a list of companies. In the interest of full disclosure, I'm the co-founder of SmartyStreets. We have an address verification web service API called LiveAddress. You're more than welcome to contact me directly with questions on my personal Twitter account or the company Twitter account.
I'm creating a website and I don't want to have user/membership.
However, people using the site can do things like vote and flag questionable content. Is the only way to identify and prevent users from doing this repeatedly by using cookies?
I realize a user can just clear their cookies but I can't think of another way.
Suggestions for this scenario?
Well you could map a cookie + ip-adress in a datarecord in your database. To identify the user. So if the ip exists in the database, you simply just add the cookie, but check the cookie first to avoid unessesary database calls.
This is not optimal though, since schools etc might have the same ips on a lot of computers.
You can always just adapt openid!
Marko & Visage are correct,
Just to add though, you might want to store each vote with the timestamp,IP, etc... so at least if someone does try to "game" your site, you'd be able to rollback sets of votes made from the same location or within a very short amount of time (i.e. from a bot)
+1 To all that others have already said. Here's another middle-way idea:
Use cookies as primary means of limiting voting. If a cookie is not found, check the IP address. Allow no more than, say, 1 vote per 5 minutes from the same IP.
Cookies are not enough, as you said it could be cleared/expired.
IP address tracking is also not an option because of DHCP and firewalls.
The only thing that is ~100% sure is users, but then again, one person can register multiple accounts.
I'll go with cookies, as the simplest ant least obtrusive way. If someone really wants to play the system, he will find a way whatever you try to prevent it.
Even with membership a user can register multiple times and vote.
Cookies are one way to handle this but people who know that they can delete cookie can vote again.
You can catch the IP of the voter and restrict based on that. But many people will have same IP.
Sadly there is no other way.
Yes, you are right.
HTTP is stateless, so there is no way of determining if the origin of a request you receive now is the same or different to the origin of a request you received, say, 5 minutes ago.
Cookies are the only way around this. Even server side sessions rely on cookies to maintain session identity across requests (ignoring the security nightmare of passing the sesison ID in the URL, which anyone with malicious intent can sidestep trivially).
There will always be people gaming the system if it suits them. Moreover, if you make it such that you don't need cookies at all you'd be open to very simple attacks.
I think you'll want to consider ways to increase the economic cost of users operating under a cloud of suspicion.
For example, if a user with the same cookie tries to re-submit the vote, that can obviously be stopped easily.
If a user with a different cookie but from the same IP does the same thing, it could be coming from a proxy/firewall so you may want to be cautious and force them to do something extra, like a simple CAPTCHA. Once they've done this, if they behave properly nothing new is required as long as their new cookie stays with them.
This implies that people without cookies can still participate, but they have to re-enter the letter sequence or whatever each time. A hassle, but they're likely used to sites not working without cookies. They'd be able to make an exception if required.
You really won't be able to deal with users sitting over a pool of IPs (real or otherwise) and exploiting new and dynamic attack vectors on your site. In that case, their economic investment will be more than yours and, frankly, you'll lose. At that point, you're just competing to maintain the rules of your system. That's when you should explore requiring signup/email/mobile/SMS confirmation to up the ante.
You can add GET variables and URL parts to serve as cookies - some sites do that to allow logins and/or tracking when cookies are disabled. Generate the part using source IP and user agent string, for example.
site.com/vote?cookie=123456
site.com/vote/cookie123456