If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
Related
ASP.Net Core has protection against brute force guessing of passwords, by locking the account after a fixed number of login attempts.
But is there some protection against credential stuffing, where the attacker tries a lot of logins, but always with different usernames? Locking the account would not help, since the account changes on every attempt.
But maybe there is a way to lock an IP against multiple login-attempts or some other good idea to prevent credential stuffing?
I'd recommend using velocity checks with redis, this is basically just throttling certain IPs. Also some fraudsters will also rotate IPs, you could also detect when logins are happening more frequently (say 10x the norm) and start to block all logins for that short window. I wrote a blog post detailing some of the above. The code is all in node, but I did give some high level examples of how we stop fraud at Precognitive (my current gig). I will continue to build upon the code over the next couple of months as I post more in my Account Takeover series.
https://medium.com/precognitive/a-naive-demo-on-how-to-stop-credential-stuffing-attacks-2c8b8111286a
IP throttling is a good first step, but unfortunately it won't block a large number of modern credential stuffing attacks. Tactics for savvy credential stuffers have evolved over the past few years to become more and more complex.
To be really effective at blocking credential stuffing, you need to be looking at more than IP. Attackers will rotate IP and User-Agent, and they'll also spoof the User-Agent value. An effective defense strategy identifies and blocks attacks based on real-time analysis of out-of-norm IP and User-Agent activity, plus additional components to enhance specificity (such as browser-based or mobile-app-based fingerprinting).
I wrote a blog post looking at two credential stuffing attacks in 2020, which I call Attack A (low-complexity) and Attack B (high-complexity).
Attack A, the low-complexity example, had the following characteristics:
~150,000 login attempts
1 distinct User-Agent (a widely used version of Chrome)
~1,500 distinct IP addresses (85% from the USA, where most of the app users reside)
Attack B, the high-complexity example, had the following characteristics:
~60,000 login attempts
~20,000 distinct User-Agents
~5,000 distinct IP addresses(>95% from USA, >99% from USA & Canada)
You can see that with Attack A, there were about 100 login attempts per IP address. IP rate-limiting may be effective here, depending on the limit.
However, with Attack B, there were only 12 login attempts per IP address. It would be really hard to argue that IP rate-limiting would be effective for this scenario.
Here's my post with more in-depth data: https://blog.castle.io/how-effective-is-castle-against-credential-stuffing/
Full disclosure: I work for Castle and we offer an API-based product to guard against credential stuffing.
Let's say I have a table of food items to bring to a lunch on a very simple web page. I don't want there to be login, but I would like there to be some smartness to my app.
Let's say a user puts in a food item. Other than a login, couldn't I use the IP address to do things like: only the user that created the record at same IP address can edit this record. Something like that.
I was thinking one more step toward a login, have a single text box where a user can put initials.
This way first person to suggest bring an item can be happy to know their todo for the lunch is done and can't be "overwritten"
That's it!
Pros and cons, welcomed!
This is more of a helper app than a formal thing, like to help around the office of local users.
Authentication and Authorization are separate functions, and I'm drawing the distinction here for a reason.
Authentication is the process of positively identifying a user, so you know who they are.
Authorization is the process of allowing or preventing that user from accessing parts of the application.
IP addresses can be used to partially identify users, but as #Dai pointed out in his comment, it has problems. Even using a Mac address is problematic since some people know how to spoof Mac addresses. If you can use someone else's authentication service, you can authorize them yourself.
Once you have positively identified a user, you can track them using a randomly generated ID that is good for a session. It is possible to use a cookie to track that ID. If that ID is associated with a Role you can authorize based on that role.
I created a webapplication with no registration required and I need to reasonably limit user's actions such as adding a comment or voting.
I wanted to do it simply by identifying users with their IP addresses, however I learned that these can be easily spoofed. Moreover, sometimes there can be a number of users behind one IP address. Additionally, I did not find 100% reliable way to determine user's IP.
How can one deal with this problem? Are there any other ways to set limits per user? Or maybe IP addresses are "good enough"? If yes, what is the best way to determine it?
Assuming you have registered your device with Google 2-step Verification, what information does it use to verify that you are on that device when you come back to the website?
Does it store something on your computer (like a cookie), or does it use some other algorithm to determine where you are logging in from?
It stores various bits of information about your conversation with the server. SSL cookies, session data such as your IP address and other information about your browser. As you change this information, a risk assessment value is increased as deviation from the originally known values changes. Once this value reaches a certain threshold, based on your country's online risk profile, that sets off a chain of events that invalidates your session.
When your session is invalidated, you need to log-in again.
It's more complicated than a cookie, but it involves cookies too.
There is a lot of debate in the security community as to whether it matters to add protection beyond endpoint and cookie verification and when it becomes a nuisance to the end user.
Just a quick follow-up on this question. A lot of people continue to view this question, but surprisingly, there hasn't been a good answer posted.
Since the original post, I did a lot of research to find out what technologies are used to determine a unique device, and I finally stumbled across the panopticlick project.
This website answered a lot of questions because it showed the exact metrics that a website can use to fingerprint your browser. Using this methodology, a site can really narrow down the exact device that you use to connect to a service, and therefore make it much easier to validate a 2-step verification.
Hopefully this helps someone trying to implement 2-step on your site.
We are in the early design stages of a major rewrite of our product. Right now our customers are mostly businesses. We manage accounts. User names for an account are each on their own namespace but it means that we can't move assets between servers.
We want to move to a single namespace. But that brings the problem of unique user names.
So what's the best idea?
Email address (w/verification) ?
Unique alpha-numeric string ("johnsmith9234")?
Should we look at OpenID?
EMAIL ADDRESS
Rational
Users don't change emails very often
Removes the step of asking for username and email address, which you'll need anyway
Users don't often forget their email address (see number one)
Email will be unique unless the user already registered for the site, in which case forward them to a forgot your password screen
Almost everyone is using email as the primary login for access to a website, this means the rate of adoption shouldn't be affected by the fact that you're asking for an email address
Update
After registration, be sure to ask the user to create some kind of username, don't litter a public site with their email address! Also, another benefit of using an email address as a login: you won't need any other information (like password / password confirm), just send them a temp password through the mail, or forgo passwords altogether and send them a one-use URL to their email address every time they'd like to login (see: mugshot.org)
OpenID is very slick, and something you should seriously consider as it basically removes the requirement to save local usernames and passwords and worry about authentication.
A lot of sites nowadays are using both OpenID and their own, giving users the option.
If you do decide to roll your own, I'd recommend using the email address. Be careful, though, if you are creating something that groups users by an account (say, a company that has several users). In this case, the email address might be used more than once (if they do work for more than one company, for example), and you should allow that.
HTH!
I like OpenID, but I'd still go with the email address, unless your user community is very technically savvy. It's still much easier for most people to understand and remember.
If you use an email address for ID, don't require that it be verified. I learned the hard way about this when one day suddenly the number of signups at my site drastically decreased. It turns out that the entire range of IP addresses including my site's IP was blacklisted. It took a long time to resolve it. In other cases, I have seen Gmail marking very legitimate emails as spam, and that can cause trouble too.
It's good to verify the email address, but don't make it block signups.
Right now our customers are mostly businesses.
People seem to be missing that line. If it's for a business, requiring them to login via OpenID really isn't very practical. They'd either have to use an external OpenID provider, or their poor tech people would have to setup and configure a company OpenID.
If this were "should StackOverflow require OpenID for login" or "Should my blog-comment-system allow you to identify yourself via OpenID", my answer would be "absolutely!", but in this case, I don't think OpenID would be a good fit.
If most of your customers are mostly businesses then I think that using anything other than email creates problems for your customers. Most people are comfortable with email address login and since they are a business customer will likely want to use their work email rather than a personal account. OpenID creates a situation where there is a third party involved and many businesses don't like a third party involved.
I think that OpenID is definitely worth looking at. Besides giving you a framework in which to provide a unified id for customers, it can also provide large businesses with the ability to manage their own logins and provide a common login across all products that they use, including your own. This isn't that large of a benefit now when OpenId is still relatively rare, but as more products begin to use it, I suspect that the ability to use a common company OpenId login for each employee could become a good selling point.
Since you're mostly catering to businesses, I don't think that it's all that unreasonable to offer to host the OpenId accounts yourself. I just think that the extra flexibility will benefit your customers.
If you are looking at OpenID you should check out http://eaut.org/ and http://emailtoid.net. Basically you can accept email addresses for a login and behind the scenes translate them to OpenID without the user having to know anything. Its pretty slick stuff...
I personally would say Email w/ Verification, OpenId is a great idea but I find that finding a provider that your already with is a pain, I only had an openId for here cause just 2 days before beta I decided to start a blog on blogspot. But everyone on the internet has an email address, especially when dealing with businesses, people aren't very opt to using there personal blog or whatnot for a business login.
OpenID seems to be a very good alternative to writing your own user management/authentication piece. I'm seeing more and more sites using OpenID these days, so the barrier to entry for your users should be relatively low.