On macOS, Safari has a ‘special’ status, at least as far as I know: even with Brave as the default browser, when adding users or internet accounts on Preferences, or sometimes even to deal with complex authentication issues (requiring combinations of OAuth2 and passkeys/dongles such as the YubiKey), Safari must be the default browser, or else nothing will work.
This, by itself, is just a minor annoyance, since those cases are reasonably rare. However, the major annoyance is that these almost always require remembering a stored combination of logins/passwords. Assuming complex combinations of alphanumeric characters to make those passwords ‘impossible’ to guess, it also means that no human can remember them all.
And we don’t need to: Brave stores them all in its internal Password Manager on our behalf, encrypted with our key, and accessible only via whatever security mechanism we use.
But of course Safari doesn’t know that! Instead, Safari relies on Apple’s built-in Keychain, like all Apple apps (and many non-Apple ones) do. Which is a bummer: I know I have the password on an account, but Safari doesn’t.
Naturally enough, what I do is simply to have Brave and Safari open, side by side, look up the password in Brave’s Password Manager and then do a copy & paste to whatever window Safari has opened.
For the past few years, I even went a step further: on those websites with complex authentication procedures (e.g., government websites, EU websites, academic ones, and many, many others — my own personal blog has, I believe, three different levels of authentication plus the requirement to use my YubiKey 
), as soon as I register with them via Browser, I add all the logins and passwords to Safari as well. That way, they’ll get saved into the macOS Keychain automagically, and gets propagated to my other Apple devices, whether they have Brave installed or not.
The natural question that arises is: why doesn’t Brave use the native macOS Keychain instead of reinventing the wheel and create its own?
The answer, I suppose, is that those who use Brave in different operating systems (aye, I do that as well) need to sync passwords across systems; while Apple’s Keychain can only be accessed via an Apple-native application. So, Brave’s Password Manager is platform-independent — at the cost of having to deal with Yet Another Password Manager and duplicating everything.
But this is not absolutely required. A hybrid approach is certainly possible, it might just be slightly trickier to implement in a safe and secure way.
I’ve never had a look at Brave’s (or Chromium’s!) code, which I assume to be written in C++ — which has tons of libraries, for sure. I’m mostly an amateur Go programmer, and I have been using in the past a ‘universal’ keychain library to include in some of my own tools. Its operation is pretty simple: depending on the operating system and architecture it’s running, it tries to figure out first if there is a local keychain. GUI-based Linux and Apple’s devices will have those with certainty for all architectures, and, very likely, something exists under Windows (x64), as well as for Android (which is a GUI-based Linux, after all, running on ARMv6 and/or v8 CPUs). That way, storing a password or credential securely in any of those combinations of OS/CPU is just a matter of calling the exact same function; what happens ‘under the hood’ is up to individual OSes.
And what about all the other edge cases which may run Brave on top of a more unusual combination of OS/CPU? (say, FreeBSD and/or Darwin running X Windows, but not necessarily a GNOME-based windows manager [which includes its own standard keychain — for which Brave can be compiled and run) The answer is simple: in such cases, the library defaults to creating a disk-based encrypted database, i.e., exactly what Brave does with its built-in Password Manager.
The advantage is how this can be tied together with Brave Sync. The premise is that Brave Sync will not write directly to its own internal database-on-the-filesystem, but, instead, it would use such a library to pick first whatever the OS offers, and only default to the current approach if no ‘native’ keychain can be written to. I’m sure that someone must already have developed a C++ library to do exactly that.
It might be the case that, under Apple’s macOS at least, the storage cannot be done in one of the ‘default’ keychains, and a new keychain needs to be generated just for the purpose of storing Brave login/password pairs. But that is perfectly acceptable, since, by default, macOS will search across all keychains, unless told otherwise, so long as a Brave-specific kychain is readable by all.
As an extra bonus, this would allow web passwords stored on an Apple Keychain to be sync’ed with those in GNOME Desktop or Windows; thus, replacing the need of using any of those powerful universal password managers such as 1Password, among others.
This is essentially turning the following support requests into a Feature Request, in the hope that this won’t get auto-closed after a very short time:
- Any way to integrate Brave with the built-in password manager on MacOS?
- Brave Browser ios access to Autofill contact data and Passwords App / Keychain data
- Add support for macOS Keychain to Brave
Obviously, for the security-conscious who don’t trust Apple’s ability to safely and securely, this feature should be entirely optional, i.e., by default Brave should only use its own Password Manager service. But there could be an option saying “Use the system-native keychain instead”.
And, as some of those support requests show, it would also make sense to use those commercial, universal password managers as an option as well — assuming that they have a permissive and publicly published API, that is. In fact, for those cases, it’s even likely that whatever C++ library you might use for storing passwords under 3rd-party keychains will already support those tools as well!
Please give it a try!