My requirement is i have a portion of the site that should allow user to access from only one system. He may used different IP's and different by if the system is same he should be able to get the access. My site is in PHP. Doing some R&D i found so JS which helps to get the MAC address if the visitor is using IE. My case is i cannot restrict user to use IE. He may use any browser. Is there any way to get the MAC address. If not possible how should i restrict the same user from accessing content from different computers.
No. MAC addresses are not useful beyond the local network, so they're not available in the upper layers (eg. Application layer). Using Javascript to get the the address isn't exactly foolproof either, since it's incredibly easy for someone to manipulate.
If you want to restrict the hosts that a user can access your site on, you'll need to use a method of storage persistence within the browser to store a key - something that uniquely identifies them. Some forums use this method to catch people attempting to bypass their bans.
You should generate some kind of random key (or encrypt a string), store it on the server-side along with the user you want to identify, then give the user the key to be stored in a cookie/localStorage.
Though, there is the obvious problem of a user clearing their cookies...
Hopefully that gives you a bit of head-start.
Daniel is correct, it's not practical to attempt to use MAC addresses.
For your purpose, you'll probably want to use a few layers. Cookies are a good place to start. As stated though, they can be cleared. The user also may have cookies turned off. Cookies are also stored in plain text on their computer, and they're really easy for the user to modify.
You could also implement sessions with PHP. Each session is unique for each system, and browser. If the user switches browsers or restarts their current browser, the session is re-created.
You could also check their user-agent string. It will be different for each browser, and "most likely" each system, but it can easily be spoofed.
You could also use a public/private key exchange, but that can be a pain to implement and manage.
There really is no one fool proof solution. The best bet is probably to use a combination of techniques to get it as "close to foolproof" as you can. Just try not to make it too inconvenient for the user.
Related
I create a PHP/MySQL application that will be used to log in to the user with a username and password, but I need the user login to the system to survive even turning off the browser or restarting the device.
For this reason, I cannot rely on PHP sessions.
Of course I can use browser Cookies, but I'm afraid of being stolen.
I tried to store the generated hash in the cookies and store the login information in the database. Unfortunately, here is a big problem with the potential theft of cookies.
I also tested this hash for security against the browser version and user IP address. Unfortunately, users of the app will mainly use mobile phones (the IP address will change frequently) and hash verification only against the browser version does not seem safe to me.
Is there any way to create a secure long-term login mechanism using HTML/PHP/MySQL/...?
You can think about the problem in abstract terms: You want to recognize a user based on some data. There are two ways you can do this:
You can give some (secret) data to the user they can then show you later
You can gather some data unique to the user
Cookies are an example of 1. - but it doesn't really matter if you use cookies or some other thing like local storage in JavaScript. What you are doing is giving a value to the browser and storing it. All methods have the same risks: The value could be stolen in transit (when not using SSL) or they could be stolen in storage.
For approach 2. there are things like using the user's IP address or other pieces of data they generate "accidentally". These are however not reliable and you're often doing a trade off or a combination of 1. and 2.
For example, you can set a cookie, but on the server side validate that the IP address is the same. This gives you a little bit of additional security, but the user can't use the application on a phone now, since they'd get kicked off each time they switch WiFi / mobile networks.
If you wanted to have something even more secure, you could use an SSL client certificate stored on a HSM. But this is a tradeoff again, since it gets increasingly complex to set up and you have to distribute and manage hardware.
None of these methods help against a compromised client - ie. if the user has a trojan or other malicious software on their machine.
(I'm sure I'm not the first person with this issue, but I wasn't able to find much via Google/Stack Overflow. Apologies in advance if it's a duplicate.)
My site can be used as a data source for the program Mp3tag: it accesses a page on my site, scrapes data, and uses it to tag mp3 files. I want "vip" members of my site to have access to higher-resolution artwork.
Unfortunately, Mp3tag acts like a fresh browser each time: there's no cookie/session data, and the program can't display any sort of "sign in" prompt. So my issue is that I need to [semi-]securely authenticate a user without having them sign in.
My plan is to store a simple md5 hash for each vip member, have Mp3tag include the username/hash in the url it uses to access my site, and then have the server authenticate this. (For the record, I'm using PHP/SQL.)
(Note: I don't need this to be super secure. I won't be using the hash for any kind of sign in or access to anything else on the site. The worst case scenario should be that someone manages to guess a vip member's hash, and then has access to high-res artwork―if that's the worst case, I'm ok with that.)
But will this simple hash cause security issues elsewhere? All passwords are hashed/salted, use PHP's password functions, etc., so having a separate md5 hash (that's unrelated to password) shouldn't cause any issues, right?
And secondly, is there a more secure way to do this? I guess I could add some sort of IP address checks, but that's the only other idea I had.
But will this simple hash cause security issues elsewhere?
No.
All
passwords are hashed/salted, use PHP's password functions, etc., so
having a separate md5 hash (that's unrelated to password) shouldn't
cause any issues, right?
Right. This is a simple "something you have" authentication. It's basically a key that's relatively easy to copy. Not the strongest mechanism, but you're only protecting an image, so it doesn't have to be. As long as your actual account authentication uses separate credentials, you're not weakening that.
And secondly, is there a more secure way to do this? I guess I could
add some sort of IP address checks, but that's the only other idea I
had.
IP-based access can be very effective, but tends to be a real pain when your clients move around. It's probably not worth it for this level of protection.
You might use a stronger hash, but that's irrelevant if the page isn't served over HTTPS.
I think your idea is fine, just use random_bytes() as the source, not something predictable like the username. Think of it as just a second password that they don't get to make up.
So currently on my website I log users OS when they register an account. And then they can view it (their OS that was logged upon registration) on their "account page".
But my question is, is getting users OS from parsing useragent in PHP reliable? For example I get users useragent via this $_SERVER['HTTP_USER_AGENT'] in php, then parse it to extract their OS from the useragent. Can I rely on this being accurate for legitimate users?
I don't really care if hackers can spoof the useragent, all I really am wondering is if this ($_SERVER['HTTP_USER_AGENT']) will give me the users accurate OS from legitimate (non hacker) site visitors?
You appear to be asking whether you can trust this field to be reliable when it's reliable? Well, yes, you can; when it's reliable, it's reliable.
But these times are rare. You don't need to be a "hacker" to spoof a User Agent. A simple browser extension will do it, or one extra argument in your wget or curl command if the request is scripted.
User agent is 100% fallible and you should not rely on it for anything useful.
Yes its reliable for non hacker user.
More Explaination
The user agent string is a text that the browsers themselves send to the webserver to identify themselves, so that websites can send different content based on the browser or based on browser compatibility.
Mozilla is a browser rendering engine (the one at the core of Firefox) and the fact that Chrome and IE contain the string Mozilla/4 or /5 identifies them as being compatible with that rendering engine.
You can also use get_browser() function of php.
Most of the time it is pretty reliable, in that most people can't be bothered to change this information. So using it for purely secondary, and ease-of-use, functionality is OK.
Especially in cases like these, where you use it to fill out the "default" values. Which the user have an option to change if wrong.
However, as it can be changed/spoofed by anyone who knows a little bit about HTTP and/or web browsers, you must not rely upon it for anything security related. There are quite a few browsers even, which will let the user change their user-agent string at will.
That includes using the user-agent string in an attempt to identify a user. As it is trivially easy to copy the headers, and spoof your own.
Use of SSL would increase the difficulty slightly. Still, in order to get all of the headers from your users (or admins), all an attacker would need is to post a link on your site to a server of his own. After which he could do whatever he wanted with his own.
If you want to make your UI more friendly. Lets say: "Is user on Chromer?" then show him some usefull info. Then its 100% reliable and very usefull. I don't care how friendly my UI is for hackers.
In some cases, for example ... lets say that for some reason you would like to block every one but Chrome owner,.. you can't rely on it.
I have been working on a secure login/portal type set of tools, the general code is free from SQL injections, XSS etc, I have mulitple things in place to stop session hijacking.
regenerate session's ID for EVERY page
Compare the user's IP with the IP at login
compare the user's user_agent with the agent at login
have short session time outs
etc
I have done all I can think of to stop hijacking, however I have still located a situation where it might be possible and would like to know if anyone has any ideas.
Imagine a situation where you have 2 users behind a firewall which does SNAT/DNAT, so both apart to come from the same IP. They are both identical machines supplied by the same place. One connects to the site and logs in, the other copies the PHPSESSID cookie and can simply steal the session.
This might sound like an extreme example, however this is very similar to my place of work, everyone is behind a firewall so looks to be the same IP, and all machines are managed/supplied by the IT team, so all have the same version of browser, OS etc etc.
I am trying to think of another way (server side) to stop the hijacking or minimize it further, I was thinking of a token which gets embedded into every URL (changed for each page), and checked.
I am looking for ideas or suggestions, if you want to offer code or examples you're welcome, but I am more interested in out of the box ideas or comments on my token idea.
Force everything to use HTTPS.
I think you are referring to a passive attack where a user in the network sniffs the cookie. For that, you don't need HTTPS. There are several options that are sufficient when the parties are sure to whom they're talking (e.g. you could do a DH exchange first and the server would encrypt a token the client would use in the next request...), but it's not worth the trouble going down that route.
If the user initially types in a non-https address, an active attack is still possible, but there's nothing you can do in that case. In the future, you might prevent future attacks of this kind once the user establishes one unadulterated connection to your site through HTTP strict transport security..
I wrote the main login portal for a major branch of the U.S. military.
I did all you mentioned above, plus at least one more step:
Have you stored a cookie on first login w/ the SESSION salt? Then encrypt everything serverside using that salt. The crooks would have to know about THAT cookie and STEAL IT, and it dramatically reduces exposure to session hijacking, as they just aren't lokoing for it.
Also, use JS and AJAX to detect if they have flash installed and if they do, store a flash cookie, too, with another salt. At that point you can more or less assume you have some pretty dedicated attackers out there and there's not much more you can do (like sending your users GPG keys to use via javascript and make them sign every single bit of data they send to you).
Do not reinvent the wheal, the built in session handler for your platform is very secure.
There are a number of configuration for PHP's session handler. Use HTTPS, at no point can a session ID be transmitted over http "cookie_secure" does this, its a great feature but a terrible name. httponly cookies makes xss harder because javascript cannot access document.cookie. Use_only_cookies stops session fixation, because an attacker cannot influence this value on another domain (unless he has xss, but thats a moot point).
PHP configuration:
session.cookie_httponly=on
session.cookie_secure=on
session.use_only_cookies=on
I am trying to think of another way (server side) to stop the hijacking or minimize it further, I was thinking of a token which gets embedded into every URL (changed for each page), and checked.
You should look at:
Understanding the Rails Authenticity Token
Tokens are a good idea.
The unique poll/vote/survey i mean here is, user can only vote once. How do i do that? Track their ip? Login? Beside login, what else? (login is my last option, thus beside login, is there anything else I can do?)
To restrict the number of votes per person, you need to track the person.
Now there can be several ways to do that, and I'll list them with their pros and cons. Its for you to decide which method suits you best.
login: this will offer you ultimate control. But its also a little cumbersome for the user. and its your last preference
IP: how will you handle people behind web proxies? How about people with dialup connections and/or dynamic IPs?
cookies: this is good for short term polls, so you can set the expiration of cookies to a time when the poll has ended. But, a potential drawback is that a user (contrasted with a luser) will know how to delete the cookies!
openId: While this method is not too different from the 'login' method, this saves the user from registration (which really is the part that sux the most about logins).
EDIT: the problem with this situation is that you need to resolve the identity of the user. I think OpenID does this pretty darn well.
Cheers,
jrh.
You could always store a cookie on their computer. Beware, though, that the user can easily disable cookies, or modify the contents of a cookie. There is no 100% reliable method to do what you want to do - the user can always create a new account, or move to another computer, etc.
If you want to go with the cookie approach though, there are three possibilities.
You can store a bit of text saying this person has already voted
You can store a unique id referencing their vote
You can store a session cookie and store the rest of the data on the server (probably more secure, since they can't edit the data, only the session id, and doing so will probably invalidate it).
The most secure way is a login system.
But if you dont want to use one, i used to add a hash containing the users IP and browser witch will help me filter out to a much better degree then just simple IP ( the browser string might be different for different persons using the same browser, because of the version, operating system and extensions installed ), but you still have problems if they switch browsers, the same problem as cookie.
The hash was stored in a database.