Laravel Socialite has a "stateless" mode which disables storing anything to session. From a read of the source code it doesn't do anything different instead -- it just doesn't store or retrieve these values.
As part of this, it assumes for example that the OAuth state is always valid.
Checking this is one of the things which the Twitter sign-in documentation, for example, tells us to do.
So I'm wondering what sort of security implications using the stateless mode of Socialite could have.
If it's anything serious, what sort of workarounds would there be, for an application running as a stateless API? I could store things in its Redis store, but I'm not sure how I'd tie any bit of information to the current user. By reimplementing what Socialite does I could for example store the state in the cache, keyed by some hash of the user's IP and browser fingerprint. But this seems very messy.
This answer from #iandayman shows what could go wrong without OAuth state parameter in a login flow: https://stackoverflow.com/a/35988614
Related
I start building a new app and wonder what will be the best way to implement auth - security wise.
What are the cons, pros, and differences between the Laravel make:auth and using jwt-auth.
Is Laravel's default auth will be enough?
This description is pragmatic approach so you can do something else if you want.
I think while developing an API you should use JWT based authentication mechanism.
The Json Web Token(JWT) tokens includes user information in itself. So it giving so much important benefit to manage session. First and most important of the benefits is you can be manage sessions without storing them at server. I would like to explaint it just to avoid misunderstanding, you can have store it at server but it's not necessary except a few scenario. These scenarios depend on how you could designed your authentication.
I able to do a lot of more explains about of it but in summary if you are developing an API I propose you would use JWT-Token.
My question may be answered here, Are sessions needed for python-social-auth, but I feel as if I'd be making assumptions and would like to be positive regarding my understanding (NOTE: I'm not using django, I'm using mongo express react node, I'm guessing django might come with sessions built in or something). I followed this guide https://medium.com/hyphe/token-based-authentication-in-node-6e8731bfd7f2 to add token authentication and user login to my CRUD web app, works great, users are authenticated properly, routes are protected. However, everywhere I read about the fundamentals of session and session management states that "every web application in the world that maintains user data has to deal with sessions" (source: https://nodewebapps.com/2017/06/18/how-do-nodejs-sessions-work/). Currently, my react client uses setInterval to regularly check if the access token will expire soon enough to receive a new one via the refresh token. Is implementing sessions required for my app? If so, what is it that they add that I am missing?
It depends on the type of application.
If the resources being accessed using a token are not user specific, then sessions are not useful.
However, in a scenario where the resources are unique for different users (e.g. one has to sign in, etc), then it's wise to implement both sessions and access tokens.
Remember that tokens can also be saved within a session. Checkout 'express-session' to implement sessions in expressjs.
I am developing a web system in php using the laravel framework, I arrived at the part of authentication of users, where it is not allowed the type of user x access to page y. What is the best way to do this with laravel? I thought about creating a session and saving the id of the user, so every time he accesses a certain controller I check if he has access to the id or not. so I had some doubts.
Is this a good way to perform this authentication?
Is this really safe?
is there any way for the client to change my session?
What would be a better method for authenticating user access?
Laravel provides a very good authentication system out of the box. Even though Hacking is inevitable it provides very good protection and since Laravel is pretty popular framework you don't have to worry about the security part. if there is any security bug, patches will be available almost immediately.
And your second concern can a client can change the session ? the answer is NO, if you code it properly. session resides in the server unlike cookies, so there is no direct way for a user to change the session. if you follow good coding practices you are good to go.
And how do you limit userA from accessing pageB. This is a pretty common feature needed in almost all the applications. As of now Laravel does not provide an out of the box solution for this. but this is pretty simple, you can add a role column to the users table, and check whether user have appropriate permission in each page. Laravel keeps the user object in the session, and it is avilable via the auth() helper or Auth Facade. if you want a little sophisticated solution there is a package out there [entrust][1]. it seems a good choice.
You may want to read about
Authorization
Csrf Protection
Authentication
I hope I have addressed all your concerns
Laravel provides a simple way to authorize action thats purpose built for what you need:
https://laravel.com/docs/5.5/authorization
I'd like to secure access to resources in my web application, so I authenticate my users using the standard mechanisms and use server-side sessions to preserve the authenticated state.
I'd like to deploy across multiple systems in a load balanced configuration, but I don't want to start synchronising session state across my infrastructure. Are there ways (using either spec-driven facilities in Java EE or commonly available libs like Spring Security) of preserving the authentication state of a user without server-side sessions, for example by pushing the required state back out to the client? If so, are there additional risks I need to be aware of?
Update - I am using declarative security as per Java EE webapp specs and authenticating via an LDAP repository.
I'm not aware of a framework solution, but the following does work:
After the user successfully logged in you create a secured token and set it's value as a cookie. The token contains all information required (user ID, creation time, etc.) and is encrypted using some algorithm. So all nodes in your cluster can read the token, decrypt it and identify the user. Then you create a ServletFilter intercepting all requests, examining the token and set corresponding user credentials for e.g. ServletRequest.getRemoteUser() by using an HttpServletRequestWrapper.
One way to solve the problem. But you must take care, self-made security must be well-thought-out.
You can store some kind of token in a cookie after authentication, and manage session attributes yourself. E.g., have a database table whose primary key is the authentication token and stores user session data... Don't forget to implement a job to clean inactive "sessions".
As for what you should be aware of, keep in mind that cookies are something easy to access, steal, delete, disable, etc. The authentication token should be something strong and verifiable (hash a combination of the user ip + browser + rotating salt + some other things you can check for).
It is also wise to divide user authentications in two levels. "Has the cookie" and "just validated the cookie"... Let's say that "has the cookie" is a state that can be there for half an hour (or maybe more) which allows the user to navigate the site. "Just validated" state is for important operations, and should require the user to enter it's credentials again. The timeout for this "just validated state" shouldn't be much longer than a couple of minutes.
Keep in mind that I'm assuming that your site is not holding really sensitive data. For those situations I would recommend something such as two-way SSL authentication with external tokens or security cards plus rotating token devices plus biometrics authentication :D:D:D... I guess you see my point.
Cheers,
You can use an open id server to authentication thus separating your authentication and application logic.
I haven't had to tackle a login process before so this is new territory for me and all I seem to be finding on Google are conflicting methods of handling this process, so I was hoping someone could help clarify.
So far I have a salted SHA1 hash made from mixing username, password and my salt variable.
When the user logs in their credentials get hashed, then this hash gets sent to sql and if found comes back with a UserID (or something). So I know they are authenticated.
With that I can handle their session with session variables.
Is that right so-far?
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
I'm confused, can anyone shed some light?
Thanks in advance
You are usually better off using the authentication methods provided by your platform than creating one yourself. There are a lot of non-obvious problems that you can easily leave yourself open to. Which platform are you using? Are you using a web framework?
General purpose hashes like SHA1 are inappropriate for password hashing as they are optimised to be very quick, when you want something that is very slow. For discussion of this, see How To Safely Store A Password.
Anyway, I wanted to have the option of "remember me" and was looking at storing something in a cookie but am not sure what to put in there as, as-far-as I am aware storing the hash would be pretty much the same as putting their username & password in plain text.
Hashes are designed to be one-way functions, so no, it isn't the same as putting their username and password in plain text. However if you do it that way, you'll have to create a way of letting somebody authenticate with the hash instead of their username and password, and that is the same as storing their username and password on the client (as far as you are concerned, anyway).
I like the fact that you have used salt for your hashing but I don't think it's necessary to use the username for hashing only password+salt should be enough. Specially it will inflict an overhead of rehashing if you want the option of changeable usernames for your system.
For remember me option, I don't think you should store any credentials at client side cookies. Only the session ID should be enough. If you want to make it really secure you should use client-side certificates that are issued by the server.
http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500
Your first login process is correct and up to todays security standards with the only exception that you may want to choose another hashing function over sha1.
Sha1 is very quick and therefore brute force attacks to crack a hash are faster. So if your hashes (database) and token (source code) get leaked, the passwords can be cracked.
One countermesure is to use a slower hashing function (see Jims answer for an article about that)
But the best of course would be not to leak your hashes in the first time.
A possibility for the remember me function is to let the user keep the session cookie for longer. For example Magento and Zend Auth does this.
This is however very ugly because you are likely to get hundrets of thousands of sessions stored on your servers, even for users that never return.
The far more elegant way is to store this information client side.
Sidenote: Of course you shouldnt put too many cookies on the client because they get transmitted with every page request. But a login cookie is a very valid case to do so. A good practice is to store the login cookie at the client side and populate the server session with data saved in a database at login which is marked in a session. This way you eliminiate continous database requests and have a good user data registry. Of course write has to be done to the database and session directly or better to the database and then somehow flushed to the application (full or incrementally).
Putting the hash in a client cookie isnt like "plaintext". However its ugly and awful and insecure on many levels.
There are some different approaches but they mostly involve some hashing again.
The most common and easy one is something like to put a cookie with user_id=john and user_token=HASH($userid.$appsecret) on the client. Or to store them as one in one cookie.
This is kinda secure but I prefer the following method:
Generate a string that holds:
userid ; user agent ; first two ip segments ; current timestamp ; your application secret token
Run it through a good hashing function and store a cookie at the users client that looks like
auth=userid;timestamp;hash-of-the-above
When the client logs in via cookie you re construct taht string from above but take the timestamp and user id from the cookie. Generate the hash and see if it matches. Then you have validated that it is the cookie you generated for that ip adress segment and this user agent at the specified time
Sidenote: first two ip segments rarely changes with dynamic isps. you can leave them away too, its for extra security.
What is the main advantage of thsi method?
The client or you can invalidate all login cookies by setting a timestamp. Only cookise that have been generated afterwards are accepted. You can also implement a timeout.
This is good if you want to "remote logout" form a public computer where you forgot to log out or something.
I think functionality is very important and with this method you dont have to keep track of single login cookies (like google does).
Hope this helps you.
You can scale this method to any level of security you like and adjust it to your needs.
your authentication is just fine. If you want to make it even more secure you could transmit the login information with a SSL encrypted connection so nobody can read what's going across the network.
The remember token is quite simple let's say you want a remember me function that is valid for 14 Days.
A stranger with no authenticated session comes to your site:
Check if there is a remember me token in a cookie
If yes, check if you can find this remember me token in your database and check if the "valid until" column is still valid (date comparison)
If you find a valid token you can set the user id and authenticate his session
If you don't find a valid token redirect the user to the login page if necessary
When the user fills out the login form and authenticates him sucessfully:
Generate a token using an appropriate hashing function. The token you hash could look like "[Timestamp]---[userpwd]" so it's (almost) definitely unique! Save the token and the date until the token is valid (+14 Days from now as example) to your database connected with the user's id. If there's an expired token, replace it because you don't need to store expired tokens.
If the user logs out by clicking the logout button or similar just delete the token record in your database and the user's cookie.
That's it!
If your platform (web server etc) supports HTTP digest authentication, i would strongly advise you to use it. It was designed by people who know more about security than either of us ever will. It doesn't send passwords over the network. It is supported by all modern web browsers, including mobile devices. If the browser has the password stored, it happens transparently during connection, giving you the 'remember me' functionality without needing to go anywhere near a cookie.
The only thing it doesn't do is let you use a nice form - the use will get a dialog box from their browser to log in.