I realize that mac addresses or machine ids aren't transferred over the internet, however, I would like to lock down our subscription-based website security so that only specific computers can register and have access to its resources.
Large organizations will subscribe to our service and will undoubtedly have more than one ip for their organization. As well, we'd like to give the ability for their qualified employees to access the website on devices outside of their physical organization (for road-trip presentations, etc.).
Is there a sure-fire way to achieve this end (beyond the username/password assigned to each account)? If not, what would be the most effective approach?
Instead of restricting access via IP, you want to use something that's actually secure.
Username and password over an HTTPS connection should at least be unsniffable, but you might want to look in to client SSL certificates. They can be configured in Apache or other web server software. If username/password authentication is not enough, this is the next (and perhaps final) step up.
UPDATE:
That said, what many application providers will do is provide a method for subscribers to implement an ACL for their accounts. You can even force people to consider their ACL before allowing them to access your services. Think of it this way:
An account is set up in your system allowing login from anywhere. Upon creation, the ACL is UNSET.
User logs in and is immediately directed to an ACL setup page, where they must provide either an IP address or range or subnet associated with their account. You can be clever and pre-populate things with their existing IP address or subnet, perhaps even looking things up at ARIN to see if their IP is in a network assigned to the company name on their account.
Once the ACL is set (or they have, despite your warnings, confirmed that they want to keep their ACL open), they can access your services.
If they try log in from elsewhere, they (and you) are notified via email (or SMS or whatever) of an attempted breach.
If they no longer have access to their ACL-listed IPs (i.e. IP renumbering due to a new upstream Internet provider and bad planning), they can call your phone support who will validate them by other means. FAX confirmation perhaps, because that's SO secure...
A user-managed ACL is not a "sure-fire" way, but it may be sufficiently effective for your needs, and it will certainly instill a sense in your customers that you have their best interests at heart.
There is no sure-fire way. That's in the nature of networks. You accept data from a remote machine and you have to trust it at least to some extend.
Take the simple username/password approach. If the usename and the passwords match, you have to trust, that they where entered by the person that the username and password was intended for. This does not fundamentally change if you require more data to be send by the client.
Related
Ok so people keep botting my multi-ogar edited server(which is like an agar.io private server), and I noticed that they all use the same user-agent. How can I use ws to detect how many connections are coming from the same user agent so I can block them?
Something like
if (useragentconnections += 3) {
ws.terminate()
}
Unless you require some sort of account login/authentication, there is no foolproof mechanism to identify the same user-agent. Here are some techniques that can be used, each with varying degrees of success:
Cookie the connection with some sort of unique ID. All webSocket connections start with an http request so you can cookie them. If this is from a browser, the cookie will be presented at each new webSocket connection from that user agent and you can identify them. If this is a programmatic webSocket coming from some custom code, then they may not retain the cookie so this would not work.
Look at the IP address and count connections from that IP address. If the user is an individual home user, then this will uniquely identify any users connecting from that home network. If this is a corporate user, then there may be many users on that corporate network that appear to be coming from the same IP address via NAT so you may falsely identify lots of users within the same corporate/business network as having the same IP address.
Require some sort of account login/authentication and have some terms of service. If you identify misuse either automatically or manually, you can then ban that account.
Require some manual "human" intervention in order to get logged onto your server such as a captcha. This is to prevent automatic programmatic logins and require that a human be on the other end.
I'm new to user authentication and related digital security issues, so I would like to know if the way I'm doing things is ok. Currently the way my server "remembers" users is based solely on the IP address they have logged in from. If they check the remember me option, I store that IP in the database and from then on, every time that machine enters the website, I check if that IP is associated with one of my users. If so, I log them in.
What is good or bad on that approach?
I just wonder whether CloudFlare (or others) manages this or not and if it manages how. The situation can be explained with a simple example. Think of a corporation in which there are 1000s of users. These users have the same IP (different internal IPs of course but external IP will be the same since it's a corporation..) and these users try to access the same site which is protected by CloudFlare. Will CloudFlare treat these users as the same users or not? How does DDos prevention tools manage this situation?
I would manage it as writing unique cookies for different users (kind of session_id) and look for this cookie value. Since it will be different for all of the users behind company network, there would be no problem..
Edit: That cookie solution is the way I'll go as a solution for my problem (if security vendors don't manage it..) and I didn't write it as the ideal solution for security vendors (that would be so arrogant:) )
I'm looking for information about authentication but I'm very newbie so I don't know any system.
My requeriments are: An user only can authenticate from one computer/mobile device/tablet.
I'm thinking about a monitoring system of MAC address and when the user connect using other device I can see this like an alert.
What other methods are there? Certificates?.
Repeat, I'm very newbie with this.
PD: My app has been development with framework Symfony2
So first of all MAC address is a network local address, which means that after it goes trough router/switch the MAC address changes, so you cannot relay on this. Even if you wanted to lookup interface MAC addres with your client software MAC's can be changed.
Secondly Certificates give you certain properties like nonrepudiation (you can calculate digital signatures on operations that users do and then the could not deny doing something in your application). But Public Key Infrastructure is really hard to manage! You would need your Certificate Authority to give valid certificates, You would need to monitor and update Certificate Revocation Lists to deny stolen/invalid/forged certificates from being treated as valid and authentic.
If it is not a security centric application and after you analyzed your options I would suggest simple form authentication (username/password/captcha). And write mechanizm that would periodicly (i.e. every second) send an AJAX request refreshing user status, thus you could recognize if user closed browser or has opened window. And in your authentication process you could check for other ACTIVE sessions for given username and deny login or act in some other fashion. If you need more informations about authentication I would recomend looking through security patterns
My site allows all users to redeem a coupon. However membership is free to the site. How I structure my redemption system to best discourage people from creating many free accounts to redeem many coupons?
I was thinking of only allowing one redemption per ip per week. Is this reliable? What is the most reliable way?
Using IP is generally not great as, depending in the customer ISP, it might not be unique to the individual customer. You might be better off looking at cookies for tracking (and expire them after a week).
Terrible idea. Give it up.
Here's just a few reasons:
Everyone who works in the same office probably shares an IP.
Everyone who lives in the same house probably shares an IP.
Everyone who comes online through the wifi in that starbucks down the road, probably shares an IP.
Home networks where the router is set to use DHCP will get a different IP address every time it is bounced.
Users on cellphone networks will most likely be routed via a pool of proxy servers and can have different IPs even during the same session.