Schneier posts papers - one evaluates 1P

dougl

https://www.schneier.com/blog/archives/2014/09/security_of_pas.html

The first paper discussed 1P, and highlights a couple of vulnerabilities. The iFrame auto-fill is an interesting one.

Comments from AgileBits?

Megan

Hi @dougl,

Since your question refers to 1Password in general and is not restricted to 1Password 4 for Mac, I've moved your question into the 'Lounge' forum. I'm going to ping our security expert, @jpgoldberg‌ here, as he'll be able to give you a much better answer than I. :)

jpgoldberg

Hi @dougl!

There will be a blog post about this, but the short answer is that with respect to automatic auto-filling, Silver et al. use 1Password as their example of how to do things right. We, too, specifically do not have automatic autofilling for exactly the reasons described.

I was at USENIX Security where this paper was presented, and I'd been in touch with the authors in the weeks before the conference.

Take a look at page 4 of the presentation slides (PDF), which is largely repeated as the main defense (page 23).

Actually, I will just post page 4. Note again that this is the authors' example of the safe way of doing filling.

jpgoldberg

I should also point out this other discussion about automatic auto-fill, in which this has also been discussed. https://discussions.agilebits.com/discussion/comment/138928

dougl

Thanks! I should have been more clear, I was referring to this comment at the very end:

"However, if a legitimate page that a user wants to fill credit card information into also contains an iFrame with hidden credit card fields from a third-party domain (e.g., advertisement), 1Password will fill the credit card information inside the iFrame as well as in the main page with a single click and no notification to the user."

I'll admit, that I didn't consider that thread model, but it's definitely one that makes sense.

As for the rest, well, let's just say that there's a reason I've stuck with you guys over the years - and it shows.

RichardPayne

I didn't think 1Password filled hidden fields?

jpgoldberg

There are more ways to "hide" a field than to use the hidden field type. For example, the form could be positioned where it is then covered yp by some other page entity. This is particularly easy to do with iFrames. (If so many legitimate log in forms didn't use iFrames, we would refuse to fill into those.)

Although 1Password is safe from the main sort of threat that the paper describes, it did point out places were we have room for improvement, all of which are being considered and some of which have already been acted on. For example, we are changing the behavior of what happens when a form saved as https fills for http. (The details vary across platforms.)

The recommendation to keep track of the domain in a form action and report if there is a change is also something that looks particularly interesting. What we need to do is collect data to get a sense of how often legitimate changes occur.

For these sorts of things, we need to keep in mind that the threat, while real, involves an attacker who can modify the contents of a served web page but has not compromised the server to the extent to which they can just capture the passwords as the server handles them. This does happen, but if an attacker fully compromises a server, then there is nothing we can do at the client end of things.