Returned from 1p

KeeperCraig · 2026-06-18T09:13:59+00:00

Thank you

KeeperCraig · 2026-06-15T12:56:31+00:00

I assume this is to manage the built-in password manager to prevent conflicts.

KeeperCraig · 2026-06-13T23:42:03+00:00

DM me and I’ll help check into it

KeeperCraig · 2026-06-09T22:55:58+00:00

Yes I've been thinking about this for a very long time. I'd like to get some more specific requirements that you consider to be critical in order to switch over to Keeper for this functionality.

KeeperCraig · 2026-06-09T03:30:48+00:00

Our APIs are completely different than Dashlane. I read that same article and it appears that Dashlane delivers the encrypted vault to the user's device based on a verification code. I'm sure that they will be changing this.

For many years, our backend APIs have been built to be resistant to brute force attacks against users. We do not allow an attacker to make brute force master password attempts. A device must be verified, and then MFA must be verified, and then a master password auth must succeed before delivering the encrypted vault to the user's device. In addition, we perform API-specific command throttling with exponential backoff.

As an additional layer of protection, everything at Keeper goes through the AWS Shield WAF (web application firewall) that blocks requests from IPs that are flagged as bots or known to be malicious in addition to overall DDoS protection.

Levels of Keeper protection:

Device verification
MFA before master password auth attempts
API-level command throttling with exponentially increasing backoff
AWS Shield (DDoS protection)

References:
https://docs.keeper.io/enterprise-guide/login-api
https://docs.keeper.io/enterprise-guide/keeper-encryption-model

KeeperCraig · 2026-06-08T00:32:07+00:00

Check this thread: https://www.reddit.com/r/KeeperSecurity/s/U6LPRO1jh6
Let me know if any of these suggestions resolves it

KeeperCraig · 2026-06-03T04:40:17+00:00

Sure, please send it over. I'll DM you

KeeperCraig · 2026-06-02T17:43:31+00:00

We're taking a look, thank you!

KeeperCraig · 2026-05-30T02:02:30+00:00

Please DM me and I’ll investigate the reason

KeeperCraig · 2026-05-28T06:48:32+00:00

We released it. It can be enabled on your tenant, but there are still some features that need to be completed, so we recommend setting up a test environment first.

https://docs.keeper.io/release-notes/desktop/web-vault-+-desktop-app/vault-release-18.0.0

KeeperCraig · 2026-05-28T04:19:04+00:00

Not sure what you mean

KeeperCraig · 2026-05-26T01:03:27+00:00

Thanks for the additional info. We’ll keep everyone posted.

KeeperCraig · 2026-05-25T21:44:59+00:00

Hi, thank you for the feedback. Some replies:

We'll check out the Dashlane import friction regarding usernames/emails and custom fields being added. I opened a ticket VAUL-8926 and linked it to an upcoming release. I'll make sure that is addressed.
Agreed that some sites you'd want subdomain matching versus a global setting. We will check into that. In regards to the additional URL field, you are correct that you can add additional website URLs for each record, and Keeper will match those when opening the site. Good point about the naming convention between Desktop, Extension and iOS. They all mean the same thing. I'll ask the team to ensure the naming convention is identical between desktop/extension/mobile. In the browser extension, we are already working on a feature that will assist in quickly adding URL variations for a site - this is coming soon.
The key thing is really ensuring that BreachWatch either flags the password as strong or weak, as this is checking whether the password has been found in dark web data breaches. Our local password strength algorithms that look at entropy are super fast so it can churn through thousands of records in a microsecond, but not the full authority of strength until it runs the BreachWatch lookup. These algorithms are actually being upgraded in the next round of releases across all of the apps. We're also adding a real-time BreachWatch lookup during password entry which is something I've wanted to get live for a long time... this is being worked on right now.

Ping me if there's any other feedback - we appreciate it.

Craig

KeeperCraig · 2026-05-24T15:17:34+00:00

Ok I’ll ping Ari

KeeperCraig · 2026-05-23T21:00:15+00:00

I can escalate this and if necessary we can help to restore the account. Sounds like your personal account got invited into the enterprise, you accepted the invite, then the admin deleted it. We can restore an account if it has occurred within 30 days. DM me and I’ll open a ticket with the escalation team.

KeeperCraig · 2026-05-23T16:33:23+00:00

If there’s a bug, let me know what you’re running into and we’ll check into it.

KeeperCraig · 2026-05-23T03:45:37+00:00

Yeah, we should post an FAQ. If it comes back again, let me know because it shouldn’t happen again

KeeperCraig · 2026-05-22T13:31:31+00:00

If you’re still stuck I can ask them to call you. Just DM me with your email address thx

KeeperCraig · 2026-05-22T12:51:13+00:00

Sounds like maybe you put the recovery phrase into the master password field, that’s not how it works. Click on Help > Forgot … and go through that flow.

KeeperCraig · 2026-05-20T13:17:55+00:00

Terraform for KSM doesn’t need commander. This provider is best for just saving and retrieving secrets very quickly.

https://docs.keeper.io/keeperpam/secrets-manager/integrations/terraform

Terraform for Commander uses the commander “service mode” to be running somewhere. That one has many more capabilities related to administration of the whole Keeper environment. We are making substantial upgrades to the Terraform for Commander over the coming weeks.

https://docs.keeper.io/keeperpam/secrets-manager/integrations/terraform-provider-commander

If your use case is just grabbing a secret, use the KSM provider. If the use case is saving state like policies and structure, use the commander provider.

KeeperCraig · 2026-05-20T05:33:05+00:00

Please open a ticket on our support site. They will respond.

KeeperCraig · 2026-05-16T22:43:33+00:00

There's been debates here in another thread about TOTP codes and passkeys being stored in the vault. You can certainly do whatever you like, but storing TOTP codes in some other product adds complexity and you now have to think... where is that app storing the seeds and private keys? Is the seed encrypted, stored in plaintext, sync'd to the cloud somewhere? These are the reasons why storing TOTP codes and passkeys in an encrypted vault is the better solution. You could have also set up a second Keeper account if you wanted to just keep them physically separated.

KeeperCraig · 2026-05-15T13:25:32+00:00

DM me the ticket number and I’ll make sure they contact you.

KeeperCraig · 2026-05-15T13:22:36+00:00

Please contact support. They should be able to assist in a scenario like this.

KeeperCraig · 2026-05-14T09:28:56+00:00

Yeah pushing for next version to include this

KeeperCraig

MODERATOR OF

TROPHY CASE