I'm implementing solution, using OpenIdDict library for authorization/authentication, for merchant stores. Now creating OpenIdDict application for every merchant, also every merchant might have multiple selling points(Android terminals). From admin side, I would like to provide functionality to administrate selling points, and at the point merchant creates new selling point, I would like to show them OpenIdDict client id, client secret, and uniquely generated selling point id in form of QR code, to have possibility of assigning new Android terminal to specific merchant. At this point came to problem, that I can't unhash OpenIdDict client secret. Also, it's not the case where I can share client secret with merchant in advance, as the Android application would be distributed through store.
Came to this thread https://github.com/openiddict/openiddict-core/issues/452, but I find implementing custom encryption/decryption logic a bit unsafe, it might contain security issues and should be supported later.
Would appreciate any suggestions, how to do it correctly, or how it's done in other systems.
Related
We are working on a system which retrieves data from customers' Shopify shops and provides some services based on this data. In order to make it as convenient as possible for an end-user we would like to update this data on a daily\weekly\monthly basis.
For now we only came up with a solution of implementing unlisted app, prompt a user to provide all necessary permissions for the app to access their shops and fetch the data. But the token we get doesn't seem to be valid for a long time and we probably won't be able to reuse it a day later.
We appreciate it if you can share any success cases of implementing this kind of approach.
You provide an App to the merchant they can install using oAuth. When the merchant is prompted to approve the App, Shopify will then provide your App with a long-lived access token you can use as much as you want, for as long as you want. I use a custom App from my Partner App dashboard to create these kinds of one-off Apps. It is superior to the one where the merchant has to tick off scopes and permissions IMO.
There are two kinds of token you can ask for and receive. One is considered for offline access, or long-lived. It works for everything. It is for webhooks as an example, or other access where no person is involved. But, there is also, online access tokens! Say a person clicks into the App from Shopify to do some work. You can request an online token for them to do their thing, and that token is only good for say 24 hours.
So you have options!
I'm currently running an online community, we're now launching another community and actually intend to launch several over the course of the next months. Each community has their own auth0 client, as well as other settings such as, which features are activated per community, what are their Twitter/FB accounts, which API should it connect to, etc.
Right now this is still hardcoded, now I'm thinking to retrieve this all via API but I'm not sure how safe this to retrieve these all from the client? Ultimately these things end up in the client anyway via the node environment variables, so it shouldn't make a difference, should it?
I was looking for official web API to operating with Bitcoin system, but found nothing.
Thank you in advance!
If you're fine with securing and running your own Bitcoin server and interacting with that, there's a guide at https://en.bitcoin.it/wiki/API_reference_(JSON-RPC). But if you're not comfortable securing your own instance of bitcoind, then you could always use a third-party service like Blockchain.info's API.
Please be aware that hackers are particularly targeting servers and websites that they think probably hold bitcoin. If you're thinking of launching a Bitcoin service, take a lot of time to educate yourself about the services that have lost their users' funds and what they did wrong. Take a look at Blockchain.info if you want to see a Bitcoin web service implemented well. Their servers never hold private keys "in the clear", so bitcoin cannot be stolen from their users if their servers are ever compromised.
Update: If you are building a Bitcoin service that holds bitcoin for users, the current "best practice" (circa June 2014) is to generate a hierarchical deterministic wallet using a random string of words as a seed and encrypt it client side with the user's username and password. At that point it's safe to send to the server for storage. The user should be shown the seed used to generate their HD wallet and prompted to write it down and store it somewhere safe. Without this string, it will be impossible for them to retrieve their wallet in the event they forget their username or password. When the user logs in later, the client-side code should grab the encrypted wallet and decrypt it again client-side. All operations requiring a decrypted wallet, such as signing transactions, should be done client-side. The server should never be exposed to the wallet "in the clear."
We're building a multi-tenant SAAS web-application. Our tenants want the option to accept credit card payments for the various products that we allow them to market through our application. To support this we will require that the tenant has their own Braintree account. The tenant provides us with their Braintree API keys through our app. We then use those API keys to interact with their Braintree account on their behalf (card storage, card verification and basic transactions).
This model is the same as the model used by the existing Braintree customers WooThemes, Goodsie, TutorTrove and many more.
We need to record the tenant's API info (merchant ID, public API key and private API key) for this all to work.
My questions are:
Can we simply store this information in our application database?
Does storing this information affect the PCI/DSS scope of us or our tenants?
If we can't store the information in raw form, what is an appropriate storage form?
Note: we have contacted Braintree directly with this same question, but we didn't think it would hurt to get other opinions as well :).
Cheers,
Sam
IMHO, Please note that you will be [if not, should be] having tenant based crypt keys [each tenant can configure their own crytographic algorithm and the keys => SAAS Cusomization], Please do encrypt the AuthorizationId using the tenant specific keys and then persist in the database. These kind of sensitive data should be secured and you should have a note stating that you are maintaining these keys in the database so that the tenant's can opt out if not required and manually enter the key whenever required. This will ensure safety. By the way is your application using SSL.
Please do share your thoughts on this suggestion
So Braintree responded to this question with:
So long as your system is PCI compliant, and your merchants are aware
that their API keys are stored on your server, then you should be
fine. How you store the integration API keys is completely up to you,
and [we] don’t really have any best practices to offer.
So, it doesn't seem like this case affects the PCI/DSS scope of our product, and it seems we are free to choose an appropriate way to store the private API keys that we obtain (saravanan's suggestion is one possible option).
My Passbook-related app was recently rejected based on guideline 23.3:
23.3: Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the app will be rejected and Passbook credentials may be revoked
I had a few questions and got on the phone with someone at Apple. They told me that to remedy my problem I could create a sign-up form in my application. This sign-up form could then be used to create a certificate and pass type ID for the user based on their credentials. However, I've been combing through the documentation and I've not found anything that allows people to create Pass Type IDs or Certificates without at paid developer membership. Is this correct, would my users need a paid developer membership to create their own Pass Type IDs?
If they don't, is it even possible to create a PassType ID at runtime? For example, using the information in the sign-up form I might make an API request with PassKit / some kind of Passbook server to create a Pass Type ID:
PassID *ID = [PassKit createIDWithName:#"USER_INFO"];
Is there anything like that or was the Apple technician talking about something else?
would my users need a paid developer membership to create their own
Pass Type IDs
As crazy as this sounds - yes! The only way of fully satisfying this guideline is to pay the Apple Tax and sign up as a Developer. There are several long threads in the Apple Developer Forums talking about the reasoning and implications of this. While it is not popular, the majority of us concede there are very good reasons for this, that in the long term, will protect the integrity of the platform (as well as keep the Apple lawyers happy in the short term).
The main reasoning is because in most jurisdictions; coupons, tickets, travel documents and other typical Passbook content create a binding obligation upon the issuer. Legally, in the event of non-fulfilment, the pass issuer is liable to the consumer. In order to protect themselves, Apple needs to ensure that under no circumstances, could they be deemed as the issuer of any Passbook pass.
The Apple Developer programme registration validates the identity of any individual or corporation who is accepted. It also forces Developers to sign the terms of the Developer Agreement which has an entire attachment dedicated to what you can and cannot do with Passbook and with your PassID certificate. This provides Apple with enough legal protection against any claims for unfulfilled goods or services relating to any Passbook pass.
While there has been a lot of pushback and calls for a faster, less US centric process (you would not believe how difficult it is to get a DUNS number for an small entity outside of the US), I don't expect this to change any time soon.
As for auto provisioning. Myself and the creators of the other major Passbook platforms have been calling for this since before iOS6 was launched. I have an open radar dated 7th August requesting a simple API to issue and revoke Pass Type ID certificates. I'm intrigued as to what your Apple Technician was referring to since as far as I am aware, there is no such service.
// rant
What is frustrating about this is that there are a number of approved Apps that allow full pass customisation but issue the passes under the App developer's certificate.
Apple also seem to turning a blind eye to certain services that issue passes under their own certificate that bear the logo and trademark of major brands (and then have the audacity to call on these brands to 'claim their passes').
Even Passtools (now Urban Airship) claim to offer a 'Unique Apple Developer Certificate from PassTools', which technically would be in violation of the Apple Developer Agreement.
So the bottom line is that on this occasion, you may have just been unlucky.
// end rant
I'm not sure what the technician was talking about, but 23.3 refers to a server (likely yours) going through a signing process with the pass before sending the pkpass file to a device.
For high level information, review the "signing and compressing the pass" section of the passbook programming guide.