I am developing an integration with REST Api with yodlee, and I am worry about security considerations, and would like to hear about the best practices concerning security with the server that talks with yodlee via REST API.
There is a method that returns the users password in plain text, getLoginFormCredentialsForItem()
This worries me a lot and I see that I have to isolate this server with the application server.
Do you have any recommendation to confront this scenario?
Thanks for your feedback on this. I've reviewed this with our Yodlee Security team and they've provided the following response:
The Yodlee Platform stores consumer credentials in a reversible format so that we can use those credentials on behalf of, and as authorized by, the consumer in order to retrieve their data for use by the application. Yodlee has enacted multiple layered security controls as defined by US banking regulations, industry standards (e.g. ISO2700K, PCI) and good industry practices to protect these credentials and the data retrieved by them. When Yodlee deploys with a client, access to the APIs are restricted via network and API level access control lists to complement our and our client’s security controls. However, in this Developer Portal, all APIs are white-listed so that developers can explore the full feature set of the Platform.
We're a longstanding platform with over 10+ years of security and bank-level data audits under our belt and we do not take these or any security concerns lightly. As part of our audit process, we will review the need and use of this particular API and make the appropriate determination whether to modify or remove this API completely from use. We thank you for bringing this concern to our attention.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
I recently entertained the idea of developing an app that aggregates Instagram data of a small community and displays it in different UI clusters, derived by certain analytics. While the API provides all the required endpoints for my requirements, I started re-inventing the app over and over again, to satisfy the Instagram platform policy, terms and conditions as well as the login permissions for the different scopes.
According to Instagram API documentation there are 3 categories for the scopes of all apps:
To help individuals share their own content with 3rd party apps: basic
This use case is meant for apps that allow the general public to login with Instagram to get their own content; for example, an app that allows people to print their own pictures. Apps that fall into this use case will only have access to the basic permission.
To help brands and advertisers understand and manage their audience and digital media rights: basic, public_content, comments, relationships, likes, follower_list
This use case is meant for products that don't have a public facing login integration, but are gated to brands and advertisers. The product must support either multiple brands and advertisers (e.g. a social media management platform) or multiple users within a single brand or advertiser organisation.
To help broadcasters and publishers discover content, get digital rights to media, and share media with proper attribution: basic, public_content, comments
This use case is meant for products that don't have a public facing login integration, but are gated to broadcasters and publishers. The product must support either multiple broadcasters and publishers, or multiple users within a single broadcasters or publisher organization.
Ideally, my app would benefit as many analytical endpoints as possible, particularly if I can process the list of followers and public content. This means my app should fall under group (2). However, the target community of this app was not consisted of brands and advertisers. Group (3) is also not an option, since my community is consisted of individuals. Then I was thinking that group (1) will fit my needs. But that was also not the case, since according to platform policy, I won't be allowed to put the media in different UI clusters:
You cannot replicate the core user experience of the Instagram apps or web site. For example, do not build a media viewer.
Then I started comparing the use cases with existing live apps. I noticed that if they would carefully follow the terms and conditions, as well as platform policies, they would also be unfit for all rules imposed by Instagram. Let me provide examples:
minter.io (broadcasters == individuals?)
minter.io focuses on Instagram analytics. Thus, it falls in group (2). However, anyone can register on this system, meaning any individual that owns an Instagram account. How is this a valid case when brands and advertisers are not gated? Furthermore, even if those are somehow filtered in some future phase (which they claim they do manually), why is it allowed to generate a report of a "competitor" account, when the ID of that account could be any individual, and not an advertiser?
pikore.com (discover / search function?)
Apart from having the similar issues of minter.io, where everyone can login, I fail to understand how is it possible for pikore.com to provide a "discover" functionality which is exactly what Instagram offers on its mobile apps? Is that not breach of platform policy? Or the fact that it is also able to display all media items of a given account mixed with advertisement? For example: pikore.com/arianagrande. This breaches also other terms stated in General Terms of Platform Policy:
24. Add something unique to the community. Don't use the Instagram APIs to replicate or attempt to replace the functionality or essential user experiences of Instagram.com or any of Instagram's apps.
25. Respect the way Instagram looks and functions. Don't offer experiences that change it.
26. Don't attempt to build an ad network on Instagram.
ElseWatcher (another media viewer?)
I absolutely adore this app. But the fact that the Instagram data is organized by location and date, it seems to me that it's another media viewer with extra functionalities.
socialbakers.com (free social tracker?)
socialbakers.com, while providing an amazing interface, it requests public_content scope for any individual user of instagram.com. On top of that, without providing any mechanism to gate the broadcasters, offers their services as "Free Instagram Analytics Tool".
Maybe I am wrong, but the way I see it, the Instagram API rules, are not applied consistently to all 3rd party apps. Can anyone explain whether those are inconsistencies indeed, or whether I got things the wrong way?
While at it, I would also like to know how is it possible to have the term clause "1. Instagram users own their media (stated here) in conjunction with "17. Don't apply computer vision technology to User Content, without our prior permission" (stated here). Does that mean that if I am an Instagram API user that agrees to these terms, and I perform computer vision on any image that also happens to be on Instagram, that I am breaching terms?
Have you seen this cases?
simplymeasured.com/freebies/instagram-analytics
pro.iconosquare.com/pricing
websta.me
unionmetrics.com/free-tools/instagram-account-checkup/
After June 1st all Instagram 3rd party apps should pass a review. The review should contain video screencast with
Provide a link to a video screencast showing the experience in your
app. Please show how your integration uses all permissions you are
requesting, any interface to moderate content or getting rights to
media, and any Instagram login experience. Since your app may be in
sandbox mode, you can use data from sandbox users to showcase the
integration.
I think, Instagram wouldn't have approved any app which violate their rules.
This might be more of an industry question rather than a specifically technical one, but the answer must consider the technical feasibility. I've tried to make the question as pointed as possible. I am working on a new web application that must protect social security numbers, bank account transactions, etc. Security is essential, as is the appearance of security. The company I work for, however, is small. Does it make sense to rely on third-party issuers (e.g., Google, Facebook, Twitter, Yahoo), which are certainly popular but as social media do not convey the seriousness of, say, the banking industry? Or can I realistically expect to implement OAuth/Owin/Katana as securely as these third parties? Is there another option that is both reliable and popular, without being driven by social media? Or does it make the most sense to implement security myself? I do not have a heavy security background, but am willing to learn it if forms authentication makes the most sense for my situation.
Your question is not specific enough to give you concrete advise. But creating your own security is never a good idea.
Whether you should use social media identity providers depends on how much you need to be certain of the user's identity. If the user has to enter all that information him/herself, then you only need to make sure that only that account has access. A social media account will work fine in this case. You can't be sure that the user is who he says he is, but that does not matter as he can only see information he entered himself.
If however this SSO and bank transaction info is coming from another source, you'll need a identity provider that gives you more guarantees about the user's identity (for example the bank's logon server)
This is linked to this question which seems to have asked a while back. Security implementation in a project that is adhering to basic principles of Domain driven design. let me give an example
Banking System:
Use Case: A new bank deposit is being made and requires approval as it is first deposit
a. Clerk can auto authorize if the deposit amount is <5000
b. Manager can be of two types - Bank manager / Account Manager. ONLY Account manager can authorize any accounts that have deposit >5000
My concerns are as follows (Pls correct if the concern itself is correct)
Not sure where should i build this following logic - takes care of checking whether the logged on user has authorization to do certain things taking in to account his title - (this case Account manager). Authorizing is a use case, but the security layer seems to have intimate knowledge on the domain object
In general Authorization (not authentication). I know that Role Based authentication would help, but the question is "where" - in which layer and the call flow. Should the UI layer call on some security layer or would the domain layer validate itself for all possible combinations ?
Please help. Its very confusing.
Bump to see if this gets experts notice
Cheers
Security is a cross-cutting design feature which can affect all classes, methods and properties.
From a DDD perspective you would go with specifications and roles.
Where and how those specifications get implemented comes down to your architecture. You could go with aspects, you could go with in-line calls, events, etc.
Here are some links I would check out regarding security and roles:
Security
Roles
RBAC
I am creating a web-page/website that integrates all my accounts into one spectrum, as in, from this page I want to use this page to log into my mail box online or any other site that requires authentication. All i want is a central login panel. enter my unname&passwd and get redirected to my mail. Is that an impossible question to ask?
It sounds to me like you want to consider using OpenId, which is a standard, fairly widely adopted form of single sign-on. Used by this very site, in fact, and supported by at least two of the three companies you mentioned: yahoo and google. Hotmail does not currently support it.
It completely depends on the individual service. You'll have to investigate each service to see if they even allow you to authenticate against their servers remotely. In the event that they do allow it, it's still up to the service whether or not you'll be able to retrieve any kind of information from them after logging in.
Banks in particular are very unlikely to give you any way to interface with them and the ones that do will likely require a monthly access fee.
You want to look into SAML, an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.
With SAML, you can communicate between the major single sign on (SS0) technologies like CAS, OpenID, Shibboleth, AD/LDAP...
I am considering adding OpenID to our customer facing admin and control panel areas...
1 - Associating OpenID's With Existing Accounts
For customers that already have accounts with us, I'm thinking they would need to login using their existing account number that we issue and then I'd have a mechanism to associate their OpenID with that account in their account management area (call it 'OpenID Manager' for the sake of argument).
In the 'OpenID Manager', presuming the user already has an OpenID, would I authenticate the user against their OpenID then associate with our generated account number for future OpenID logins (assuming that they authenticated ok)?
2 - Sensitive Data
Although we don't store full credit card data in our DB there is other data that is sensitive, invoices, domain reg details etc. After reading this article http://idcorner.org/2007/08/22/the-problems-with-openid/ I'm a little cautious about the idea of using OpenID in this way, what's the general consensus with you folks?
It seems to me that a lot of the arguments against OpenID are either made out of ignorance or by people with an axe to grind.
For example, the document you link to complains that identifying yourself with a URI is "dehumanising and more than a little frightening". Is that a legitimate complaint, or something written by somebody desperate to find things to complain about?
The two major things that get brought up are phishing and compromised accounts and these arguments have been rehashed so many times, it's hard to take somebody seriously if they bring them up yet again with no new points to make.
Phishing protection depends on the provider. Some providers offer much better security than typical websites ever would. Some providers just offer the typical username and password. Either way, if an account is compromised, that's something between the user and their provider, it's not your concern. You don't worry that the end-user has a keylogger installed on their computer, do you? That's because their local security isn't your responsibility, even though it might be used to gain access to their account. Likewise with OpenID - its security is not your responsibility.
If you compromise an OpenID, it gives you access to more than a single website. Sure, but the same is true for email. Just say you've forgotten your password, and you get sent a new one. You now have access to every account they've registered with that email address.
OpenID is no worse than the status quo, and it's significantly better in many circumstances, especially for informed users. If you are still wary of it, then just make it optional, so only the informed users use it.
I'd allow the registration of multiple OpenIDs with a particular account. That's a nice feature to have because it allows users to migrate between OpenIDs should the need ever arise.
That said, the idcorner link raises a good point. I think he massively overblows the security issue and makes many idiotic assumptions about how OpenID providers work, but that OpenID really isn't intended to replace all forms of user authentication. It's designed to make it easy for "drive-by" users to interact with a site with some form of basic authentication.
Ever been to somebody's blog, want to post a comment, but first you have to step through a 3-page registration? OpenID solves that problem.
Want to post a quick bug report on a public tracker but need an account first? OpenID to the rescue.
Want to store sensitive proprietary data in a web-accessible way and provide access only to people who are trusted? OpenID is not the solution.