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).
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
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.
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:
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.
> 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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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":
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.)
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.)
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.
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.
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 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.
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.
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?
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.
42 comments
[ 2.9 ms ] story [ 63.0 ms ] thread- 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).
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.
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:
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.
After Firefox discontinued the ability to prevent usage of its internal password manager, my bank warns me to turn the feature off.
https://bugzilla.mozilla.org/show_bug.cgi?id=956906
I'm a little confused.
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.
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
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.
Passwords for more sensitive sites, like banking, should be longer of course, 20 characters gives you 119 bits, 30 characters gives you 178 bits.
It took them years before they finally listened to reason and allowed you to have a stronger 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.
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.
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
What happens when you lose your private key?
What happens when you change machine?
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.
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.
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.
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.)
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?
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...
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?
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.