A more secure Autofill

Feature Name:

A more secure Autofill

Feature Description:

  • Autofill password fields with randomly generated values instead of the real password.
    • User autofills password-field;
    • Unbeknownst to the user, a token is randomly generated and autofilled
      • This token will be connected to the actual password and there is a direct translation to the user’s real password
    • User clicks action button (to either login/register)
    • Extension makes the translation between the token and the actual user password
    • The request is now sent with the real password, and not the token

Clients / Repos Affected:

  • Browser Extension
  • Server (?)
  • DB (?)

Timeline to Completion (Estimate):

  • October 2021


Hi everyone! In my MSc Thesis Dissertation, which is a part of the PassCert Project, we are building a proof-of-concept password manager that through the use of formal verification, is guaranteed to satisfy properties on data storage and password generation.

My project has the following goals:

  1. Make autofill more secure (the feature i propose in this post)
  2. Make Password Manager’s randomly generated passwords compliant with sites’ password policies (I will create this post later on)

This feature was suggested in a 2014 work, by Stock and Johns. It was also recently suggested by Oesch and Ruoti.

In short, the idea presented allows for greater user protection, since the Javascript that runs on the website will never have access to the real user password.

@tgreer @kspearrin


One quick note (sorry, just saw this and thinking out loud).

I’m not sure how this would actually work, since quite a few sites use XHR for authentication, SPA’s especially; so with that JavaScript does have access to the HTTP request, which is what I’m assuming this proposal would be hijacking before the form is submitted. But any value manipulation, request body/headers, form fields/values, etc. would seemingly at some point still have to live within the same world as the page’s JavaScript.

The only way, from my understanding of this approach, for this to work would be cooperation and/or APIs from the Browser that would handle it on the wire itself during the request, denying access to the JavaScript world.

Also note, Bitwarden uses JavaScript in the browser extension to perform autofill, and therefore anything and everything it does must be accessible to JavaScript, and if the Bitwarden extension has access to those values into the page or request, my assumption would be that the page would also have it.

But I am not an expert here, just thinking out loud with some food for thought.


Hi! Thanks for the answer and feedback :slight_smile:

What I had in mind was not to restrict the javascript, per se; the idea I got from those two works was that the Password Manager would autofill a token instead of the real-password:

  • if an attacker manages to access the value of the password field in the form, it’s useless, since it’s not the real password.

I think that the Password Manager would have to be listening to the submit of the form, intercept it (using the browser API, I think) and change the password value in the request with the real password .

Does this make sense? I may be overlooking some details, so i appreciate all the feedback :slight_smile:

That makes perfect sense what you’re wanting to accomplish, and that’s how I understood it from your initial post and now after cross-referencing some of the materials you’ve linked/referenced (thank you for that btw) I don’t believe this is actually possible to do in a more secure way as of today.

My reasoning:
By delaying the autofill of the actual credential (password or other secret, SSN, credit card number, etc.), you have a few obstacles to overcome:

  • Browser support for request hijacking as an extension vs. a same-domain script (may be possible, not sure)
  • Privacy concerns where our plugin is circumventing the submission of a form or altering contents in the web request itself (man-in-the-middle); it’s one thing if the browser does this by design, it’s another thing if our friends, security researchers, and hackers through our various programs get a hold of this or raise these concerns
  • Preflight validation that the page may be doing client-side for the user-experience, how to inject the appropriate value (like a generated password that requires validation for complexity before form submission)
  • You’re not actually adding any security, just another level of obscurity

IMHO without native browser API support for this type of form value tokenization where a process (JavaScript or Plugin) can set tokenized values into the browser’s context for a given Form, so when the form is submitted it contains those values based on the token lookup on the wire; this isn’t possible or at least is not worth the endeavor. It feels like a bit of “security theater” without that type of support because at the end of the day someone could simply write a smarter credential scraper that still has access to the password by snagging the form on submission event bubble, tying to the XHR request, or doing some other manipulation of the DOM, create hidden auto-fill duplicate targets and force-submit, etc. I can think of several ways to circumvent this that would likely take a day or 2 of PoC work.

Don’t get me wrong, this is a GREAT concept, I love the idea of it but not sure w/o native browser support it can gain much traction.

With all of that said, #2 in the project goals you have stated would be absolutely welcome and a great addition! Yes. You are also more than welcome to work through a PoC for your #1 concept listed here to see how it does and we can certainly open it up to other for testing / hacking. I would caution about getting to complex/polished with it, keep it light so you’re not investing a ton of time, but it would still be interesting to see what you’re able to come up with (I’m sure there are some browser APIs or other tricks I’m not thinking of for sure).


@mikibakaiki, I’m not sure of the requirements of your thesis, but it could be a good exercise to (1) implement a proof of concept for this idea and then (2) try to break it. Regardless of the outcome (and whether it’s merged into master), it might give you some interesting findings to write about.


@cscharf again, thanks for the extensive answer, really appreciate it! :smile:

These points you make are great to explore and possibly use them if I can’t achieve something that is usable and actually more secure than the current state of the art!

I’m not sure if I understood what you mean here, could you please elaborate?

Yeah I can see this being a problem, but I’m assuming the app is “secure” to the point that, if you’re doing the manipulation of passwords, there’s enough trust from the client for you to do “extra effort” security-wise. Or am I being too naive? :upside_down_face:

