1password White Paper

0 views
Skip to first unread message

Salomon Thoj

unread,
Aug 3, 2024, 11:25:20 AM8/3/24
to kittthabadi

Reading your security white paper ( -white-paper.pdf), I am confused about the difference between "account password" vs "master password". For example, on page 10 of the white paper it talks about the "account password" + secret key, but the picture shows the "master password" and secret key.

Is the account password that unlocks the app the same password that I need to log in to 1password.com in my browser? Can I log into 1password.com on my browser without having the 1password browser extension? If not, how would the browser get access to my local secret key?

Thanks for catching this! "Account password" and "Master Password" refer to the same thing: the password that you use to unlock the 1Password app and sign in to 1Password.com. Account password is the term that we're using moving forward and it looks like some of the images in the Security White Paper haven't been updated yet to reflect the new wording. I've let the team know so that we can update these images to avoid confusion in the future.

Yes, you can sign in to 1Password.com without having the browser extension installed. When you log in to your 1Password account on 1Password.com you'll be asked to type in both your account password and Secret Key. You can find the Secret Key on your Emergency Kit.

Additionally, on their own website they compare themselves to many other password manager but exclude Bitwarden. I found this interesting because it seems as though their comparison perhaps intentionally stacked their product up against solutions that they knew they could compete and potentially win over? For the record, this is pure conjecture and am happy to retract said statement if there is valid reason for excluding Bitwarden but including LastPass (a company that has been absolutely dragged by the privacy/security community due to their atrocious breaches that took place over 2022).

In their compliance section it says that they are working on a Whitepaper that will publicly present their architecture, which is to say there is not currently an explanation of the architecture despite the fact that this service has been around for at minimum 2 years (based on what I could find). HeyLogin also appears to be more geared towards businesses interested in Enterprise level solutions than individual users.

Again, I am not an expert at evaluating service like these. Just providing my insight based on the brief 15-20 minutes I spent looking at HeyLogin after seeing this post. If you decide to try them and have a great experience, be sure to post here again because I would love to hear more from someone that has experience with their solution. Best of luck!

I recommend you read the 1password white paper, it can explain it better than I can, but it details what would happen if someone accessed AgileBits servers and stole the encrypted data. (Story 1 in the whitepaper)

A first draft of this paper was released for review by members of the CNI Access Management list on March 28, 1998 and generated a great deal of electronic discussion within the closed CNI-AUTHENTICATE mailing list. This was followed by a meeting in Washington DC on April 5, 1998 to review and discuss the draft paper and comments generated on the list up to that date. The revision has also benefited from discussions at a Digital Library Federation/National Science Foundation Workshop held in Washington on April 6, 1998 on closely related issues. My thanks to all who contributed.

This version, which incorporates many of the ideas from this process, is being prepared for distribution at the Spring CNI Task Force meeting in Washington DC, April 14-15; it is also being placed on the CNI web site (www.cni.org) for wider dissemination. Note that in some places time did not permit me to fully incorporate earlier comments or to research questions that were identified, and I have tried to indicate where changes will be made prior to the preparation of the final version. The paper also still needs some considerable editorial work, and I ask readers to be forgiving of editorial problems. Comments are invited and should be sent to . About 10 May, 1998, I will prepare a final version of the white paper which will be placed on the CNI web site.

As institutions implement networked information strategies which call for sharing and licensing access to information resources in the networked environment, authentication and access management have emerged as major issues which threaten to impede progress. While considerable work has been done over the last two decades on authentication within institutions and, more recently, in support of consumer-oriented electronic commerce on the Internet, a series of new technical and policy issues emerge in the cross-organizational authentication and access management context. This white paper, which is being prepared by the Coalition for Networked Information in conjunction with a large group of volunteer reviewers and contributors, is intended to serve several purposes:

Progress in inter-organizational access management will benefit everyone. To the extent that resource operators and licensing institutions can agree on common methods for performing this authentication and access management function, it greatly facilitates both licensing and resource sharing by making it quick, easy and inexpensive to implement business arrangements. It benefits users by making their navigation through a network of resources provided by different operators more seamless and less cumbersome. The central challenge of cross-institutional access management is not to set up barriers to access; it is to facilitate access in a responsible fashion, recognizing the needs of all parties involved in the access arrangements.

While this white paper will give some particular emphasis to issues that arise in the higher education and library communities (particularly at the policy level) the problem under consideration here is very general, and in fact occurs in general corporate licensing of networked information services, or cooperation among business partners.

As we will see in the next section, not only are there questions about how best to accomplish this technically, there are also a series of intertwined policy and management considerations which need to be considered.

The focus here is on group licenses that may be subject to some additional constraints (for example concurrent user limits) rather than on transactional models where individual users may take actions to incur specific incremental costs back to the licensing institution over and above base community licensing costs. Any incremental cost transactional model will need to incorporate at least two additional features: a set of user constraints that become part of the attributes for each authenticated user and which are made available to the resource operator, and a means by which the resource operator can obtain permission for transactions by passing a query back to the licensing institution. This involves a much more complex trust, liability and business relationship between resource operator and licensing institution, as well as consideration of financial controls and a careful assessment of security threats. It will not be considered further here.

Note that there are several other cross-organizational authentication, authorization and access management issues which are beyond the scope of this paper, including the authentication of service providers and verifying the integrity and provenance of information retrieved from networked resources.

Authorization is the process of determining whether an identity (plus a set of attributes associated with that identity) is permitted to perform some action, such as accessing a resource. Note that permission to perform an action does not guarantee that the action can be performed; for example, a common practice in cross-organizational licensing is to further limit access to a maximum number of concurrent users from among an authorized user community.

Some libraries are establishing consortia which involve reciprocal borrowing and user-initiated interlibrary loan services; in a real sense these consortia are developing what amounts to a union or distributed shared patron file. One can view this as moving beyond just common authentication and access management to a system of shared access to a common directory structure for user attributes, and a common definition of user attributes among the consortium members. This is an example of a situation where very rich attributes are available to each participant in the consortium as they make authorization decisions; interlibrary loan and reciprocal borrowing represent a much richer and more nuanced set of actions than would be typical of a networked information resource.

A subsection on models for access management, discussing the locus of authorization decisions and trust relationships between there resource operator and licensing institution, will probably be added here in the next revision.

We will be examining a number of different proposed solutions to the access management problem. Before describing and analyzing these proposed solutions, this section considers the various requirements that a viable solution needs to address. Obviously, there are trade-offs which will need to be made among the conflicting goals in the context of each specific resource access arrangement, and institutions will have to make policy choices about the relative importance of the various requirements.

Any solution also needs to reflect current realities; in particular, it must be able to recognize the need for a user community member to access a resource both independent of his or her physical location (for example, a user must be able to connect to the internet via a commercial ISP, a mobile IP link, or a cable television internet connection from home), and also the need for people to access resources by virtue of their location (for example, access may be granted to anyone who is physically present in a library, whether or not they are actually members of the licensee institutional community).

c80f0f1006
Reply all
Reply to author
Forward
0 new messages