I'm posting a question which I posted here again as I think this is the right place to ask this question
I'm wondering why Facebook is not handling the cookie export between browsers and related security concerns.This will be worst when they are using the "remember me" option as the cookies will be persisted for many days in the machine and someone can easily steam those cookies if it is a shared computer.
I think even Google is also not doing it. I copied the CURL from google with the cookies and executed it in the command line and I was able to get the expected outputs(mails). These 2 are used as identity providers in most cases. So I believe the applications which are using these two as the identity provider and using the remember me option which is provided by them also should face a similar threat.
Is there is an identity provider which handles it properly, maybe with the device fingerprinting or any other technologies?
Appreciate if someone could mention such IDPs and how it is handling that use case.
Related
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
I have an app which allows connections to multiple servers. At the moment I'm storing all connection details except the password using chrome.storage.sync.
Is it possible to store username/password combinations using the standard built-in password manager ?
Is it possible to store username/password combinations using the standard built-in password manager?
In short, no. There is no API to work with password storage of Chrome.
How to do authentication in a Chrome extension anyway? Here's an old question on this topic.
What changed since then is that Chrome has now a dedicated API for OAuth, chrome.identity, which provides a secure way of logging onto web services.
However, if you're looking to make something like a local password manager, then you cannot really protect against a malicious user. All storage you can access, and all encryption/decryption functions, are available for a user to inspect.
A server component that handles a certain decryption step is a good measure, but not always applicable.
Edit: as suggested by Vloz, a Native Client module that handles crypto functions is a good step to obfuscate data.
I have been looking for a way to protect my RESTful APIs. This appeared simple, but it seems to not be so simple. First off, I am writing an iOS app connecting to a Play Framework server. None of this has anything to do with Google, Facebook, Twitter, or LinkedIn (shocking I know). Oh, and my current plans do not require custom apps to use my APIs, its just my apps for the time being.
Basic Authentication
What appeared to be simple was a basic user/pass on a /auth method managing a cookie session. That may draw some groans as being too simple or weak but mostly it moved identity to a session key quickly verified. My initial setup was to expire the sessions every day, but that lead to the iOS app forcing a login daily proving to be an annoyance.
OAuth
I posted a question on an iOS board and received a blunt direction towards OAuth. My research of OAuth began but holy sh*t is that complicated and there does not seem to be any server side examples... just plenty of people complaining about how frustrating it is. All the client examples show connecting to Google, Facebook, Twitter, and LinkedIn. Oh Joy!
After watching Eran Hammer's rant about OAuth1 and OAuth2, it seemed fruitless to continue and his OZ idea (which looks really clean) is only at the early stages in node.js.
Question
So, my question to the broad StackOverflow community is... what do you do for securing your REST APIs?
I'd suggest to consider approach used by biggest players i.e. Amazon Web Services or Windows Azure - HMAC. Although it isn't comfortable in implementation, as you can see it's trusted technique.
The general idea is to sign the request's parts (i.e. headers) in the iOS with secret key and try to recalculate it on the Play app to verify that request is authentic and not manipulated. If it won't fail, you can be (almost) sure, that was sent from somebody, who uses valid secret key.
Take a look into Windows' document to get the concept (I think that for common task, you can use the less number of elements used for signing).
There is also other interesting post (based on AWS authentication) which describes whole process even better.
Edit
Of course you should realize that authentication in iOS and securing API requests are different things, even if you'll expire your session every 15 minutes, you can't be sure that somebody won't overhear it and then will be able to send a fake request from the outside. Signing every request should minimize the risk.
On the other hand, if you'll prepare clear rules for signing the requests and will write short doc (which I recommend even for yourself), you can deliver it to the other developer and he'll be able to implement it in (almost) any platform supporting SHA256, so you will have API ready for using from 3-rd party apps - if you'll decide to publish it in the future.
Since Play Framework is in Java, you could use Apache Shiro
I haven't used it yet.. (I am planning to though) So I don't know if it's the best option.
Just do something simple, send the authorization code / password in a custom header over HTTPS .
So the only problem with the Basic Authentication approach was that the user has to login every day? Why not offer the user an option to save his username/password on the device? That way he can choose between security and convenience.
Hi I am using CAS for SSO. But problem is that i want reset password,register new user on CAS login screen.Does CAS provide these services or i have to implement?
Or Any other SSO solution exist which fulfill my requirement.
CAS is just a SSO frontend to your existing identity management solution (database, LDAP etc). It does not include any identity management features itself (create user account, reset password etc). I have recently been using the Cloudseal platform which is a full identity management solution and so far I am pretty impressed. I believe Atlassians Crowd also includes this although I have not used it. There are probably other products out there as well.
Both of these are commercial products although they are both free for the first 50 users. Crowd is a traditional standalone platform which you download, install and configure but Cloudseal is a hosted service so there is no installation and less config.
You can certainly modify the spring weblog and login page to allow for the functionality that of course you'd have to implement. You should also ask the question on #cas-user mailing list to see if a similar need in the community has been implemented by other users which you may be able to take advantage of. I remember only recently someone raised the same question to the list and there was a bit of interest in getting this feature developed and integrated. You may want to revisit the topic on the mailing list.
Hope this helps.
I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.