Ivarson

When you're setting up sync for a vault in enpass for Android, you don't need to enroll the whole phone with that account. You'll be redirected to the Google Account page in Google chrome, just make sure to "login with another account", entering the credentials for the shared Google account. Once the sync is ongoing, you can logout from that account in Google Chrome (account.google.com) so you're not accidentally use it for other stuff when surfing. If you're insecure of this, you might consider using a Dropbox or Microsoft account instead. The shared account (whichever provider) should be used only for the shared enpass vault (IMHO). Also, make sure to store the credentials for the shared vault in both yours and your wife's _primary_ vault, so it's not being lost in the shared vault (catch 22)

Any news on this @Amandeep Kumar? Also tried on: Kali Linux Enpass 6.10.1 Chrome 127.0.6533.99 Still doesn't work. I was able to create a PassKey in Enppas for Android android, but obviously can't use it on desktops. Is LinkedIn enforcing hardware-bound passkeys that Enpass is unable to process?

That's fine, but can you at least confirm that there _are_ plans to upgrade it?

Upgrade portable already. It's way behind

Workaround confirmed working. Is this something that can be addressed from Enpass side or do we have to wait for Google to sort Chrome out?

Only text and images has the open-option in enpass (if I remember correctly) so having only Save for a pdf is expected, should apply whether an item was imported or created originally in Enpass. The limitation for pictures and text is due to enpass not wanting to dump the file outside the app, since it might be left in a temporary folder or cached in a external application.

All of a sudden, webauthn (passkeys) requests in Chrome are not being redirected and picked up by enpass. Chrome 125.0.6422.72 Enpass 6.10.2.986 Android 14/Samsung a54 Passkeys still works in (the few) native Android apps that supports passkeys.

I know, it's supposed to :-) I was asking about how the shared data _looked_ like, when you could share without AES-256 encrypting it. Pretty sure it was plaintext fields on each row, and a .ENPASSCARD-file with non-encrypted base64. anyway, wouldnt a "Copy All"-option sort your needs? The clipboard would contain all populated fields in the item, and would be intended for human-to-human sharing or external copying. (base64 is in essenence made for normalized transportation) --- Title: XCV Username: XCV Password: XCV Website: <URL> --- i also recall talking to enpass support one or two years ago about a web-based service for external password sharing, and they were "working on it" something like Bitwarden Send or Lastpass password sharing where you could have either password- or limited accessattempts on a generated weblink, not sure if that took of or not.

I was asking about the per-item 'Share'-function, not the 'Export' and how the non-PSK shared data looked like

I dont remember what the unprotected sharing looked like, but think it was All fields in plaintext, and a enpasscard in base64? @Amandeep Kumar If you want the Share-function to be a secure Enpass-only thing where there are no shared vaults involved, you could instead add a "Copy All Fields" for the items (you already have Copy Username, Copy Password, Copy URL, Copy OTP, Copy Email.. adding a Copy All wouldn't reduce security _that much_, possibly the fact that all fields resides in clipboard at thesame time, but atlest the clipboard would still be protected by the builtin timer that wipes records after some time by default. As a sidenote, in the Windows-app, there's a Print function where Enpass generates PDF-files. This can be used in some cases, but it's clunky, the content cant be highlighted and copied from and so forth, but if you want to share several fields at once, and the password isn't too long and complex, you can select an item, hit the Burger-menu (not the items three dots) -> File -> Print -> selected items. Then make sure that "Microsoft Print to PDF" is selected, which creates a local PDF instead of going to a physical printer. Due to a glitch i guess, the "selected items" is only available if you're viewing ONE vault, when All Vaults are selected (i.e you have many vaults) you can only select ALL ITEMS. I dont recommend the print-thing as a sharing-concept, just pointing out its there for the Windows Desktop app.

It's missing from your release notes, but Wear OS companion app has finally got it's facelift in 6.10.2, with way clearer layout and fixed scrolling issues. well done, but add it do the changelog

Old question, but you should setup a new passkey in enpass. The RFC-specifications for import / export of Passkeys aren't out YET. (but backup restore in enpass ofc covers the Passkeys)

Any URL

With the update enpass 6.10.1. 982, enpass no longer autofills inline in Firefox for Android v. 124.2.0 Chrome and other apps still autofills and the related settings are on Android 14

LinkedIn used to provide a link to login with passkeys, worked fine with Enpass. Now they (LinkedIn) changed the flow so that a floating popup appears, reading 'login using key', when focusing on the username or password-field. That popup however brings up Windows native login-screen (device, pin etc) and bypasses Enpass' Passkey-integration. If more sites follow this, you might have a growing issue at hand. For Edge and Firefox, i dont event get that floating popup at all. Windows 11, 23H2. Google Chrome: 122.0.6261.70 Enpass (Microsoft Store): 6.9.4 (1630) Enpass Chrome-plugin: 6.9.3

@Amandeep Kumar Any enpass version on any platform. The only possibility to see what category an item belongs to, is to see an item directly from a choosen category. If you view an item from the All categories view, there's no field or description to correlate the item back to is category.

You aren't supposed to move the enpassdbsync AFAIK. You disconnect your vault from OneDrive A and connect it to OneDrive B-account?

This isn't an official package, is it? Try the Deb-packages from Enpass official Ubuntu repo instead "KNOWN ISSUES: - Browser extension unable to connect to application with default permissions. - The extensions will open the application, but not establish a connection." - https://flathub.org/apps/io.enpass.Enpass

vaults are local-first in Enpass. What you'd do is to remove the data "from cloud" on one of your devices with Enpass, then immediately setup a new sync to Google. If you've got Enpass on more devices still syncing towards apple, youll get a red warning on them saying no data was found on Apple iCloud, ignore and then setup sync to Google on them as well. make sure you've got backups when doing this, esp. if you're only using Enpass on one device, either automatic ones or create a manual backup, since you'll remove Working with vaults — Enpass User Manual-Desktop 6.7 documentation

Just tell the devs to stop this malarcy with. It's redicioulus esp. with Enpass going Enterprise. Pinning was introduced after a security audit you had done prior to Enpass Business, but surely you fixed the real issues that came to light? Continuing SSL/TLS-pinning for now is just security by obscurity :-)

The new beta version 6.9.4 for android seems to lock the main app when it is brought to focus (and if the "lock after" has been set), not in the background. I'm seeing my items briefly before enpass lockscreen covers it. So it seems the data is unprotected in the background. The behavior is seen when "Lock on leave" is disabled. If that setting is activated, the locking seems to happen as soon as the app is put to background.

Thanks for putting your hands on the WearOS app in enpass beta 6.9.4 for android. Seems that you tried to sort the scrolling out. However now you made the title-header scrollable, so items are hidden. Please make it so that there is only one scrollable area in the WearOS app (and also not 50% too long scrollbars

Are those plans still "current", that is, you're abandoning the portable version? Will it receive functional updates at some point, or security updates if needed, or is it left as-is? Is it safe to use in a sync-scenario when other enpass versions are years newer?

Checked again now, and seems that this has been solved by Google with yet another Chrome update: 120.0.6099.115. Enpass now shows up at Passkey-logins like it should.

Any idea what's going on?