I'm looking for a short tutorial about creating a login page for a website using cookies.
Each user has a username and a password.
Should I save both the username and the password in the cookies ? or just the username may be enough ?
Can a malicious user steal somehow these cookies and pass the authorization ?
It's not a good idea to store the password in the cookie. If you store just a username, your system is basically completely unsecure. Remember that the client has complete control over the contents of cookies it sends to the server. It can send any username it wants. You should create an authorization token for the specific session (probably with an expiration time associated with it) and store that in the cookie. To prevent tampering with the cookie, you should sign (and encrypt) it on the server and validate the signature.
That said, doing that correctly is not an easy task. Don't reinvent the wheel. Use the authentication mechanisms provided by your platform.
There are many ways to do authentication in PHP. Just google one
http://www.developertutorials.com/scripts/script-details/307067.php
You will want to store you user's passwords in a database, and keep obfuscate them in some way. PHP has a built-in function called md5().
Here's a guide on php.net to help you through.
http://php.net/manual/en/features.http-auth.php
I'f you're having trouble grasping these concepts, then I'd recommend working through a php framework. My framework of choice is cakePHP, which makes stuff like authentication a breeze (another top framework is Code Igniter).
Related
Using angularjs in the client , and c# in the server side.
I want to learn how can i create a website with users.
I know how to store the data in the db.
My real question is how the site remember the user session
After refreshing.
So the user dont need to login again.
Thanks guys.
Microsoft created a JWT (JSON Web Token) package for .NET Web API projects specifically for this purpose. And since you're using Angular.js, working with JSON is perfect.
There are plenty of tutorials for understanding how JWT works and securely saves a user's session like this one: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token.
The idea is that your server sends your client/user a long encrypted string. The client saves it in their cookies and sends it to your server whenever you want to verify the user.
Most of the complicated details regarding encryption you don't need to worry about. Just follow the tutorials for setting up the exchange of the JWT tokens.
Back in the days, we use cookies to do this.
In the Restful html5 world of today, we can use several other options.
Websql, Localstorage, IndexedDB.
Probably you are using something like JWT to store an authentication token you use to make authenticated api calls.
The way to go, or as i do is store that token in localStorage and then, inject in every call to the api.
Then in the angular run section i check if the user is authenticated checking if i have the token stored, and if is not, send to the login page.
angular.module('Scope', ['ui.router', 'ngStorage'])
.run(function($localStorage, $state){
if (!$localStorage.authenticationToken) {
$state.go('login');
}
}
});
In this example, every time the app reloads, angular execute the run function, and checking if we have stored the token, if is not, send the user to the login webpage.
I have a form that via AJAX validates login credentials from an external php script and database. I am attempting to password protect pages of a Squarespace website.
I am wondering if there is a way to securely store some kind of token returned when the user logs in using the login form that can be checked on each page the user attempts to access and redirects them or allows the to stay on the page based on if they successfully logged in.
I have looked into using cookies, web storage/local storage, window.name and several other methods that other people have used but none actually seem secure and I am not able to use php.
Is there a secure way to do this?
Well, it depends on what you mean by "Secure." By default, for example, PHP's built in Session feature will use either a query string or cookies. The same is true for ASP.NET's Session feature. These are used on millions of websites and I'd say it is secure. The question is, what are you storing in the cookie? If you set a cookie like "IsLoggedIn" with a value of 1, that's not secure. However, if you do like PHP/ASP.NET do and store some random string (ideally a cryptographically secure random string) which is validated server side to a list of logged in random strings, you're good.
But that begs the question, why aren't you just using PHP sessions to store this information? See http://php.net/manual/en/features.sessions.php Then you'd store the IsLoggedIn in the session object which is stored server side, not client side, and you're secure.
I'm a bit confused. I am trying to provide a simple Google Authentication sign-on.
I would like to use Google's recommended method using the client-side flow: https://developers.google.com/+/web/signin/add-button
If I use this method, how will I keep a user logged in as they move from page to page. I know I can't create PHP session via Javascript.
How can I use the client-side flow and keep a user signed in. I am using PHP on my server.
After spending a few weeks researching, I now understand that I cannot just set a php session variable and stop using oAuth2. I realize that everything I need to get information from Google, I must prove that I have still authenticated that user.
Also, I have come to understand that unless you force prompt, Google will not resend a refresh-token. To provide the best user experience, you must capture the token at first login and then re-use the token to make calls without having to force prompt. This token must be stored in a secured location such as a database for each user.
I wrote a simple demo html (SSL enabled) forms to access some university services thru it. It requires the user to login with his university ID first .
My question is , how to encrypt the logins data even from me the owner of this page ? Is it possible ? so that the user can confidently use this.
You could use HTTP Digest Authentication which does challenge-response authentication and always sends password hashed.
The problem with Digest is that UI for it is ugly and logging out is left up to the browser (you can't have a reliable logout link).
Alternatively you could implement your own challenge-response mechanism in JavaScript, e.g. http://code.google.com/p/crypto-js/
but it's rather pointless, because the user doesn't have any guarantee that you're doing it, and that you won't replace the secure script with an insecure one in the future. As the site owner (or somebody that hacks your site) you could change the script and "steal" passwords at any time.
SSL is good. That's the best real security you can do client-side.
You can ensure that you're storing passwords securely on server-side — hash it with a slow hash such as bcrypt (not md5/sha1) and use unique salt for every password.
I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?
I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.