Show HN: PEP – an idea to help bring password managers to the masses

I'm not sure if I follow, I don't see what the benefit is in defining an authentication protocol like this based on passwords. If websites are going to actually work with this protocol, why not use public key authentication or any of several other existing authentication protocols. Maybe I'm missing something, but unless this somehow eases the distance between password based authentication and other methods then it seems kind of like trying to shuffle our human password schemes into a protocol where details like a unique password shouldn't need to matter anymore anyway.

I'm a little confused.

The passwords I create myself are secure enough. But holy hell, entering them on devices with nerfed keyboards (phones, TVs, etc.) is a royal pain in the ass.

So: do I make my passwords less secure and easier to enter on a nerfed keyboard?

Avoiding this pain has been the strongest motivation for me to explore password managers.

I like the general idea of defining protocols that can help password managers work more seamlessly. But this seems too low level. Most online services run HTTP services, and afaict, this protocol wants to run on TCP/TLS (though it doesn't specify); seems like it would be more sane to define it as a HTTPS/JSON api for password rotation, given all the online account providers generally have https servers and could easily add a new https endpoint.

But I think the more interesting problem, which this totally ignores, is how to plug in to account creation. If I'm a normal user, and a page presents me with a sign up form, I want to autofill the choose / confirm password fields; if I don't I'm probably going to choose a weak password - or worse, one I'll forget entirely. I suppose you could say "just tell your password manager about the account later and let it choose a better password" but the proposed protocol doesn't work at all if your password manager doesn't know about the account (or doesn't know the password). Whereas if you can plug into the creation flow - possibly via some html / js api - the password manager can be like "hey I see a account creation form that wants you to create a new password, want me to do that for you"? And boom, you are always generating strong passwords.

And ideally we'd have a similar standard for login pages so password managers could slurp up your existing logins as you use them. 1Password does decently at this, but every once in awhile I encounter a bank or some other service that decides to ask verification questions or have a two-page login flow, that 1Password just can't deal with.

Let's see if Guido will accept this into 3.6

Here's my proposal:

A single, standardized HTTP endpoint, "/.well-known/passwordchange/", where you can POST with query parameters "userid", "oldpassword" and "newpassword" and the server returns either a 200 on success or something else on non-success. That's it.

Should really just use JSON or something.

Also the password rules are unnecessary complex it doesn't need to provide the full rules just a regex that should match and the password manager can just fill that in with randomness something like "[a-zA-Z0-9]{64}"

The rules should also be provided in the password input field and the form should provided the reset url so that can be discovered something like:

    <form password-reset="/api/password/reset">
        <input password-restriction="[a-zA-Z0-9]{64}" />
    </form>

Then the password manager can autofill with a correct password on account creation.

I'd also use a json/http interface for resetting the password, means no restrictions on length and is much more familiar to the target audience.

See also

SWAMP, or Standardised Web Account Management Protocol https://github.com/ashward/swamp

Password-manager friendly (PMF): Semantic annotations to improve the effectiveness of password managers http://mypico.org/documents/2014-StaSpeJen-pmf.pdf

The killer thing that we should standardise is a way to change passwords on websites through password managers:

- Closing ex-employee accounts and/or changing passwords imposes manual work

- Rotation policies imposes manual work

It's not so much hassle registering via 1password or lastpass using browser extensions, which implicitly cover a lot of the spec (by automatically assuming the site accepts strong passwords then generating complex passwords).

As I tried to explain to a "security researcher" suggesting Login-Links-via-Email was a better primary auth system than passwords, the Password Manager problem can absolutely be solved without changes to the websites/webapps themselves, because one password manager already solves it:

Safari + iCloud Keychain.

Managing passwords used to always be one of the features of a browser. Why so many browsers do it so poorly now as to warrant an entire market for third party password managers is beyond me.

And I know, not everyone uses Safari and not everyone who does uses iCloud - my point is not that everyone should be forced to use those two - I'm saying if Apple can do it, why can't Google provide a good password manager in Chrome, why can't Mozilla provide a good password manager in Firefox, why can't Microsoft provide a good password manager in IE/Edge?

I really like this and hope this sort of thing takes off.

Account management is something practically all online services need and it is re-implemented by all web applications.

Logging in via a mobile device sucks sometimes with long passwords. It would be cool if the password database client could also act as the 'hub' for pending logins. So that you could permit a login to occur.

I have written about account management protocols: https://github.com/samsquire/ideas#52-account-management-pro...

This is a protocol (or specification)... do you think this might conflict with the naming of Python's pep8?

One of the major problems is that we're still sending passwords to the server. We need better protocols, like SRP to enable us not to send the server clear-text passwords. (Yes, I consider it clear-text even over TLS because the server still sees the password in all its glory.)

For people interested in redesigning how web site authentication is performed, I would encourage a look at the FIDO Alliance specifications for "Passwordless UX" and "Second Factor UX":

https://fidoalliance.org/specifications/overview/

The problem with redesigning how web site authentication is performed is always that it requires support (or at least extensions) in the browser the user is using, as well as in the websites the user is logging into.

Both Microsoft and Google are members of the FIDO Alliance, so maybe these specifications may actually go somewhere. (Sadly, Apple is absent from the member list.)

Given this is totally dependant on a million different backend coders, none of whom will read this document, can I suggest:

HTML 5 gets a password "field" that is an obligatory two fields INPUT and TEXTFIELD. iNPUT stays the same as now for backwards compatibility and the larger field is where I / Firefox pastes my public key.

At this point we are starting everyone on the sensible path to client certificates and yet have a fall back position of the curren bork'ed password setup.

For the simplest next step web servers can just do simple challenge response over SSL to ensure I hold my "certificates" private key.

The best cannot prevent good enough coming through

How about standardising around second factor authentication with cell phones?

Simple and easy. There are issues with losing the phone, but as long as there are ways to lock an account, or alternate second factors.

The FIDO standards suggest second factor auth (U2F, iirc) but with a 'device' (like a USB dongle). I tend to think phones are a pretty ubiquitous approach. And the more this technique is used the more likely there will be OS extensions that automate the process, for mobile browsing.

Are there known defeaters I'm not aware of for this?

This assumes cooperation with password managers. Places with arcane password requirements also hate password managers.

After Firefox discontinued the ability to prevent usage of its internal password manager, my bank warns me to turn the feature off.