6 ms·

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

46 points by brownbat 11y ago

tonyhb 11y ago
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).
jwcrux 11y ago
This is a protocol (or specification)... do you think this might conflict with the naming of Python's pep8?
- clintonc 11y ago
  PEP generally stands for Python Enhancement Proposal -- PEP 8 isn't the only one.
- a3n 11y ago
  I harumphed when I saw the acronym PEP, because of Python's prior use. And I've harumphed a few times in recent years because of similar multiple-use of names and acronyms. Enscript comes to mind. https://en.wikipedia.org/wiki/Enscript https://en.wikipedia.org/wiki/Enscript But as computer and internet use becomes more a part of daily existence, we're just going to have to get used to it. People who are involved in niche communities, even those whose names and products came first (like Python's PEPs) are just going to have to get used to mentally shifting context.
task_queue 11y ago
Let's see if Guido will accept this into 3.6
asdfaoeu 11y ago
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.
TD-Linux 11y ago
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 11y ago
  What? Why? Why wouldn't they just move that to an about:config flag or something? That seems very useful.
  - bazzargh 11y ago
    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
Direct 11y ago
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 11y ago
  > 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.
moreati 11y ago
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 11y ago
  Wow, SWAMP is great, nice find!
WalterGR 11y ago
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.
- imaginenore 11y ago
  If your password is even 10 characters (alphanum, upper and lowercase = 62 characters), it's already safe enough for the most sites that properly hash your passwords and don't allow many attempts. Passwords for more sensitive sites, like banking, should be longer of course, 20 characters gives you 119 bits, 30 characters gives you 178 bits.
  - aikah 11y ago
    lol my bank only accepts 4 digit numbers passwords.
    - my_username_is_ 11y ago
      My credit union used to have a similar, although not as bad, password policy. I believe password length had to be between 8 and 10 alphanumeric characters, and then there were other crazy rules that reduced the entropy of passwords further. I think there had to be at least 3 numbers in the password and it couldn't start with a number. It took them years before they finally listened to reason and allowed you to have a stronger password
    - a3n 11y ago
      My (new) bank USAA has some password policy which I forget, but I vaguely remember the green bar growing longer as I typed in my proposed password. To log in to the site I have to supply my login/password, then on the next page my 4 digit pin, then on the next page the answer to one of three rotating security questions. On the phone app, after the phone was authenticated the first time, I only have to enter my 4 digit pin to access my account. IIRC, that policy is at my option. I'm not sure if that's all a good thing, or theater, but that's what they have.
dgoldstein0 11y ago
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.
lifeisstillgood 11y ago
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 11y ago
  > 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 11y ago
    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 11y ago
      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.
reipahb 11y ago
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.)
jimktrains2 11y ago
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 11y ago
  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.
  - schrodinger 11y ago
    Heartbleed
  - jimktrains2 11y ago
    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.
stephenr 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        Any browser/OS based password manager (such Safari/iOS/OSX/iCloud keychain) makes passwords visible to the user when required.
samsquire 11y ago
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-protocols https://github.com/samsquire/ideas#52-account-management-pro...
sago 11y ago
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?
StavrosK 11y ago
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 11y ago
  Probably shouldn't just be using HTTP for a password change.
  - StavrosK 11y ago
    HTTP is the protocol, all HTTP needs to go over TLS anyway.

46 points by brownbat 11y ago

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

jwcrux 11y ago

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

clintonc 11y ago
PEP generally stands for Python Enhancement Proposal -- PEP 8 isn't the only one.
a3n 11y ago
I harumphed when I saw the acronym PEP, because of Python's prior use. And I've harumphed a few times in recent years because of similar multiple-use of names and acronyms. Enscript comes to mind. https://en.wikipedia.org/wiki/Enscript https://en.wikipedia.org/wiki/Enscript But as computer and internet use becomes more a part of daily existence, we're just going to have to get used to it. People who are involved in niche communities, even those whose names and products came first (like Python's PEPs) are just going to have to get used to mentally shifting context.

task_queue 11y ago

Let's see if Guido will accept this into 3.6

asdfaoeu 11y ago

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.

TD-Linux 11y ago

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 11y ago
What? Why? Why wouldn't they just move that to an about:config flag or something? That seems very useful.
- bazzargh 11y ago
  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

Direct 11y ago

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 11y ago
> 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.

moreati 11y ago

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 11y ago
Wow, SWAMP is great, nice find!

WalterGR 11y ago

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.

imaginenore 11y ago
If your password is even 10 characters (alphanum, upper and lowercase = 62 characters), it's already safe enough for the most sites that properly hash your passwords and don't allow many attempts. Passwords for more sensitive sites, like banking, should be longer of course, 20 characters gives you 119 bits, 30 characters gives you 178 bits.
- aikah 11y ago
  lol my bank only accepts 4 digit numbers passwords.
  - my_username_is_ 11y ago
    My credit union used to have a similar, although not as bad, password policy. I believe password length had to be between 8 and 10 alphanumeric characters, and then there were other crazy rules that reduced the entropy of passwords further. I think there had to be at least 3 numbers in the password and it couldn't start with a number. It took them years before they finally listened to reason and allowed you to have a stronger password
  - a3n 11y ago
    My (new) bank USAA has some password policy which I forget, but I vaguely remember the green bar growing longer as I typed in my proposed password. To log in to the site I have to supply my login/password, then on the next page my 4 digit pin, then on the next page the answer to one of three rotating security questions. On the phone app, after the phone was authenticated the first time, I only have to enter my 4 digit pin to access my account. IIRC, that policy is at my option. I'm not sure if that's all a good thing, or theater, but that's what they have.

dgoldstein0 11y ago

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.

lifeisstillgood 11y ago

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 11y ago
> 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 11y ago
  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 11y ago
    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.

reipahb 11y ago

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

jimktrains2 11y ago

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 11y ago
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.
- schrodinger 11y ago
  Heartbleed
- jimktrains2 11y ago
  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.

stephenr 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      Any browser/OS based password manager (such Safari/iOS/OSX/iCloud keychain) makes passwords visible to the user when required.

samsquire 11y ago

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

sago 11y ago

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?

StavrosK 11y ago

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 11y ago
Probably shouldn't just be using HTTP for a password change.
- StavrosK 11y ago
  HTTP is the protocol, all HTTP needs to go over TLS anyway.