The authors on the latest article speak about this: basically, browsers could be doing more in this matter.

I guess that like you say, and @eliykat mentioned (thanks!), building a PoC is worth the shot, whether the results are positive or not so positive! Both will be useful for the thesis, no doubt.

With that said, you think you could give me some pointers on how to approach this?

I had already asked in the gitter chat about the autofill functionality, and I’m analyzing it… I still can’t see the storage of ciphers (encrypted or otherwise) in the browser, and I’m not sure if i should be able to do it or not. — i used the command chrome.storage.local.get(function(result){console.log(result)}) to display it.

My idea was to maybe add a field to the cipher like tokenPassword or such and always autofill it with this value. When it was time to alter the POST request, use the real-password value.

Does this seem like the right path? :slight_smile:

Thanks again, you two, for the feedback!

PS: I’ll be posting the Contribution post for #2 in a few days, with some more details as well
PPS: Here it is. I can’t edit the original post, so i’ll leave it here

Sure! Say you have a form, that form takes inputs (for example a national ID number, credit card number/security code, password, etc.) and it has some fancy JavaScript that does client-side validation on that form, special visual formatting, etc. Placing a token in that form would essentially “Break” the intended user experience (UX) of the page and leave it to the site’s “server” to validate the form data (which hopefully it’s doing). We already get some sites that have been reported broken because we modify the HTML in the form on the fields to add what should be innocuous data attributes to them for our own use after page load for auto-fill itself; so I can’t imagine what other things could get broken on various sites once you start inserting this technique of manipulating the DOM data elements/values, form submission events, etc. And in JavaScript, how do you control the order in which those form submission handlers are fired (especially if you want to be the “last” one)?

That was the general thought there.

Passwords (Ciphers) are stored in memory, not local storage. The proper way to work with them is by using the DI services within the Angular world that are passed to the constructor of the various components or services which you’re working with. Shadow properties OR a dictionary key+value on the autofill service itself would probably be easier than modifying the cipher, something where you’re storing the cipher id + field id + token value + replacement value secondarily for submission in the sandboxed memory-space of the extension (vs. the page).

Hi! Great explanation, and great point. I hadn’t thought about that, namely the verification on the client-side. I can see why it would be problematic indeed. But, say that browsers were up to speed: would a new API method — that could do this autofill function with tokens and not a real password — fix the problem? How would it work?

I’m curious, because off the top of my head, I can’t imagine a scenario where these security checks won’t be done on the website, and therefore, they have to evaluate the real password…

So basically create a new object which is only present in memory, is this it? An object which is only accessible in the autofill service

I’m not entirely sure, but I would imagine if the extension is calling the API with known tokens + value pairs (that the browser can protect in its own memory space for that page lifetime), and the browser detects a form submission or XHR submission, it could then alter it on-the-wire, after all page execution has completed (e.g. JavaScript), and do a replacement of those pointers/tokens with the actual values along with adjusted “size” headers for the submission body.

Yes, correct.

1 Like

Okay thanks for the help :slight_smile:

I’m currently investigating this and trying to work something out. I assume i don’t have to meddle with the jslib/src/domain right? Because there’s the Login object. But maybe i don’t need to link the token pw with the login itself, but to the cipher right?

PS: I’m not sure if you’ve had the time to see it, but i posted about the generation of compliant passwords. I couldn’t link here in the original post. Just thought i’d let you know, since you demonstrated interest in it :smiley:

As a new user, I assume the security issue is settled before any feature is offered.
Call me naive, but I believe most of us think that way. The technical stuff goes way
over my head.
What I would like to see is something user-friendly. A simple link to a FAQ page, support page, etc. These are what most of us are looking for. At least I am.

I like the token idea, just keep it simple for me please. Possibly use the password
generator to create a token for each user and not the site.

The main idea is that all this is done in a way that the user doesn’t have to worry about it. A user would always be able to see the real password, but the token would be something internal.

Using the same token for every site may be simpler, but I’m not sure it has the same security implications.

I’m thinking that the site domain could be like a salt.

Sorry if this is still a bit technical :slight_smile:

The user-friendly aspect I mentioned was simply referring to what the user sees,

I realize that there is a great amount of technical wizardry behind the scenes.
People like me have little sense of that. Whatever is ultimately decided upon
sinks or swims on what we as users actually see. That perspective is often not
thought about strongly until the die is cast.

I would imagine that many wonderful programs (like this one) are laid waste by
not focusing on what the user sees. We only see results - not what designers think or even know what may be best for us.

I hope I didn’t give the wrong impression mikibakaiki. As I said, the technical details
are way over my head. My hope is that this program stays around for a long time.
I applaud the effort by csharf to improve it where possible.

In my humble opinion, the main competition has listened to Big Money to its own
detriment. Wards and Sears did that, as well as many on-line companies, and
look where they are. Even though I am comparing apples to oranges, the
principal is the same I think.

Of course, no one has offered me anything as yet, so any criticism from me is
definitely one-sided.

I’m not sure I understand what you mean. But I think that this being an open-source project, users do have a lot to say , in a sense that, if there’s something that bothers a considerable part of the community, it will probably be addressed, whether by the official team, or some super cool person in the community :smiley:

With that said, I suppose that money is not a factor here or at least is not the deciding factor.