[kitten] New Draft: Open Password Automation Recipe (OPAR) Protocol

[Branden Williams]

Good day!



I’m happy to announce my first I-D submission here: https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00



Problem Description:

There is no standard way for a Password Manager (1Password, LastPass, etc.) to understand what constitutes a compliant password on a site to site basis. Often times, the format that it suggests does not comply with the website’s password policy (wrong special characters, wrong length, wrong count of upper v. lower v. numbers). The attached proposal attempts to solve this by allowing website owners to embed their password policy programmatically into a JSON object that a password manager can read to automatically suggest a strong and compliant password. This would promote usability of password managers as well as improve the user experience. (Note: I do not work for any company that creates a password manager.)



Success:

Publication of this doc as a Proposed Standard. This would allow website owners to programmatically describe compliant passwords so password managers can suggest, transmit, and store the maximum strength compliant password possible for the website. Ideally, all developers that build password managers could implement the standard to improve their user experience. This could potentially also improve user experience for those with ADA (or non-US equivalent) requirements.



Discussion:

Please discuss here on ***@ietf.org! As this is my first submission, I am open to any and all comments.



Regards,



Branden R. Williams, DBA, CISSP, CISM

***@brandenwilliams.com

Phone: [phone]



http://www.brandenwilliams.com/

[Branden R. Williams]

FYI, I realized a typo in the draft that includes two examples, both labeled as example 1. Will fix if this goes through.

Regards,

Branden R. Williams, DBA, CISSP, CISM
***@brandenwilliams.com <mailto:***@brandenwilliams.com>
Phone: [phone]

http://www.brandenwilliams.com/

Post by Branden Williams
Good day!
I’m happy to announce my first I-D submission here: https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00 <https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00>
There is no standard way for a Password Manager (1Password, LastPass, etc.) to understand what constitutes a compliant password on a site to site basis. Often times, the format that it suggests does not comply with the website’s password policy (wrong special characters, wrong length, wrong count of upper v. lower v. numbers). The attached proposal attempts to solve this by allowing website owners to embed their password policy programmatically into a JSON object that a password manager can read to automatically suggest a strong and compliant password. This would promote usability of password managers as well as improve the user experience. (Note: I do not work for any company that creates a password manager.)
Publication of this doc as a Proposed Standard. This would allow website owners to programmatically describe compliant passwords so password managers can suggest, transmit, and store the maximum strength compliant password possible for the website. Ideally, all developers that build password managers could implement the standard to improve their user experience. This could potentially also improve user experience for those with ADA (or non-US equivalent) requirements.
Regards,
Branden R. Williams, DBA, CISSP, CISM
Phone: [phone]
http://www.brandenwilliams.com/ <http://www.brandenwilliams.com/>_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten <https://www.ietf.org/mailman/listinfo/kitten>

[Branden R. Williams]

Good Day to you all. Just checking in to see if anyone had any thoughts here. The status of the draft seems the same since original submission.

Thanks!

Regards,

Branden R. Williams, DBA, CISSP, CISM
***@brandenwilliams.com <mailto:***@brandenwilliams.com>
Phone: [phone]

http://www.brandenwilliams.com/

Post by Branden Williams
Good day!
I’m happy to announce my first I-D submission here: https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00 <https://tools.ietf.org/html/draft-bwilliams-kitten-opar-00>
There is no standard way for a Password Manager (1Password, LastPass, etc.) to understand what constitutes a compliant password on a site to site basis. Often times, the format that it suggests does not comply with the website’s password policy (wrong special characters, wrong length, wrong count of upper v. lower v. numbers). The attached proposal attempts to solve this by allowing website owners to embed their password policy programmatically into a JSON object that a password manager can read to automatically suggest a strong and compliant password. This would promote usability of password managers as well as improve the user experience. (Note: I do not work for any company that creates a password manager.)
Publication of this doc as a Proposed Standard. This would allow website owners to programmatically describe compliant passwords so password managers can suggest, transmit, and store the maximum strength compliant password possible for the website. Ideally, all developers that build password managers could implement the standard to improve their user experience. This could potentially also improve user experience for those with ADA (or non-US equivalent) requirements.
Regards,
Branden R. Williams, DBA, CISSP, CISM
Phone: [phone]
http://www.brandenwilliams.com/ <http://www.brandenwilliams.com/>_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten <https://www.ietf.org/mailman/listinfo/kitten>

[Greg Hudson]

Post by Branden R. Williams
Good Day to you all. Just checking in to see if anyone had any thoughts
here.

The problem statement seems legitimate, but I am not sure about the
solution.

Getting everyone to implement OPAR isn't necessarily easier than getting
everyone to accept passwords which meet a specific set of criteria, and
perhaps signify that somehow.

Most of the criteria described by OPAR are deprecated, at least per
recent NIST guidelines[1]. Sites may still require mixed case and
special characters in passwords, but encouraging them to formally
describe those requirements may be less valuable than encouraging them
to drop the requirements altogether.

Describing a password policy isn't a closed problem, and describing some
policies isn't sufficient for the password manager to be certain it will
generate an acceptable password. For instance, one technique seen in
practice is to reject every password seen in a past login attempt[2].

A nit about section 3.1.2: a site should ideally allow very long
passwords (at least 256 bytes), but a password manager should not
necessarily generate passwords that long.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html
(or search "NIST password recommendations" for summaries)
[2] https://www.guildwars2.com/en/news/mike-obrien-on-account-security/

[Branden R. Williams]

Post by Greg Hudson
Getting everyone to implement OPAR isn't necessarily easier than getting
everyone to accept passwords which meet a specific set of criteria, and
perhaps signify that somehow.

Fair enough, but given the amount of legacy technology out there, I have
little faith in getting everyone who leverages authentication to beef
up their standards accordingly.

Post by Greg Hudson
Most of the criteria described by OPAR are deprecated, at least per
recent NIST guidelines[1]. Sites may still require mixed case and
special characters in passwords, but encouraging them to formally
describe those requirements may be less valuable than encouraging them
to drop the requirements altogether.

I just read through that doc and saw the points on composition rules. I suppose
if there are no limits, then that could be an option as well. It would probably
be easier to just say “No composition limits” with the max characters of Y
than to try to include every character in the Special Characters section.

Post by Greg Hudson
Describing a password policy isn't a closed problem, and describing some
policies isn't sufficient for the password manager to be certain it will
generate an acceptable password. For instance, one technique seen in
practice is to reject every password seen in a past login attempt[2].

I’m willing to roll the dice on that one. If a (good) password manager
generates two identical passwords, it’s time to buy a lottery ticket. :)

Post by Greg Hudson
A nit about section 3.1.2: a site should ideally allow very long
passwords (at least 256 bytes), but a password manager should not
necessarily generate passwords that long.

Hrm, interesting. Perhaps 3.1.2 should read something like this:

Password managers should focus on this value and elect to
maximize length and complexity according to its configuraiton.

I’m happy to submit and update, but if we are concerned about being
out of sync with NIST (yet in sync with practice), I’m good dropping
it :)



Regards,

Branden R. Williams, DBA, CISSP, CISM
***@brandenwilliams.com
Phone: [phone]

http://www.brandenwilliams.com/