I've have some authentication scenario that I'm not sure how to approach. I'll appreciate any advice on the subject.
Requirement:
Website will contain one section
that will be only available to
specific computers.
Website needs to be aware which PC is currently making request (I need to be able to tie this PC to other tables in Database)
We have full access to PCs that will be accessing website
Website cannot require login, user should be just presented with content pages without need for logging in.
Solution needs to be secure since, it will have to pass security audit
Assume that every PC is on different network.
My ideas so far:
use client certificates but I'm
not sure whether you can issue
different certificate per client? If
the answer is 'you don't know who is
making the request' than it's failing
requirement number 2 and therefore is
not an option.
Windows
Authentication with impersonation so
I can have different users logged in
on PC (I'm in control what will be
the user name/account logged in on
the machine)
Basic Authentication and set PC to remember username/password first time. I'm a bit afraid that this "remember me" can expire which would cause big chaos since someone would have to setup this PC(s) again...
Windows Identity
Foundation - never tried but if I can
implement this scenario here in some
nice way I appreciate if you can
point me in the right direction.
Thanks in advance for your help.
EDIT:
I would prefer not to use SSL if possible... (performance consideration)
EDIT2:
Currently I think that the best option would be to check whether PC is authenticated (whether it contains Forms Authentication cookie) and if it is not then redirect him to some https:// page that will check client certificate, set cookie if cert exists and redirect back to target page.
This shouldn't be slow since SSL will be used only in rare cases when cookie expires.
Please let me know if you see any flaws in this solution. If you know how to create server certificate and later generate different client certificates from it I would be grateful for guidelines.
Related
I'm building a Laravel website for the employees at the company I work at, but one of the requirements is that the users shouldn't have to fill in any credentials to log in, this means instant login when navigating to the website.
Right now I'm using an oauth package that lets them login with their Office365 email, they only have to use their email the first time they visit the website, but this isn't good enough to meet the requirements.
Does anyone know how to do this or a package I can use for this? Thank you in advance!
If you're in an exclusively windows enviroment, you can use the NTLM protocol with the help of this package: https://packagist.org/packages/jakub-klapka/laravel-windows-auth
But it comes with a few cavorts ...
Only works with Windows.
The site needs to be hosted using IIS on a windows server.
The server must be on the same domain as the user.
Works with Internet Explorer or Edge. Supposedly you can do this with Chrome and FF but I haven't ever had success.
I haven't tried with Office365 and Azure AD but theoretically it could work. But again, I believe this is only possible if you're a 100% Microsoft shop. Personally, I'd say SSO through O365 is a much better long-term strategy. Support for NTLM seams to be waning, especially as things move into the cloud and IE/Edge continues to looses market share.
Hope that helps!
As part of an application my users can create documents with embedded images/files/text etc. Viewing and editing this content requires the user to log in. At the moment the images and files though are delivered as permanent links so if those links are shared any non-authenticated user can access them forever.
I would like to make these files secure. My initial thought was to use the login token and user's id to check if they have access and only deliver the files if they do. But then I started working on it and it seems the most practical solution would involve generating a link that will expire at some point in the future. This doesn't remove the exposure to unauthenticated access but maybe reduces it enough.
The questions that come to mind are:
Is there a common approach or a few options on how this should be implemented?
I've seen returning urls with expiration periods used
Google docs seems to do something more sophisticated for it's embedded images but I can't tell what
Others?
Basic design points?
Pros/Cons of each?
Yes, it reduces the authenticated access to a fixed time but theoretically it provides un-authenticated access. So a security professional will claim it has no authentication. This kind of timed expiry link is usually used to safeguard against one time un-authenticated access like password reset(along with an expiring token independent from the time).
What is your goal? From whom are you trying to protect the data? Is the users who already have access to files and you want to limit providing an expiry time? From the question, you need to secure the access to the files/documents which has text and embedded images in it from everyone. You are right about the timed expiry design. It will not guarantee you authentication and integrity of the document and if it is over non-secure HTTP it will not even provide you integrity of the document from a potential adversary.
you can use cookies(secure cookie) over HTTPS. As long as the user has the non-expired cookie, allow access to the files/documents. The cookie approach needs distributed cookie management if you to host the solution in multiple boxes with a reverse proxy in-front. Though cross-site scripting is a threat but still most of major web application providers are using cookie based solutions. Please note, cookie breaks the REST nature of the web-application.
Another approach (similar to cookie) is to generate authenticated tokens tied to user/documents which has access for N number of attempts for a time period set while generating the token. This method has to be used over HTTPS to avoid un-wanted listeners.
An always changing link is very costly to manage and not scalable over time because it is too much state to manage and application crash makes it even more costly. Re-directing to authentication is a safe bet for you provided you have already cookie management in place or you have one application instance to take care of.
Or you can you HTTP digest authentication provided that your framework supports it so that you do not have to worry about the cookie-hell. Please note that you may need to write up some client-side java script based on your use case.
Background story: We run a website with thousands of users and a handful of admins. Some of these admins don't need all-access to the website, so I want to restrict their access by giving them individual permissions.
My plan is to set a Session on user login with the users perimissions, if given any. However, I'm concerned that this might be an unsafe action.
Can a Session be manipulated by a user client side? In this case a regular user could gain access to the admin features if they knew the permission names and set a Session for themselves.
I found some related questions on Stackoverflow, but they didn't give give me enough information on the subject.
You are already providing the login for admins and users so save type of permission they have and give them rights to modify data according that..And as long as your session state is encrypted it is very hard to manipulate on client side.
If you have concern about security of your existing session and cookies here is link to make it secure.
Secure your Session
This is full Article how to make your session and cookies secure...
You can indeed store server variables such as the user-agent, the ip address and so forth (and even JavaScript variables), but they are only good for validating that the persistent cookie data matches the client's new connection. The ip address isn't a good idea except when you know that the client (like you only) isn't going to change on every page load (a la AOL).
Modern web browsers and 3rd party services like LastPass can store login credentials that only require a key press (and sometimes not even that) to send the data to the login form. Persistent cookies are only good for those people who refuse to use what's available otherwise. In the end, persistent, non-session cookies are not really required anymore.
There is no such thing as secure cookie UNLESS it's transmitted over SSL only. It can be mitigated some when using a persistent non-session cookie (like remember me), by doing exactly what you're doing, but not in the same way you're thinking of doing it.
OK, I thought SSL certificate should be used on the pages that have some sensitive information displayed and on the login page, change password pages and so on.
But, on this thread SSL Certificate. For which pages? that was opened about 6 months ago, the best recommendation according to votes was to use ssl certificate for absolutely all pages on the web-site, even for the About page. Well... If you have a news web-site and some users have a login page and pay for advanced subscription, but you are among that users, do you read news with ssl certificate? :)
1) The first question: I've never seen a web-site with http on the About page. Can I doubt that recommendation is the best one?
2) The second question: Why doesn't Ebay follow that rules to have https connection on every page? I see they show ssl certificate only at the login page and never before you log in. After you log in, you see http, not https. What's their point?
3) If you actually have page A for guests and page B for logged in users and page C as a "sign in page" and page "D" as registration, would you recommend to use ssl for page B,C,D, but not for A?
Thank you.
SSL flows both ways. You need to worry not only about the secrets transmitted from server to client, but also about the secrets transmitted from the client to the server. Amongst other things, the latter group includes commonly used client identification mechanisms like basic authentication headers, authentication cookies, and session cookies for authenticated sessions. It is possible to set things up so that such information is not transmitted from the client for certain pages, in which case it becomes safe to load them over HTTP. However, the mechanisms for doing can be complex to maintain and require strict and ongoing auditing. Unless you are willing to make that effort, you should be using HTTPS for all pages that an authenticated user can possibly visit.
I haven't read what was said on that link, but I wouldn't agree. SSL does have a performance hit, so using it for everything, just because you can, wouldn't make any sense. As with everything else in technology, use it sparingly.
So, in the case of applications where security is of great importance - how would implement the challenge question idea. That is...you would:
Detect if the computer IP has changed and hence ask for the challenge question.
Detect if the cookie is missing.
Detect if the computer name is different.
Some combinations of the methods above?
I am currently working on a forex platform...in asp.net/c# and thinking on how to implement thi feature for best results. I think the best and only way will be to check for a cookie change - since if i base on the ip - the ip might be dinamic by the isp of the client - also if i count on computer name then it's not that bright since the computer might be used by more than the user in question...of course if i count on the cookie then the browser might be used by more than a single person...but this is why this is an additional security measure and not the very password/username authentification.
Other than that getting the computer name (if possible??) + cookie change seems to be the best method. I am tagging this as c#/java since the 2 are very common these days when it comes to authentification and security.
10x!
One thing facebook did that I thought was good... You can enable an option to have them put a cookie in your browser... Unique for each computer you use... Then if someone without a cookie in the browser logs in to your account, they send an email to you letting you know... I think they geolocate the source ip of the unknown computer and put it in the email as well... So if you live in the US, you wouldnt expect a login from Russia. Not everyone accepts cookies, but for those who do, this optional feature is great and financial firms should do it too...
My bank (and many others) rely on some form of constant two factor auth Could be as simple as your best friend's name, or if they're like my online broker, high value accounts over a certain balance threshold get a time based password token. You must login first with your password, and then with the token number.
Most financial sites used a hosted picture from their site that you choose to have displayed for your password logins... This helps reduce the risk of phishing losses.