I'm upping my security on my website, because some of my users were
questioning the security, but all I can say is no one can view your
password (dual hashed using SHA-512 and then md5), but they reply, but what if they get into my account they
can change my password and play around with my account.
So I'm going to up my security kind of like Steam's security where you can't login to a
new computer without them sending you a random key. I'm trying to think of a way to do it, so I've got it so it will store a little array in my database that will have all the computers that the user has logged in to with.
But I need some data so that my script can check it but I'm not quite sure what data, I was thinking of the IP address but you can't get it without an external source e.g whats my ip and other sites like that. I need some data that doesn't change with the same browser/computer.
So question is, I need some data that is unique to the browser he/she is using but it does change if he/she is on a different computer or browser.
It is possible to implement some security in your web application on IP level. As a matter a fact, for example, in the company I am working it's possible to log in with "Administrator" account only from the devices connected in company network - a given range of IP address.
If you want to implement this technique for each user, you will meet a lot of issues because your users can be behind some proxy server, that is changing their IP address on each log in or on given interval of time.
They are different types of proxies and you can detect when the user is using some of them, and then retrieve the real IP address of the user - check this HTTP headers:HTTP_X_FORWARDED_FOR, HTTP_VIA AND REMOTE_ADDR EXPLAINED and more specific this X-Forwarded-For one.
Any way, they are a lot of techniques to hide you IP address like proxy servers and applications like HideMyAss that makes the whole thing pretty easy.
Anyway, even your users send to you a specific set of email address that you will store in your database and check if the users are connected to your application using them, the same possibility for abuse, using your account (as the passwords) is faced again. The IP addresses will be just an other field in your database table. So, if anyone can change the passwords, he might be able to add an other new IP to the IP list that your are checking.
I think that the best think to do, is to implement such IP security only for your administrator account. Then, you and your clients will be calm that no one can join with it and change their passwords.
Don't know if you have many users, I never did this in a practical application but played with bouncycastle a long time ago. Had a similar problem with a 3rd party provider providing services to out company with IP filtering but Dubai offices were refused because some proxy gets in there that doesn't provide forwarded for and has a wide IP range.
Here is the option I was thinking of but never applied:
Making a self signed key for each/all/groups of client to import and and importing the public part of that in your server store, then do not allow anybody there unless they have a key that's imported in your server keystore.
Maybe if you serve companies that use a proxy you can have the proxy serve the key.
Related
I developed an API to get all the data.
The site do not have a user registration system or anything to identify the user making a call to the API. If I could identify the user making the call, whenever someone misuse or attack the API I could even ban his IP.
I'm thinking of generating an API key based on user IP or MAC address but is it safe to do so? Any other suggestions?
First, you won't get the MAC address of the end-user. Even if you read the MAC address of incoming packets, you'll only get the MAC address of your router (which you definitely do not want to ban!)
User IPs are pretty easy to change and/or spoof (malware or confused-deputy Javascript, for example). Blocking those that make bad requests is still a good idea, but you definitely don't want to use them for authentication.
You should consider pretty much everything in an HTTP request (path, headers, and so on) attacker-controlled input and definitely not make authentication decisions based solely on information contained therein.
You mention you have a PHP backend. Why not build a system to generate API keys through that?
it is absolutely wrong, you cannot get MAC address of the user, there is no way from JS/PHP
many users behind NAT will have the same IP address for you, so you will not be able to distinguish them
You say there is no user registration system, then why would you generate an API key?
You can't have both worlds. Either the requests are anonymous, or the user registers, in which case you can provide an API key (better be using HTTPS so the keys aren't stolen), and possibly further limit by IP address range depending on your use case.
As others have answered, MAC addresses are only available on the same physical network. They do not go through routers, so they do not travel the Internet. You don't have access to anyone's MAC address outside of your physical network unless you have written a custom application that collects it (and those can be spoofed).
IP addresses can be dynamic, and some people share IP addresses based on geography, ISP, carrier, or business. Besides, many of us can easily change our IP address, so it's difficult to manage access by IP address.
There are some pitfalls and it takes extra time to manage a public API. You have to be willing to shut off an IP address or IP address range despite the fact that you may be blocking innocent and upstanding users at the same time as the abusers. If your application is free, it may give you more freedom since there is no expected level of service and no contract, but you may want to guard yourself with a legal agreement.
Many public APIs still track by IP address and implement tarpits to simply slow down requests from any IP address that seems to be abusing the system. This way, legitimate users from the same IP address can still carry on, albeit slower.
In general, if your service is popular enough that someone wants to attack it, that's usually a good sign, so don't worry about it too much early on, but do stay ahead of it. You don't want the reason for your application's failure to be because users got tired of waiting on a slow server.
Your other option is to have the users register, so you can block by credentials rather than IP address when you spot abuse.
It's not a good idea to ban an IP address for many reasons. And anyways, a hacker can spoof IP addresses, so this technique is useless.
What you can do is throttle the API calls based on the IP. i.e. limit the numbers of calls per IP per second.
You might find this helpful: http://blog.programmableweb.com/2007/04/02/12-ways-to-limit-an-api/
I was looking for a way to create an IP filter, so that I could easily identify customers, but many examples I saw, I could not understand in a way.
Then, I come here with some questions
A customer enters my site, IP x recovered from $_SERVER ['REMOTE_ADDR'], but I've been reading some things about CRID, which is one way to check if this IP is on the list denied, because obviously 90% of customers accessing the site, when you restart the modem IP is changed, I do not know if I'm talking nonsense, but a good idea to create an IP filter?
You should combine multiple factors such as sessions, cookies and ip filters.
But of course users still be able to clear cookies and sessions.
You may try to get mac-id of user's pc or computer but it is complicated and dunno it is useful or not and also user still can change mac-id but it's not an easy thing to do.
So i am running into a problem with people making multiple accounts to make there account better with more resource in game.
So my dilemma is, Many users go thru proxys or NATd info so some legimated users would be banned if i only have 1 user per ip.
Is there a way (with Javascript and PHP) to Get a uniq identifier specific to a computer (without Hardware changes, computer hardware change probably would change the identifier).
Any idea or comments would be much appericated
(The following was revived from a response made by Paul, but deleted by another for being out of place.)
I cant change the client to much because its a browser based game so getting the hwid would be possible. But how with JS or PHP.
Adding timers and restrictions to prevent transfers are in place but doesnt stop them entirely there is an option to email for an IP exception. but that is slow an tedious. Im wondering if there is a definitive to generate a specific id or identifier for a specific computer (Not ip based) that would make it so multiple accounts cant be logged in from the same computer but can be logged in from the same ip
As we are talking about a different account, probably on a different IP and client, you cannot easily find out clone accounts.
You can go for two more heuristic and gameplay options
As suggested before (by #dqhendricks), divide your resources and implement your sharing etc in such a way that you can't easily help your other account with every new account. Make finding other accounts in the beginning hard/impossible, make shareable resources a higher level feature etc. Downside is that this changes the gameplay, it doesn't have to be desireable.
You can perform heuristics on behaviour. There can be specific behaviour that is unwanted: only interaction with 1 other account etc. You could tweak some of the variables etc, but you could easily see suspicious behaviour. Make some sort of 'balance' calculation. Most ingame interactions have some sort of balance. Ofcourse, better players may have a good deal because they know more, or the other way around: they make a bad deal to help smaller players. But when one player only gives and never takes, it's "helping" without acutally playing itself: that might mean it's a clone
Everything with ip-adresses or client-information ($_SERVER) etc is worthless in this case as far as I'm concerned..
You could prevent multiple logins on the same Account (username/password).
If the issue is that they make multiple accounts with many different email addresses etc... and new usernames and passwords then you might be able to do it with Cookies for example that use a unique hardware id and then you simple check that not more than one account is active at any one time based on this hwid. if the hardware changes it doesnt matter as it is relative.
To clarify if the HW id for the first login is 1234 then the second login with generate the same hwid. If you check the cookies or your database (doesnt matter where you store it) for the same hwid then you know its already logged in.
If the hardware changes it doesnt matter as they will still both generate the same hwid.
If they use two computers though the haardware id will be different and this will work.
{sharable resources} = {total resources} - MAX(({starting resources} - {spent resources}), 0)
make only non-starting resources sharable, or maybe make sharing resources an ability you don't gain until level x.
Preventing spoofed/duplicate accounts (while ensuring all legitimate accounts work) is a very difficult task -- for reasons laid out by others. In addition to trying to guard against concurrent multiple accounts, one must guard against non-concurrent multiple account usage.
The core issue isn't so much in determining where an account connected from, but being able to trust that a user only has one account -- and to this end the only "real" solution is to use a system which already provides this sort of information, such as a credit card or paypal account ;-) That is, simply prevent someone from creating a new account (although an account can have multiple aliases/profiles, but these can be trivially tracked) unless they can prove "uniqueness".
(Also consider that two people may have two different accounts on the same machine.)
Happy coding.
I run an online game server aswell. To prevent your dilema, either modify the game client to read the MAC Address, and only allow 1 account per computer. Or log the ip's and only allow the resources to be given to that ip twice.
3rd option: Don't allow transfering of materials from the same ip addresses
4th option: Add a timer on the transfering of resources, make them wait 10 minutes of gameplay before they can do anything like getting rid of the items for others to get
I need to make sure that every users accessing my web application can do that from one machine only, so 100 users would mean 100 machines. What would be the best solution? Is detecting and storing IP during first login good idea? I think IP might change even during lifetime of the session is that right? I was also thinking of storing cookie when user first logs in. Then assigning these cookie to the user, same as I do with password and username already, and every time when accessing application checking for presence of that cookie.
Please let me know what in your opinion would be the best solution. My backend is php/mysql if that matters.
EDIT: I need to clarify... This is in addition to normal session management. I need to restrict users to be able to login to web application from one specific machine only. So if user originally logged in from his computer at work and I stored its ip/cookie/etc., then client logs out (or even not), goes home and tries to login won't be able to do that. I agree its horrible idea but client insists :)
IP address might change in the case of mobile clients, or clients that switch between wired and wireless networks. Your best bet would probably be to provide a randomly-generated UID to each client when it first connects (if it doesn't already have the cookie). Then you can check that the same username isn't connecting using two different UIDs.
The trick is that you need to make sure to time this UID out, so that if the user goes to another computer they aren't locked out. Perhaps one change to the UID is okay, but they can't go back to a UID that's already been used?
You can limit to a single useragent by issuing the client with a client side SSL certificate created with the keygen element, this gets the browser to generate a key pair, keeping the private key in the user agent, then you receive an SPKAC, which you can use to openssl create a certificate, which you then send back to the user agent, it installs it and it can be used to identify the user in that specific browser only via HTTP+TLS from then on.
Anything else, simply won't work 100% - although you can hack ways that appear to work (until something goes wrong and it doesn't work) :)
Unfortunately, an IP is not machine-specific for multiple reasons:
The IP address could change during the session, with no notice (the user might not even be aware of it)
Most users have dynamic IP, so it most definitely will change at some point
For machines such as a laptop, tablet or cell phone, the IP address is based on the current service provider
All users behind a proxy would appear to you as a single IP, so you still wouldn't be able to detect if they moved from one machine to another
Instead, generate some kind of unique key for the session and track it in combination with the user name. Prevent them from logging in if the same user name is already in another active session. (You'll also want some way to automatically flush these, just in case you lose the session-end event.)
The best solution is already built into the web server depending on which one you are using. That's what the Sessions are for. In ASP.NET/IIS, usually there is a 20minutes per session timeout.
So if a user uses another computer to access your webapplication, then the session timeout will release connection from the machine that is idle.
UPDATE
You might want to consider restricting user by the MAC Address of their machines which are unique.
If it is a very internal application that will be used only inside a company, it might be possible to define an IP range because smaller companies which do not operate worldwide will probably have a certain amount of IPs from their internet access provider.
You could also think about using some info from $_SERVER to restrict users to a combnation of a single web browser (HTTP_USER_AGENT) and a single port (REMOTE_PORT) - as an additional way to differentiate machines.
But all these solutions are bad or worse, it's technically probably not possible to solve this problem (unless you will have guarantees from your client that all machines will keep a static IP in which case it is a trivial if else problem).
Don't do that. Many people will access your website from multiple computers, and they will complain if you block them.
I'm currently in charge of setting up a polling system (using PHP).
Now for it to be as secure and objective as possible, it's important that a visitor can only vote once. I'm thinking of validating the polls by visitor's IP (there can be only one vote from one IP), and maybe throw in a captcha test to be sure that no bots can get in once they've passed the IP validation for some reason.
So there it is, unique-IP validation and captcha. But is this enough ? Is there a possibility that a single user can change his/her IP by using proxies or other ways I don't know of, and vote multiple times with unique IPs ?
Are there better ways to do this ? Preferably without the captcha.
Thanks in advance.
There is absolutely no way to be sure a user has voted once when it's a public voting system, where no login is required.
Checking the IP is not a good idea for several reason. As described in other answers, lots of networks are behind one ip, and users can just use an other pc with different ip and vote again.
OpenId
Use OpenId to identify the user and check if they have already voted.
Register users
Optionally you could allow users to register themselves if they do not have an openid account.
To implement a secure system, where session spoofing, and thus multiple voting, is made difficult read this
You can't create a 100% secure voting system.
If it's based on registration/IP/cookie, the user can create a new user/get an another PC/delete all cookie.
But you can try it with auto prefilter + administrator as postfilter workflow:
Prevent multiple voting with cookie (or IP / browser properties / etc.) filtering automatically.
On an admin view, the administrator can parse and delete votes by hand based on IP or subnet address. This is nor a perfect solution, but with some good query (same votes in the same time intervall from the same IP/subnet) the administrator can easily delete suspicious votes.
One big drawback of this solution is the need of an administrator. But - I think - there is no perfect solution.
Unless you're going to require identity verified by CA, there is no way you can be sure, that each person votes only once. This of course would be total overkill, so the real question is: how to make multiple votes more difficult.
email with verification code. IMHO overkill, but depends on how sure you want to be.
use session to check who voted. Obviously not 100% secure, but will stop 99% of ppl.
use cookie to check who voted. Like above, some ppl will know how do delete cookies.
use POST, ignore GET.
use combination of 2 or 3 of above.
If you're going to use IP for validation, do not use just REMOTE_ADDR, combine with whole X-Forwarded-For. This way you won't block people connecting through same proxy.
Don't go with the way of unique Ip. There are a lot of case scenario where a lot of users have the same ip (i.e. italian isp fastweb, large corporations, etc). Also, if user has dynamic ip it can change it's own ip address every time he likes...
One of the best ways should be using email address and cookies. User will be able to vote multiple times (you can't avoid this), but at least it will take them some time for each vote.
for a similar project i did 2 verifications ...
i placed a cookie and also saved on the server a hash from users ip + user agent.
this seemed to be pretty effective since even if there are more people that use the same IP the hash with user agent will be different most of the times since it differs for same browser depending on the operating system and other extensions installed.
There is no fool proof way for preventing multi votes. Checking cookie is anothr option.
Regarding Validatin the ip address. What if the user is from a net work which is used by many users?