i just installed wordpress (the latest) and im trying to study wordpress to make my creations secure like wordpress does or to its level.
I noticed upon logging into wordpress, it created 3 cookies.
what I'm trying to figure out is - after logging into wordpress and after it created the cookies for the user. the hash values that are inserted into the cookie, how does that value authenticate who the user is? i matched the values stored in the cookie against the values stored in the databases table called wp_users and it doesn't match..
what i usually do when authenticating a user is upon registration is i'll have a column in a table say tbl_users called hash and the value that would go in this column would be a sha1 conversion of the user name (the user created upon registration). and upon logging in on a login page and after authenticating the user by checking if he exists in the db and so forth. I would create a cookie for that user. in the cookie i would insert the hash that existed in the db and store it in the cookie. that is how i tracked the user through the pages. anyone know how wordpress is doing it? or maybe im doing it the wrong way? i don't know..
thanks in advance.
If the user authentication hash is in a cookie then it could be read, and since it already matches what is in the database directly it could be used by anyone who knows how to look at the cookies. Wordpress applies a little bit of post-processing to the user hash, I think it's in wp_settings.php.
I think it combines the user hash with the unique key you write into one of the variables in wp_config.php. After that you have a unique key built up from something publicly available like the username hash or whatever it is and from something only available in the script ie. not publicly available. It's that combination which then matches what is in the db and authenticates the user.
Hope that makes sense. Some other people may be able to give you better advice about PHP security so you may want to make your question more general.
I would look at MD5 encryption and just try to validate in your wordPress db using that. I haven't tried it but I want to do the same thing.
Just a note to you. When I was faced with the same issue while creating web apps I avoided dealing with that and just decided to use wordpress as a wrapper for my apps. You can have the login direct to your chosen template which can be a PHP page so once inside you can do anything you like but your application will be protected by Wordpress and they update their security as things change. So far for me this has been a win win win arrangement.
I validate my users using wordPress itself. You can call functions that exist in Wordpress to verify who is logged in and using your app. You can then take advantages of everything wordpress has to offer. I love having PHPMyAdmin right inside the wordPress Admin panel. This has made my life incredibly easy recently and I don't have to worry about what I don't know about security. If your developing without a security expert this might be a great option for you. Let me know if you want to know more about how I'm setting it up.
Related
In my web application I would like to show the user if he/she is already logged in on another machine. Also I would like to provide the user with the option to sign out of all machines except the current one.
Now I'm talking about session logins, not active sessions so updating a last_activity column isn't going to do the trick.
Now I assume the (only) way to achieve this is to decrypt the session payloads from the database and checking the Auth id from there. This is quite a heavy operation to do for every page request for 1000 logged in users.
Am I correct in this guess? Is this the correct (or only?) way to do it? Is there a better way to do this? If decrypting the Session payload is indeed the best option, how do I do this? I tried using Crypt::decrypt($session->payload) but I get 'Invalid Data' from the Crypt class.
I am working on a site that has a login API. So when people login on my site, they will automatically be logged in to other sites.
Is their way by which a session can be setup so that other websites can use it? If not, is their any other solution?
One way - you can store your session values in database, and can use in other sites. :)
Example:-
let suppose if my site is deployed on multiple servers and end user might be redirected to different servers accordingly to traffic, then it would be good to save the session values in db.
Yes. It's possible using in example Redis for the session storage. You should look for configuring php sessions to use custom storage. Here is php man for this http://php.net/session.customhandler
What you want to do is probably using a cookie that is spread over your whole domain. This cookie can then be linked to a session. I'm currently working on something like this on Symfony2.
As example:
login.mydomain.com
application.mydomain.com
etc.mydomain.com
login.* will obviously contain my login logic + forms etc. This will also contain an API which the other applications can verify the cookie to. My Application will first check if the user is logged in. If not, it will check if it has the required cookie. If it does not, it will redirect to the login.* login page.
If it does have the cookie, it will validate this in my login.* API. Expired > redirect to the login page, if not it will return the required info of that user and "login" to my application.
The only problem I have at the moment is storing the session. I use mcrypt to encrypt the contents and store it in mysql (cookie_id, cookie_contents). I have but 1 problem, it doesn't automatically purge the expired sessions, I still have to find a solution for this.
What you are basically looking for is Single Sign-On (just a guess, but I think accurate).
I'm currently trying to join 2 web apps on different domains example1.com and ex.example2.net so that you can login to example1 and click on a link to example2 and be instantly signed in, as it would be more convenient for customers to just login the once and navigate between the sites.
I've researched various means ie. php sessions, openID, JOSSO and Kerberos, but what would be a secure and easy way to implement this?
Kerbros is very extensive and for systems requiring high security. Its very difficult to work with, and even just setup over all, I would not suggest this route unless you know linux very well, and provided your hosting provider allows you that type of access over the machine.
Im not familiar enough with JOSSO or openID to comment well on those however.
Any php sessions are only good for the domain, and server the domain is on, kind of like cookies but not, though in all you would use them.
I think your easiest solution more so if the 2 sites are on the same hosting account/server. Is to have a database specific to this cause. What you would do is create a login system like you would normally but instead you would have 2 sites reading off this login. Aside from the normal login you would also have a session tracking table. Typically you already set sessions when users login to keep them logged in, and you'd do the same here, but you'd add a cookie into the equation one both sites can recognize and use to compare entries in this new table where your tracking your users. I'd say keep try by IP, Browser, and maybe a userID all in one cookie with a unique hash of some kind as well thats specific to the user based on something only the servers could recreate on the info they have for the user.
Of course I dumb it down in conceptual speak, its a little more elaborate than I make it out to be, but this would be your general stepping stones.
Also if the sites are independent of one another you could always create an API between them to pass info back and forth JSONP style so one can act as the hub for the login while the other just validates
But in all its all dependent of what your wanting to do overall how, when where, etc..
You can have one application handle logins for both sites using php sessions.
example1.com
user logs in and php session cookie is stored.
ex.example2.net
check example1.com and validate session cookie. if it does not exist redirect to example1.com login page or a custom login page on example1.com. If it does exist, then log the user into ex.example2.net.
If you only want a link then you generate a hash and pass that to the second app once they have logged onto the first. If the hash validates, then log them in.
If it works for you, my suggestion would be to go the openID route. It's the easier way and it's secure enough. Besides, the registration process is easier and quicker to users too.
You can actually only allow IDs from your sign-in domains, if you prefer, making it pretty much a "private" login system.
There are downsides too... You don't have fine control over the registration process, you are dependent of openID authorization process... There are some problems that might happen if your host is not well configured (timezone differences, for instance).
But overall, it's a relatively secure system, easy to implement.
Kerberus is extremely secure but it's a nightmare to work with. Unless you're dealing with highly sensitive user information, like credit card numbers, or think your websites make apetizing targets for hacking I don't think it's worth your time.
I would use a database table that is shared between the two sites. If you go down the PHP session route don't try and just pass the session data from one site to the next on separate domains, it won't work. I found this post helpful many moons ago: Single Sign On across multiple domains
I have my own login system, and I want MediaWiki to share the same session. I'm trying to have my login system automatically login to my MediaWiki too which means I would probably have to share the same user database too.
Advice?
Not sure if this is exactly what you want, but we use LDAP Authentication.
The session is set in includes/GlobalFunctions.php. If you want to fake a user login to mediawiki after the user logs in to your system, you'll need to make sure that the cookie parameters match (e.g. the cookie URL must be the same); have a look at the arguments they use to construct it in the call to session_set_cookie_params.
Once you've got the session set up correctly, you'll need to load a user and inject it to the session so that when mediawiki goes to check if the user is logged in, it finds your injected user and goes right ahead. Look in includes/User.php, the User::loadFromSession call looks like a promising place to figure out what they expect to find there.
If you make changes directly to the MediaWiki source, you'll have a hard time upgrading to future versions of MediaWiki. It would be much better to use the existing authentication plugin framework:
http://www.mediawiki.org/wiki/AuthPlugin
You didn't specify what your existing login system is, but if you're lucky somebody has already built a plugin for it:
http://www.mediawiki.org/wiki/Category:User_identity_extensions
I've seen a few instances now where web applications are letting try them out without you having to sign-up (though to save you need to of course).
example: try at http://minutedock.com/
I'm wondering about doing this for my own web app and the fundamental question is whether to store their info into sessions or into a temp user table?
The temp user table would allow logging and potentially be less of a hit on the server, correct?
Is there a best practice here?
It should work exactly the same way the application usually works, with the only difference being that a flag like thisIsATrialUser is set. You shouldn't create two different ways to do things internally.
Create a class of user, lets call it your Anonymous User Type. Give all unauthenticated users anonymous accounts (you have to clean up old accounts at some point). Use a persistent cookie to associate old users with their anonymous account. Make them authenticate themselves whenever they need to perform something that requires payment or full registration. Change their user type to something like Regular User Type once they are authenticated so you can keep all the information that was already attached to them when they where anonymous.
This allows tracking and storing of potential information like shopping carts without requiring registration upfront. Your code shouldn't have to change much if you treat anonymous user similarly to regular users. Otherwise you have to create an entirely new set of code to manage special users that are not stored in your master user table.
To clean up the data added by trial users, you can create a script to delete all the data that was created lifetime of cookie + 1 day and owned by any trial user. You can auto-pilot the script with nightly cron.