artjomb
Mitigation is also not really possible when using SSO. One way would be to require the target service to require a second factor in addition to a valid SAML token, but then each user needs to keep current its second factor, whatever it might be, in each target service. This get unmanageable quite quick not to mention that there are basically no SaaS or self-hosted applications out there that support SSO and a second factor at the same time.
Bitwarden's API likely doesn't permit anybody to access the encrypted blobs of anybody. You have to authenticate at the server to be able to access your blob. Since the iterations might be low for producing the master key and therefore the master password hash, the server must treat the master password hash as just another password and therefore iterate the hash quite often (100,000x).
Assuming no malicious insider or an outside attacker gets their hands on the encrypted blobs this is the most important attack prevention.
These are reasonable questions and I see quite a lot of value if they are filled out extensively and in a good faith approach. Most of the answers of usual security questionnaires can be deduced from the responses to this DSQ.
I really have a problem with Q6:
> Have you had any security breaches in the last two years?
> If yes: please explain the breach, and provide copies of any postmortem/root cause analysis/after-action reports.
Almost nobody will answer this truthfully. I see a couple of options: 1. There was a breach and it was public, then why are you asking. Do your research! 2. There was a breach and it was not made public. The company will likely not admit it to you. 3. There was a breach but it was a) not relevant to your case/b) internal/c) the data lost was not customer data/d) we forgot that there was/etc.
While lying in case of 2. might make the vendor liable (IANAL) they might be able to argue that 3 was actually the case.
I find the graphs without much meaning. I live in Germany and we didn't have a strict lockdown where you would get a fine for doing non-essential outside activity. In April cultural and fitness were closed. Therefore the only way to do something is to go outside.
The interesting thing would be to understand how many other people you were meeting with which I would think that data does not provide. I mean Google likely has that data but didn't anonymize it in order to release it.
Meeting more people than allowed and not covering your mouth and nose is something that was spot checked and still is.
Of course the software should be able to detect that there is no fingerprint and require the operator of that software to check for the identity by other means.
Sometimes we don't always have human operators and more things are automated.
That's great but what are the approved ways? This does not prevent access to customer data. Is there and built-in audit functionality to see accesses that were approved and done/attempted? This would also need to be implemented in all levels of the stack.
This basically means that AWS closed a compliance issue through technical control at the lowest level.
So this basically means that the .odns operator is yet another entity that can scoop up some domain names. The one privacy advantages that I see in comparison with using Cloudflare or others as DoH providers is this: .odns operator can only group the domains that they see to a resolver of the ISP of the user. Cloudflare could group domains by IP address of the user.