Good evening,
I have a client who needs a secure portal for a customer to submit sensitive info (SSN, W9's,etc.) that will integrate with Salesforce. Docusign seems perfect for this but we want to ensure the encryption during transmission of information meets SOX requirements. Can anybody confirm the type of encryption that docusign uses both in storage and in transmission of data? Thanks!
Yes, DocuSign is used by customers for SOX-compliant workflows/use cases. Consult your DocuSign account exec or SE for more information for your compliance/audit team.
Related
as a follow up to the twitter conversation here https://twitter.com/johannwalder/status/854791427871694848 is it possible to use our own encryption keys for the DocumentDB encryption at rest?
I have found the following answer "We are working on providing capabilities for customers to bring their own encryption keys." about storage service here https://learn.microsoft.com/en-us/azure/storage/storage-service-encryption but not sure if the same applies to DocumentDB as well.
Thank you!
Best regards,
Johann
Johann - DocumentDB is delivering "Encryption at Rest with Service Managed Keys." As PaaS service we have done all the heavy lifting of managing keys and keeping them secure. We have also worked with auditors to ensure we are PCI compliant as are customers using our service. I mention this because many customers ask for "Customer Managed Keys" as a proxy for meeting compliance requirements like PCI.
Happy to discuss any of the topics around Encryption At Rest (E#R) more in the coming ~week I'll be posting some detailed documentation. Until then ... happy computing and thanks for using Azure DocumentDB.
Anthony F. Voellm [Microsoft Developer]
For context I'm the lead developer delivering the Encryption at Rest feature for DocumentDB.
I'm thinking of using an MBaaS such as Firebase or Kinvey for my next app, and am wondering if any exist which encrypt application data end-to-end (i.e. such that the encryption keys are never shared with the service provider). This seems feasible in theory, since the server is not expected to do any computation on the data, only store it and deliver it to clients.
Does such a service exist? I've found ZeroDB and Crypton, but neither are available as services AFAICT, which means I'd have to administer, scale, and back them up myself. I also thought of using something like Firebase and encrypting my app's data before I pass it to the Firebase API, but I'm wary of writing a one-off crypto layer like that unless I have to (i.e. I'd rather use something that's been peer-reviewed).
Alternatively, if no such service currently exists, why not? Is it technically infeasible, or is there just no market for it?
Edit: This seems closest to what I'm looking for, but considering the broken links on their website I'm guessing it's defunct: Adreneline Mobility
The answer to your question is actually available on the market. CloudMine offers end-to-end encryption (disclosure - I work at CloudMine). They have a largely healthcare focused offering so it has to stand up to HIPAA and other government regs around data security.
Here's a good overview video on security featuring CloudMine's CTO. The first 45 sec. provide some more information on our encryption techniques.
I know I'm being the "sales guy" right now but I'm happy to hop on a call to share what we've built and discuss your specific use case. You can email me at nick at cloudmineinc.com if you're interested.
Virgil Security (full disclosure - I work there) has an end-to-end encryption SDK that works for any endpoint, and also has a special integration with Firebase. It's open source, of course. Check it out and feel free to ask any questions of the team here or on Slack - https://e3kit.readme.io/
All,
OpenStack API issues token after successful authentication. However, it is only valid for 1 hour.
Is there any workaround or possibility to extend token's lifespan?
Thanks & Regards,
Ganesh.
You may want to take a look at the solutions used by Heat, the OpenStack orchestration engine.
Heat needs to be able to execute actions on behalf of a user at some point in the future. Heat cannot simply store a token because, as you have stated, tokens expire.
Heat offers two solutions to "deferred authentication".
Keystone Trusts
Stored passwords
There are lots of details about how Heat handles this here and here.
There are some API examples of keystone trusts on the eNovance blog, and some more over here.
I'm starting to use Paypal SDK to implement the payment service for a ASP.NET site. I wrote the code following the SDK example and everything worked fine, of course I'm managing the whole process (credit card data entry and submission included). The site owner however complained about credit card data management and thus asked me to re-implement the whole procedure without managing the credit card data 'internally' at all but leaving Paypal doing this part of the job.
This mean that NO data of the credit card should be entered in forms belonging to the site I'm coding.
As far as I can see (but I'm just a newbie in Paypal SDK) there's not a way to do what I'm asked for using SDK API calls.
Given my lack of experience I'm not sure about what I'm stating then I can only suppose that I'm missing something so... there's a way to do so trough API calls?
Best Regards,
Mike
What your site owner is likely asking you to do is to leverage PayPal's Vault API (part of its REST APIs) to store credit card information so your site doesn't have to. If you store the credit card information on your site, you have to ensure the data is stored in a PCI-compliant manner, which may be too costly for some sites. The Vault API will return a credit card token that can only be used by your REST application for making payments. The API also allows you to get the details of the credit card using the token, but will mask the full credit card number.
There are some examples on how to do this in the PayPal .NET SDK Samples. If there's a use case that's missing, feel free to let us know over on GitHub.
PayPal basics for ASP.net c#
http://www.codeproject.com/Articles/42894/Introduction-to-PayPal-for-C-ASP-NET-developers
http://www.codeproject.com/Questions/718003/How-implement-Strong-cryptography-with-associated
http://forums.asp.net/t/1977404.aspx?Integrate+with+Paypal+account+within+Net+project
http://www.west-wind.com/presentations/PayPalIntegration/PayPalIntegration.asp
I have to integrate Docusign with my ASP.Net web application.In our application there are many companies and each company has Administrators and Users.I want to clarify something related to Integrator key required in below mentioned scenarios.
1)If only administrators are allowed to send documents for signing to other users.
In this case,do all the Administrators need to have separate Integrator key for sending documents for signing?
2)If all users are allowed to send documents for signing to other users.
In this case do all users of my application are required to have separate integrator key?
In short I really want to know how users can be managed with Integrator key?
Would it be 1 such account per Company, or 1 per initiator within a company?
Please suggest.
It's actually none of the above. A DocuSign Integrator Key is similar to what other APIs call their API key (Google for instance). It is used to identify a given DocuSign Integration, so you actually only need 1 Integrator Key for your entire integration. You can think of it as a "per app" or "per integration" key, not per user.
See this page in the DocuSign Dev Center for more information.