
Show HN: PEP – an idea to help bring password managers to the masses - brownbat
http://pastebin.com/tW9yWegZ
======
Direct
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.

~~~
brownbat
> Maybe I'm missing something, but unless this somehow eases the distance
> between password based authentication and other methods

Spot on.

PKI would be a good endpoint, but adoption is slow, probably because it's a
weird leap for a lot of people. So I see this as a transitional step, a
methadone for our addiction to passwords, because it could get people used to
passwordless logins. It could help people adapt to a service or dongle that
handles all their authentication. After that, it's a short hop to have PMs
just become "authentication providers," and have them and websites figure out
the best backend.

Thanks though, it's a fair point to keep in mind, PKI might even be worth
holding up as the ideal in the protocol.

------
WalterGR
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.

~~~
vbezhenar
Use a-z and compensate with 1-2 more characters. 12 character password is
practically unbreakable. Make it 15 and sleep well. Unless you're dealing with
stupid site that knows better how your password should look like. Then you're
out of luck.

~~~
WalterGR

         Unless you're dealing with stupid site that knows better how
         your password should look like. Then you're out of luck.
    

Yup. And that's quite common in my experience.

------
dgoldstein0
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.

------
task_queue
Let's see if Guido will accept this into 3.6

------
StavrosK
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.

~~~
dustinrodrigues
Probably shouldn't just be using HTTP for a password change.

~~~
StavrosK
HTTP is the protocol, all HTTP needs to go over TLS anyway.

------
asdfaoeu
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.

------
moreati
See also

SWAMP, or Standardised Web Account Management Protocol
[https://github.com/ashward/swamp](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](http://mypico.org/documents/2014-StaSpeJen-pmf.pdf)

~~~
brownbat
Wow, SWAMP is great, nice find!

------
tonyhb
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).

------
stephenr
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?

~~~
StavrosK
Because I use Chrome on my phone and Firefox on my computer, and I don't even
have my password manager on my friend's computer at all.

~~~
a3n
If your password manager is on your laptop, how do you recover all your
passwords if your laptop is no longer accessible (broke or stolen)?

~~~
StavrosK
I have it synced to my things, which is why I can't rely on only my browser
storing passwords to sites, I also need a UI where I can see those passwords.

~~~
stephenr
Any browser/OS based password manager (such Safari/iOS/OSX/iCloud keychain)
makes passwords visible to the user when required.

------
samsquire
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...](https://github.com/samsquire/ideas#52-account-management-protocols)

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

~~~
clintonc
PEP generally stands for Python Enhancement Proposal -- PEP 8 isn't the only
one.

------
jimktrains2
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.)

~~~
StavrosK
When has sending the password to the server over TLS ever cause any breaches?
Every breach I know was because data at rest was poorly kept, on either side.

~~~
jimktrains2
Yes, and if the server has access to your clear-text password, it can choose
to store it insecurely. Something like SRP enforces that the server store them
in a secure manner.

------
reipahb
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/](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.)

------
lifeisstillgood
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

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

What happens when you lose your private key?

What happens when you change machine?

~~~
lifeisstillgood
What happens when I lose my car key? I have to provide proof of identity and
ownership to a trusted and specialised business provider who then allows me
access again.

What happens when I lose my client certificate? Should be the Same thing.
Otherwise the value to me of the website being protected is worth less than
that of my car.

Really most websites are using security in the same way the local bar uses
human based facial recognition "oh hi paul, your usual?"

Since there is next to no value in a Facebook feed, I will make a rational
decision as to how much cost of effort I will put in to get access back.

~~~
davnicwil
That's an interesting point, replacing a lost key is always going to be the
weak point in any security scheme, unless you intentionally make the process
hard/cumbersome enough that it isn't, but makes losing the key a very
unpleasant, costly event both for the user, and the service you're trying to
access.

Why would businesses like Facebook implement such a scheme? As you predict it
would probably end up in them losing a lot of customers when keys are lost.

I think any business, even where security is critical, would worry about this
too. I.e. 'what, my bank makes me call up their customer service, wait on
hold, speak to 8 different individuals, then wait three days for processing,
if I lose my key? No thanks, remembering a strong password seems an easier
alternative - I'll just go to a competitor that allows that'.

That's not even to mention wrapping up the scheme in an easy-to-use way for
non-technical users. It'd be fine until the point it isn't, at which point the
customer service / PR fallout cost of things going wrong is very high.
Everyone understands passwords.

I think there are enough problems here that such a scheme would likely not
have enough adoption to become mainstream.

But I think more importantly, isn't the fact that your key(s) would have to be
tied to a physical client the true deal-breaker? A website that you can only
access from a certain set of physically secured devices with the correct keys
installed throws away perhaps the biggest advantage of the web.

~~~
lifeisstillgood
I remain unconvinced. Most web sites deliver very little value to the end
user. I mean if the government right now made us pay for each site we used,
how many would you choose as worth ten bucks a month?

So when there is a base level of security that makes us question the value of
access to a given site, we shall see changes in how identity and personally
identifiable data is used.

This I think is a Good Thing.

So, it is highly likely two factor auth will be a minimum standard for any
site that's got anything of value - look at Target or the OPM. And if you want
to connect to and use those sites you must have the right dongle. That's is a
real pain. But you won't be allowed in otherwise.

Target will still let you in the front door to spend money, but as they really
cannot give every shopper a Target two factor auth, they will subcontract that
out to hardware suppliers like Apple Pay.

So we stop spreading our pollution every which way and start building sewers -
Apple as the data sewer pipe provider ... Hmm.

Now two factor auth is from the site owner to us. A physical key exchange.

A web of trust is a much different proposition (liberty wise) and might come
through things like OPM debacle. Giving every Covil servant a dongle might
work but giving them a master cert and then signing the Certs they generate
for their phone every so often seems more manageable - and will flow out to
passports, drivers licences etc.

So I do t really know much - and my brain is under flu-like attack but the
ideas are floating out there.

------
sago
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?

------
TD-Linux
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.

~~~
seanp2k2
What? Why? Why wouldn't they just move that to an about:config flag or
something? That seems very useful.

~~~
bazzargh
TD-Linux means they discontinued the ability _for sites_ to prevent usage of
the password manager, not that you can't disable it yourself.

[https://bugzilla.mozilla.org/show_bug.cgi?id=956906](https://bugzilla.mozilla.org/show_bug.cgi?id=956906)

