Network Working Group Thomas Brownback
Request for Comments: xxxx Independent Researcher
Category: Experimental Month YYYY
Password Negotiation for Password Managers
Abstract
This document proposes a protocol that would enable a password
manager (PM) to register or change a password with online
services. The minimal user involvement would improve the usability of
PMs, a current hurdle in more widespread adoption. Increased use of
PMs would improve password management by reducing the frequency of
common, simple, reused, or rarely changed passwords online,
significant current vulnerabilities for the web.
Status of this Memo
This document defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
This memo is public domain by declaration of the author.
Table of Contents
TBD
1. Introduction
Automated password negotiation between a password manager (PM) and an
online account provider (OAP) would allow users to rapidly establish
secure, unique passwords on many websites, improving password
security on the Internet.
1.1. Password Security
Password issues are a key source of insecurity on the Internet.
a. Passwords must be complex to prevent attack. Passwords must also
be memorable to allow reuse. Complexity and memorability are at odds.
b. Password reuse also weakens passwords, and allows the compromise
of one account to enable the compromise of others. Password reuse
nonetheless remains common.
c. Password managers tackle these problems by storing several unique
complex passwords in one encrypted database under a single memorable
password.
Cite:
https://xkcd.com/936
and accompanying links on the explainxkcd page:
https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
“If you write an article about choosing passwords where password
managers aren’t mentioned even once, you’re not helping anyone.”
https://diogomonica.com/posts/password-security-why-the-horse-
battery-staple-is-not-correct/
“Users should not be choosing passwords.”
https://www.techdirt.com/articles/20100621/0934019896/dailydirt-how-
many-passwords-do-you-know.shtml
https://arstechnica.com/security/2014/04/stanfords-password-policy-
shuns-one-size-fits-all-security/
d. People are bad at generating unique, complex passwords, especially
when asked to memorize same for many sites online.
e. Users rarely change passwords if not required to do so.
f. Password constraints limit entropy and are often not transparent,
leading to frustrating user experiences when passwords are rejected
for containing forbidden characters or failing to contain required
characters, even when a proposed password is high in entropy.
1.2. Password Manager Security and Usability
PMs can improve password security.
a. PMs aid in the generation of passwords. Although the generation
of highly secure pseudo random strings remains an area of active
study, machines currently outperform humans at this task by almost
any measure.
cite:
What Does Randomness Look Like? WIRED
https://www.wired.com/2012/12/what-does-randomness-look-like/
b. PMs can not only generate, but also serve as a “memory” for
complex passwords.
c. PMs generate and store unique passwords for each site, so the
compromise of any one password does not necessarily provide useful
information about passwords on other sites.
d. Usability remains a hurdle to greater PM adoption.
cite:
https://www.npr.org/blogs/alltechconsidered/2014/11/03/361137779/lazy-
about-your-online-passwords-take-control-with-these-new-tips
“Now, I’m not going to make the picture rosier than it is. 1Password is
not the easiest software to use. Even more annoyingly, if you currently
have weak passwords, you need to change those to something very
difficult to guess, then store that login in the software. Doing this
over and over is quick, but a hassle. For my 15 key sites, it took 22
minutes of concerted effort to complete. For other semi-important sites,
I’m just dealing with them as I go. I add a couple a day, at most.”
This password establishment protocol would improve the usability of
PMs.
2. Specification of PM-PWD-NEG
The establishment of a password on an online account provider (OAP)
requires communication of password requirements and restrictions,
a password to be securely transmitted, and a confirmation that the
password was correctly set.
Additional security considerations require that the password be
communicated only in an encrypted channel, that responses from the
OAP avoid leaking information about existing accounts or passwords,
and that the exchange be resistant to replay attacks. Note that these
considerations also apply to current password establishment
procedures.
PM OAP
——– ——–
PM Hello and Authorization
[username + existing password]
——–>
OAP Password Requirements and Restrictions
<——–
Password Request
[proposed new password]
——–>
Success/Failure
<——–
Note:
Unless otherwise noted, the decimal numbers appearing in packet-
format diagrams represent the length of the corresponding field, in
octets. Where a given octet must take on a specific value, the
syntax X’hhhh hhhh’ is used to denote the value of the octet in that
field. When the word ‘Variable’ is used, it indicates that the
corresponding field has a variable length defined either by an
associated (one or two octet) length field, or by a data type field.
2.1. PM Hello and Authorization
Transmission of a username and password has been handled before. (See
RFC 1929 et. al.). Similar conventions are followed here.
+—–+——+————-+——+————-+
| VER | ULEN | USERNAME | PLEN | PASSWORD |
+—–+——+————-+——+————-+
| 1 | 1 | 1 to 255 | 1 | 1 to 255 |
+—–+——+————-+——+————-+
The VER field contains the current version of the protocol,
which is currently X’0000 0001′. The ULEN field contains the length
of the USERNAME field that follows. The USERNAME field contains the
username. The PLEN field contains the length of the PASSWORD field
that follows. The PASSWORD field contains the password associated
with the given USERNAME.
The server verifies the supplied UNAME and PASSWD, and if the
information conforms to an existing account, replies with password
requirements as indicated in the following section.
2.2. OAP Password Requirements
+————————-+——————————–+
| Allowed Character Sets | FLEN | Forbidden Characters |
+————————-+——+————————-+
| 2 | 1 | 0 To 255 |
+————————-+——+————————-+
| Min Length | Max Length |
+————————-+——————————–+
| 1 | 1 |
+————————-+——————————–+
2.2.1. Allowed Character Sets
The two octet field specifies sets of characters allowed for
inclusion in a password by means of bit flags, using the following
fields:
0. ASCII lowercase
1. ASCII uppercase
2. Digits [0-9]
3. All ASCII
4. Space
5. Basic special characters (US keyboard layout number row) !@#$%^&*()
6. Brackets ()[]{}<>
7. Punctuation ,.?'”;:`~-
8. Math -+*/=^.
9. Bars /|_-
10. High ANSI
11. All UTF-8
12-15. Reserved.
The selection of categories is intended primarily to allow OAPs to
specify allowed passwords as easily as possible.
Note that some of these categories overlap. The union of all flagged
categories should be permitted. X’0000 1001′ (All ASCII + ASCII
lowercase), X’0000 1010′ (All ASCII + ASCII uppercase), and
X’0000 1000′ (All ASCII) result in identical specifications.
Comments are welcome on more useful categories here.
No provision is provided for OAPs whose password systems fail to
distinguish between upper and lower cases, because this can encourage
a false sense of additional security.
2.2.2. FLEN
This specifies the length of the Forbidden Characters field.
2.2.3. Forbidden Characters
Forbidden characters are listed in this field using UTF-8 encoding.
Comments are encouraged on whether or not this field is sufficient,
or if other encoding schemes should be supported, or if a certain
order should be recommended or required.
2.2.4. Min Length / Max Length
The minimum and maximum permitted lengths of the password in
bytes.
Comments encouraged on whether or not this field should indicate
length in characters, or length in bytes.
Password lengths are most commonly referred to in terms of character
lengths, despite protocol preference for bytes. Byte restrictions may
require additional calculations by the PM for certain UTF-8
passwords, but character-based limits may introduce complexities for
OAP memory allocation.
Byte length makes the rest of the protocol easier to standardize, so
that is currently used, with the suspicion that character counts
would be more useful.
2.3. Password Request
+——+————-+
| PLEN | PASSWORD |
+——+————-+
| 1 | 1 to 255 |
+——+————-+
The PLEN field contains the length of the PASSWORD field that
follows. The PASSWORD field contains the requested new password.
Comments encouraged on whether it would be helpful to restate
the associated username. It is currently assumed that repeating the
username would be redundant, and might even allow confusing a
poorly configured OAP into changing an account without authorization.
2.4. Success/Failure
+———+
| SUCCESS |
+———+
| 1 |
+———+
Success indicated by X’0000 0000′. All other results indicate failure.
Comments encouraged on what specific failure codes might be useful
without leaking information. (ie, there will be no failure code for
“username not found”. A failure code for insufficient length or use
of forbidden character might be helpful for troubleshooting.)
3. Special Issues for Discussion:
3.1. Should PMs be allowed to set up new accounts?
Current assumption is no, as automated account creation is disfavored
online. OAPs often need to throttle account creation to prevent
abuse, so an automated solution here would likely be frowned upon.
3.2. Should the PM be allowed to bypass the hello?
Current assumption is no.
The protocol could be simplified by having the initial communication
consist of an authorization and new password request [username + old
password + new password]. The OAP would simply reply with success or
failure.
The PM could store password requirements, requesting them only if
needed, or verifying for changes on failure.
However, a PM that never or rarely verifies requirements would never
or rarely detect when an OAP increased security by expanding the
domain of allowed passwords. Lag in the full adoption of OAP security
improvements, though it would be rare, is judged a more significant
risk than the additional overhead of two small packets for this
infrequent communication.
3.3. Should PMs be required to authorize in hello?
Current assumption is yes.
Password requirements for OAPs should be publicly available, to allow
new users and security researchers to evaluate the security of
existing OAP password systems before account creation. But this
information can be provided to humans in a separate channel.
Requiring initial authorization limits opportunities for mischief,
such as use of this protocol in denial of service attacks.
OAP should abort the protocol on failed authentication for this to be
effective.
Like any authentication step, this allows an attacker to confirm the
existence of a username password pair, and allows an opportunity for
password guessing.
For this reason, the protocol should be throttled by the OAP.
Throttling specifics are considered out of scope here, given the
many unique features of OAPs, but comments are welcomed if there is
an appropriate way to address this in more detail.
3.3.1. Should authentication fail silently?
Undecided.
Silent failure would allow the OAP to quickly drop unauthorized
requests, but risks encouraging well intentioned but misconfigured
PMs to bash an incorrect username+password pair against the OAP
while assuming a network error.
3.4. How should encryption requirements be detailed?
To ensure confidentiality, passwords MUST NOT be transmitted in
plaintext. This protocol includes the communication of passwords, but
it is beyond the scope of this protocol to specify underlying
encryption mechanisms required.
Comments encouraged on current best practices for binding the RFC of
a protocol to lower layer encrypted channels.
3.5. Password Length
Provisions for very long (up to 65535 Byte) passwords were briefly
considered and fairly promptly rejected.
A protocol should specify maximum field lengths to prevent overflows.
Maximum lengths for passwords, however, are generally discouraged.
This apparent contradiction can be easily resolved.
When security researchers criticize maximum password lengths, it is
typically a criticism of OAPs that sharply limit passwords to very
small lengths. Six or ten character limits on passwords are not
unheard of, and these lengths are not only easily cracked, but
usually taken as an indication of other security problems (ie, that
passwords are stored by the OAP in plaintext).
Best practices in hashing passwords for storage should prevent the
OAP from caring too much about password lengths.
OAPs may reasonably require that authentication will not consume
terabytes of bandwidth or significant resources for hashing when such
resources are not providing any additional meaningful security.
Users may only reasonably require password lengths long enough to
resist feasible attacks.
There is a wide field of possible password lengths that accomodate
both considerations. A 255 Byte password would be impervious to
cracking by a universe-sized computer before the heat-death of the
universe. Such a password would also be significantly stronger than
underlying encryption, making the password no longer the primary
vector of attack.
The current protocol assumes a maximum length of 255 bytes for any
username or password field, a value which is currently assumed to
err well on the side of caution and considered aggressively future
proofed while conveniently allowing a one byte field to specify its
exact length. Comments are encouraged if another value would be
sufficient or preferable. Please note especially any OAPs that allow
incredibly long usernames that would be strained by this restriction.
3.6. Password Requirements Specification
Should the protocol develop a password requirements specification
mini-language? Should the protocol allow regular expressions to
describe which passwords are acceptable and unacceptable?
Current form proposed for simplicity. Regular expressions or the
development of a novel mini-language here would needlessly
complicate this task. Comments on feasibility of using regular
expressions or some specialized mini-language highly encouraged.
3.7. Complexity Requirements
Some OAPs require passwords to conform to certain complexity
requirements. These requirements are varied and specific. Some
include: “must contain at least one character from at least x
different character sets”, “must not contain a series of
incremental digits”, or “must not contain common dictionary words”
(using a dictionary that will never be provided).
A good PM will automatically generate complex passwords, but may
occasionally generate passwords violating some arbitrary complexity
restriction.
Such requirements are difficult or impossible to represent in a
simple protocol field because there is no clear limit on what rules
could be imposed on any given system.
Therefore, it is probably preferable to simply allow such passwords
to be rejected, and have the PM try again, rather than attempting to
communicate complexity requirements in this protocol. Ideal best
practices would discourage complexity requirements, or at least
suspend such requirements for interactions with PMs.
TODO: ref, “Password complexity rules more annoying, less effective
than lengthy ones”, Casey Johnston, Ars Technica, June 28, 2013,
https://arstechnica.com/security/2013/06/password-complexity-rules-
more-annoying-less-effective-than-length-ones/
(track down underlying 2011 study referenced there)
4. Acknowledgments
TBD
5. Normative References
6. Informative References
Cracking 160 character password unlikely before heat death of universe
with universe sized computer:
https://forums.xkcd.com/viewtopic.php?f=12&t=74016
7. Security Considerations
TODO: TLS (or any future supplanting protocol) as a hard requirement for
PEP communications, see RFC 5246.
TODO: see RFC 3552
8. IANA Considerations
TODO: see RFC 2434. “No IANA Considerations” maybe?
TODO: RFC 793 for inspiration.
Appendix A.
Authors’ Addresses
TBD
See also:
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial63.pdf
https://www.ietf.org/ID-Checklist.html
https://www.ietf.org/ietf/1id-guidelines.txt
RFC 2629 on writing I-Ds and RFCs in XML.
www.rfc-editor.org/howtopub.html
ftp.rfc-editor.org/in-notes/rfceditor/instructions2authors.txt (dead?)
rfc-editor@rfc-editor.org