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.
Related
As the title states, I've gotten this email for both projects I've made public on Github. One is a landing page for a local business and the other is a CRUD app I have on the App Store; both of which are using Firebase as the backend.
Is the API key being visible on Github such a security risk?
I've done some research after following the instructions in the email to restrict my API and have heard that you cannot make web service requests with a restricted API key.
I just want to show my repos for the projects for the application process and obviously don't want anything bad to happen with them by doing so.
Aren't Firebase APIs meant to be public?
If so, is it just my database rules that need to be stronger/more verbose?
If any more context is needed, please let me know!
Cheers!
NOTE: I'm still very new to programming so a lot of this is over my head
For Firebase apiKey in a web app you are intended to make this key public, so you should ignore this email -- see: https://stackoverflow.com/a/37484053/771768
Hopefully Best practices for securely using API keys helps.
I'm uncertain as to what you're doing specifically that's resulting in the email but it is warranted.
Please be very careful with API keys.
As the name suggests, these are like keys in that they unlock access to stuff. With digital keys, the additional challenge is that, once obtained, infinite copies of the key may be distributed (and these are usable until the API key is revoked).
There are (often) other (complementary|alternative) ways to authenticate APIs but, as I think you've discovered, sometimes you are required to use API keys.
In the case where they're required, you should endeavor to use complementary authentication mechanisms too in order to try to mitigate overuse and you should continue to be very judicious in your publication of these keys.
I suspect you should not be including (any) keys (ever) in your GitHub repos.
One rule of thumb is that vendors (like Google) use API keys as a way to limit access to (often paid) resources. If the vendor is giving you a key, they're often (not always) using the key as a way to determine how to charge you for an API too. If you're giving the key to others, you're giving other people the possibility of potentially incurring charges on your behalf.
I don't wish to scare you but I would like you to leave this question being very cautious when using keys even if only this causes you to read up more on the consequences of using them.
I am looking for sample Corda code (kotlin/java) for permissioning. Please let me know if you have any pointer. Thank you.
Corda is built on open standards, for network membership it relies on standard PKIX infrastructure for connecting public keys to identities (the identity of a node is an X.500 name). Please take a look at the ‘Network Permissioning’ section of the docs - you can use standard tools and procedures to manually create, sign and distribute certificates to Corda nodes.
For production deployments of Corda please plan to use Corda Enterprise - this will give you HA, DR, performance and other enterprise capabilities as well as enterprise-grade Doorman.
For our messaging app, if we send user messages directly to CloudKit (without doing any of our own encryption), can we claim that our app is end-to-end encrypted, "where only the communicating users can read the messages"?
Matt,
I presume/assume this is a coding question? So I'll answer with a coded answer :)
You can offer your guarantee that messages are only readable by communicating users by encrypting the messages using public/private key pairs. Technology that has been around for more than a while now. This discussion talks in detail about the process.
Search for "Swift RSA Public Key Encryption Howto" on https://forums.developer.apple.com forum.
I know this is an old and somewhat controversial question, but I thought I'd lend my two cents on the subject.
After some quick Googling, the most authoritative public and user-facing answer to this question I've found is on Apple's Privacy page. See the section on iCloud, which reads,
Your iCloud content [...] is encrypted when it’s transferred and when it’s stored on our servers.
It then talks about CloudKit.
That sounds pretty end-to-end-ish to me.
However, they go on to state that "some personal data, such as Home and Health data, is stored with end-to-end encryption." This contrasting passage does not bode well for your "We're end-to-end encrypted!" requirement, unless the quote above suffices for your purposes.
For my own present project, it does, as my data isn't necessarily business-class levels of sensitive; I don't need full control over what and how everything is encrypted. My biggest concern is that I, the developer, cannot see my users' data. This, CloudKit enforces for me, whereas tools like Firebase do not.
That is all.
Happy Googling! 😊
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/
I have read some text about WS-Fedaration but i can not understand it. I have some questions :
What would happen if there were no WS-Federation?
How does it help to Single Sign-on?
What is the difference between WS-Trust and WS-Federation?
I just want answers in a very very simple and understandable samples in the real world!
I have read a lot but i can not understand it deeply
Thanks
The relationship between ws-trust and ws-federation is that ws-federation is built on top of ws-trust. This is very technical and frankly, despite using ws-federation for years, I still am not sure where ws-trust ends and ws-federation starts. I believe this is not very important.
http://www.empowerid.com/learningcenter/standards/ws-trust-fed
To understand the idea of tokens and trust, think of an airport (which would be an application) and you as its user. You want to authenticate there. Normally, you'd have to somehow prove that you are yourself. A dna test perhaps?
But, wait, you were authenticated before, in a passport office. They somehow validated that you are yourself and issued a passport to you. The passport office would be the authentication server and the passport would be a SAML token.
By presenting the passport at the airport (by showing the saml token to the application) and by the trust relationship (airport trusts that legitimate passports truly identify people; the application trusts that saml token signed with a correct certificate prove that the user has been authenticated) the airport (the application) can authenticate you much easier.
This idea of trust and federated authentication means that more services can be built around the same authentication authority - and surely your passport issued by the passport office can be used not only at the airport but also at the hotel etc.
Normally the trust is established formally to specific passport issuers and specific document formats but in the digital world the trust is established easily - the authentication provider just signs the user information (the saml token) digitally and the integrity of the sign can be validated at the application side easily.
There is a great free book on that by Microsoft Patterns & Practices group available here:
http://claimsid.codeplex.com
i found some good resources that can help a lot.
Firs have a look on the below article.It is a little complicated it expatiate the WS-Federation in depth .
http://msdn.microsoft.com/en-us/library/bb498017.aspx
The second one is a resource that "Wiktor Zychla" helped me to find it. There is a great and legitimate source code alongside very detailed description. It can be pretty useful for understanding this issue.You can download it from this link : http://claimsid.codeplex.com/releases/view/68061
At the end, i perceived there is no cross-cut way for understanding WS-Federation, rather you should read it profoundly since it is such a very technical and abstract issue.
Hope to be helpful for you.