
A well-known URL for changing passwords - fanf2
https://github.com/WICG/change-password-url
======
gregmac
This is a nice simple convenience feature, for sure [1]:

> example.com provides a /.well-known/change-password resource which redirects
> to their change password form, wherever it happens to already be.

> Password managers check for the existence of /.well-known/change-password on
> [https://example.com](https://example.com).

> If it's there (the response code is 2xx or 3xx), the password manager can
> cause the user's browser to navigate there when the user indicates they'd
> like to change their password.

It's not trying to enforce a particular password schema, it's not an API
endpoint to automate changing passwords, and it is not trying to dictate site
design or form layout.

It's also dirt simple to implement with practically zero cost.

Aside from Safari, it doesn't seem like any password managers have implemented
this yet. It's also not in the IANA well-known URI registry [2] yet (even as
draft), so that would probably at least allow it to get a bit more traction.
Apparently they are working towards that [3].

[1] [https://github.com/WICG/change-password-url/blob/gh-
pages/ex...](https://github.com/WICG/change-password-url/blob/gh-
pages/explainer.md#proposal)

[2] [https://www.iana.org/assignments/well-known-uris/well-
known-...](https://www.iana.org/assignments/well-known-uris/well-known-
uris.xhtml)

[3]
[https://twitter.com/rmondello/status/1042008520105779206](https://twitter.com/rmondello/status/1042008520105779206)

~~~
hoppelhase
How about something like:

    
    
      /.well-known/delete-account
      /.well-known/request-user-data
    

This would also be nice as we wouldn't need things like
[https://justdelete.me](https://justdelete.me)

~~~
dfabulich
I can't imagine those taking off without legislation. Making it easier to
change passwords is more or less in the interest of the companies who make web
sites; making it easier to delete accounts or export all of your data, by
comparison, is not.

~~~
onion2k
Until users decide that the businesses interests of the companies that run the
websites they use are less important than their own interests these features
will never catch on. How about we stop using websites that fail to implement
things that are good for _us_?

In fact, someone could write a browser plugin to put a screen between the user
and the website that states "This website fails to implement .well-known link.
Are you sure you want to continue?" like Chrome does for sites that have
borked DNS. If a reasonably large number of people used that you'd see lots of
sites implement this idea without needing regulations. I'd use that.

~~~
brokenmachine
But then how would users get to Facebook? /s

You could have that plugin have a database of sites and also provide easy
links for those sites that try to hide those functions.

------
greycol
A lot of people in this thread seem to be unaware of the purpose of /.well-
known/ .

You can read the memo about it here:

[https://tools.ietf.org/html/rfc5785](https://tools.ietf.org/html/rfc5785)

Basically /.well-known/ is a place to check for common site meta data and you
can suggest new urls that can be registered.

/.well-known/change-password

Has been accepted and added for the use case of pointing to where to change
your password.

If you think this is insufficient then there is nothing stopping you from
trying to put forward a more comprehensive proposal for say /.well-
known/change-password-api that would contain all the meta data for whatever
standardized scheme for informing multifactor/username/email api combinations
you eventually come up with. Just because /.well-known/change-password exists
it does not in any way limit what other suggestions can be made and
implimented later (it only means that you need to use a different url).

------
peterwwillis
Here is the actual spec: [https://wicg.github.io/change-password-
url/index.html](https://wicg.github.io/change-password-url/index.html)

Presumably this is only for accounts you are already logged into and want to
change the password of, since change password forms usually aren't accessible
unless you are already logged in.

However, the same domain may involve multiple account types. AWS and other
popular websites have multiple types of accounts, different login methods, and
different change-password forms, on the same domain. If all this URL does is
redirect to one single page per domain, it won't work for cases of more than
one type of login.

Also, it seems that password _reset_ is a lot more common than just changing a
password, so maybe this spec could be extended to that form, too?

~~~
nine_k
I wonder if URLs like /.well-known/login and /.well-known/logout would be a
good idea, and should belong to a similar spec. Maybe even /.well-
known/register, too.

~~~
marcosdumay
Why not use simple HTTP authentication?

~~~
munk-a
A lot of site design requirements won't fit well with simple HTTP auth. If the
company wants to display a password recovery link or display pricing
information to potential customers it's incompatible with using HTTP auth
without a lot of extra bells and whistles.

These are all relatively common business requirements.

------
isostatic
They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this
feature.

And sure enough, [https://www.icloud.com/.well-known/change-
password](https://www.icloud.com/.well-known/change-password)

Looking through the referenced RFC, there's a whole raft of "well known" urls
that are registered

[https://www.iana.org/assignments/well-known-uris/well-
known-...](https://www.iana.org/assignments/well-known-uris/well-known-
uris.xml)

How widely adopted are these?

~~~
Someone1234
The one that Apple's browsers request on every domain isn't even in the list:

/.well-known/apple-app-site-association

That's the only .well-known request we have in our logs from the last year or
more. Seems to be looking for an app associated with our site.

Aside from that, I don't know anyone or anything else using .well-known. Seems
to be an Apple thing.

~~~
eponeponepon
I think LetsEncrypt uses it, no?

~~~
toupeira
Yes, also OpenID Connect.

~~~
merb
sadly only for discovery. but it would be great if oauth/openid connect would
actually use .well-known/authorize, etc. instead each provider has it's own
sauce.

------
hannob
That looks like a good idea, but why not go one step further? Provide a common
API interface for password changes.

Think about it: If you assume your pw manager database is compromised - what
do you do? Go to a hundred webpages and change your password? probably not.
Your PW Manager can't provide a feature to do it for you. But it could if
there was such an API.

~~~
asdkhadsj
On that note though, if we start using standard APIs for this sort of thing, I
question whether we should just go farther and "solve" the problem.

Ie, as a dumb example, why should I expect them to implement an API for my
password manager, and instead not simply allow oauth where my pass manager
becomes my token provider?

Doesn't that fake example solve both problems, while also getting rid of
bizarre password churn? Sure, it has the downside of _" what happens when my
password provider is compromised.."_ but that's always true, right?

An API for password managers feels like a solution to a problem we've created.

Don't get me wrong, I love the idea of reducing password churn. I'm just not
sold on this specific method of handling it.

~~~
buster
I think you answer yourself already. You expect this:

> simply allow oauth where my pass manager becomes my token provider

to be a simpler implementation then "PUT [https://blabla.com/change-
password"](https://blabla.com/change-password") or whatever a password change
request would look like?

~~~
WorldMaker
That "simpler implementation" of PUT [https://example.com/magic-api/change-
password](https://example.com/magic-api/change-password) has all sorts of
security concerns you aren't considering. How do you stop "rogue" password
managers from using it? How do you stop replay and man-in-the-middle attacks?

The other poster is correct that immediately people would jump to using OAuth
as one solution to manage which password manager apps can access that change
password flow somewhat securely. At which, yes, why not just invert the OAuth
flow and find better ways to make the Password Manager the provider rather
than [https://example.com](https://example.com) and maybe eliminate the
password entirely from the equation while we are at it.

~~~
buster
> How do you stop replay and man-in-the-middle attacks?

Replay what? Me setting my password over HTTPS? How?

The sample URL was deliberately just an example. It would surely need more
thought but i'm pretty sure the "PUT ..." solution is simpler then throwing
oAuth at the problem.

So you're confident that the same people who can't secure the simple PUT
request are better suited to implement the custom oAuth solution you are
talking about? And that will be secure? I'd bet against that.

~~~
WorldMaker
I'm saying that the closest thing we have to a well-adopted standard for
securing a "simple PUT request" for something as security critical as a
password is called OAuth.

You need CSRF tokens to avoid replay attacks. You need some way for an app to
Authorize: that they have permission to update someone's password. That's
probably some sort of application whitelist. That application whitelist
probably needs a permissions flow for a user to agree that Password Manager
Brand X is indeed their password manager application of choice. Do we have a
standard for such permission flows and app-specific bearer tokens? Oh look,
it's OAuth that says "hi".

~~~
buster
You're clearly far too deep into the oAuth mindset:

    
    
      - You don't need "persmissin flows"
      - You don't need "to update *someone's password" (just your own!)
      - You don't need an "application whitelist" because HTTP doesn't know what an application is
    

All you need is to say "hey, here is my current password/hash. Update it to
this one." on a secure channel (let's say, HTTPS). Alternatively "Hey, i am
XYZ and this cookie tells you so. Update my password to XXX". I'm pretty sure
there are a gazillion ways to securely make a request to some URL to update a
password.

~~~
WorldMaker
You're clearly not thinking of repercussions of having an open REST endpoint
that anyone on the internet could just curl/postman/httpie to change someone's
password.

Good password change forms have had CSRF tokens for _decades_ now:
[https://en.wiktionary.org/wiki/CSRF_token](https://en.wiktionary.org/wiki/CSRF_token)

There are many known attacks whereby an attacker changes someone's password to
control an account.

I don't care about OAuth at all. It's not an "OAuth mindset", it's a "I
wouldn't trust a website at all in 2018 if it had an unsecure PUT endpoint to
change my password" mindset.

HTTPS alone is not sufficiently secure. It's a start, but it is nowhere near
enough on its own. SSL MITM attacks and Phishing are still problems today.

Requiring my current password isn't necessarily sufficient either: password
cracking botnets exist. If the first sign that your password was cracked is
that your password was changed to something only your attacker knows, that's
not great. This is also where replay attacks come in. An attacker MITM or
phishes this endpoint, and social engineers you into thinking you need to
change your password, they get your old and new password together in one nice
bundle.

Cookies aren't a sufficient answer for similar reasons. Again, take a look at
cross-site request forgery issues and the history of replay attacks on
password forms.

Application whitelists are a _minimal_ security precaution to mitigate some
botnets and phishing algorithms. HTTP does know what an application is, we
often see application blacklisting done the hard way with User Agent strings
and IP address ranges. Whitelisting is a more secure approach, but a lot
harder to do securely (and why we have standards like OAuth; OAuth isn't the
only answer, it's just the current easiest answer).

~~~
buster
> that anyone on the internet could just curl/postman/httpie to change
> someone's password.

But that's my point. Keep it simple, let my password manager (be it on my
mobile, laptop or whereever i want) change my password! Yes, i'd like that.

You don't even need that CSRF token, i don't know why. To prove your identity
you'll only need to prove that you know you your password. That's possible,
securely. See
[https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol)
and [https://en.wikipedia.org/wiki/Zero-
knowledge_password_proof](https://en.wikipedia.org/wiki/Zero-
knowledge_password_proof)

Why do you need an application whitelist?! The website i am visiting isn't
whitelisting my browser, so why would it need to whitelist my password
manager?

~~~
WorldMaker
How lucky for you in 2018 that you don't seem to have any trouble with botnets
trying to crack your passwords, hack your accounts, or even just break your
accounts so that you cannot use them.

~~~
buster
Exactly. Most password leaks seem to come from hacked websites and thus badly
implemented security. And that's another point i was making: Keep it simple
but secure, so that implementors have it simple and don't mess it up.

Can you point me to some source for botnets which crack passwords? I would be
surprised. It's not feasible to brute-force a password over HTTP.

~~~
WorldMaker
My Steam account has had high entropy, sole use passwords cracked in the
timeframe of months, which would seem to indicate (if Valve is not leaking
[1]) a botnet using their "simple" HTTPS login endpoints to brute force
passwords. So far Steam Guard (2FA) has stopped the attacks, but that doesn't
make me feel that much better given the speed in which the passwords seem to
be cracking.

That's just one account I see as currently most at risk. There are plenty of
others I'm concerned about as well.

Passwords are fragile, brittle things. "Simple" security is _no longer_ an
answer when dealing with passwords. FULL STOP. It's time we moved past
passwords altogether, but even where we can't, we absolutely have to be
serious about password security from top to bottom.

You can victim blame "hacked websites" for "badly implemented security" all
you want, but that's part of the point, too. Password infrastructure will
always be lowest common denominator, because it is "easy", because it is
"simple". _Everyone_ thinks they can implement password security, and
_everyone_ is wrong. There are still people that don't hash, much less salt,
their passwords in 2018. There are still people that don't realize "Security
Questions" are Plaintext Passwords and a giant security risk. In the age of
bitcoin mining there is no such thing as a hashed or salted password that
cannot be brute forced. Bitcoin mining is password brute force at massive
scale, and dropped rainbow table hardware to the price floor.

I'm sorry that you still have any illusions left that passwords are and/or can
be "simple". Passwords are dead and yet we're all going to be fighting that
forest fire for decades to come.

[1] Which admittedly, is a possibility, but it would be a surprising shock for
an application as big as Steam.

------
Someone1234
Seems like a nice subtle way to hijack the changing password mechanism,
particularly on a sub-domain you control. Just set the URL to e.g.
"[https://evilsite/changepasswords"](https://evilsite/changepasswords") and
wait for Password Managers to be updated.

The fact that the spec says nothing about where a user can be redirected, and
which domains/sub-domains are within scope for which change password requests
seems like an oversight.

For example if my password manager saves a password for login.example.com, is
a .well-known/Change-Password on evil.example.com, or example.com in scope?
Who decides? Is it left to the password manager to figure out the security
scope?

~~~
Ajedi32
I don't understand your concern. If the attacker controls
`[https://example.com/.well-known/change-password`](https://example.com/.well-
known/change-password`) wouldn't they also control
`[https://example.com/my_profile/settings`](https://example.com/my_profile/settings`)?

Why bother redirecting the user to a third party site when you can just inject
some password-logging JS into the _legitimate_ change password form?

~~~
Someone1234
If an attacker controls a subdomain and can trick a user into visiting it
(e.g. evil.example.com), the cookies may be out of scope, but the password
manager may (or may not) treat the subdomain as part of the domain in terms of
.well-known/change-password requests, allowing a subdomain to redirect the
password manager and potentially stealing credentials.

It is undefined behaviour. The spec is under-defined. That's my issue, there
has been no security pass of this at all. It is left up to each individual
password manager to make this secure (or not).

~~~
Ajedi32
I still don't see your point.

If your password manager autofills your credentials for `example.com` when you
visit `evil.example.com` then the owner of `evil.example.com` already has an
easy way to steal your credentials regardless of whether or not this spec is
implemented.

------
curo
This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email
from Teachable about an email & passwords breach.

If you're a startup and you're storing plaintext passwords out of expediency,
realize you're doing a massive disservice to your customers. It seems they
changed this in 2015, but didn't go back and fix it for their earliest
adopters. Your early adopters make you what you are! Protect their data. And
if you do mess up, don't send out a self-focused apology from a no-reply
address.

 _We are writing to inform you of a suspected data breach involving accounts
created between September 17, 2013 and November 21, 2015. We have reason to
suspect that personal information related to accounts on Bitfountain (joined
2014-08-18) may have been compromised. This includes the email addresses and
passwords associated with the school 's Teachable (formerly Fedora) account.

As a precaution we are enforcing password resets...If you happen to use this
password with any other service, we highly recommend updating your password
there as well.

We apologize for the inconvenience, and thank you for your understanding in
helping us keep Teachable safe. _

~~~
pc86
Storing plaintext passwords is no faster than storing a cryptographically
secure hash of the same password. We're not even talking lines of extra code,
just a few extra characters actually hash the input.

It's not expediency, it's laziness bordering on criminal stupidity/negligence.

~~~
jmeyer2k
Well it should be faster than storing a cryptographically secure hash. If
hashing the data is too fast, an attacker could just brute force all of the
passwords.

~~~
kingo55
That's why you should always use salt with your hash.

Unsalted, your password hash =

Hash({{Your Password}})

The attacker can brute force it from a dictionary or stepping through
characters (possibly from another breach somewhere, or a silly password like
boobies123).

Salted hashes are way more secure:

Hash({{Your Password}} + {{Secret}})

Now the attacker has to guess an extra secret phrase, which is often really
long, that was fed into the hash function along with the user's password. And
due to the beauty of one way hash functions both salted and unsalted hashes
use the same amount of bytes in the DB... It's a no brainer.

~~~
dancek
The reason to use a salt is mostly that an attacker doesn't then have a
precomputed library of hash values.

Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they
store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid
attacker can google for a hash search engine, input the hash and get the
password in seconds.

On the other hand, with salting the value to be hashed could be something like
'luser@fail.com:@362#^h6329hgtew:gwpmkq'. That won't be precomputed anywhere.

Of course it's also a good idea to either try to keep the salt secret or use a
per-user random salt (which you store in the database). But when someone gets
a full database dump, chances are they'll also get the salt.

~~~
kibibu
The specific attack that per-user random salts are designed to prevent are
pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using
rainbow tables, so the benefits are possibly dubious.

~~~
frenchy
Who uses MD5 for hashing password anymore?

~~~
pc86
People one step above those who think storing plain-text passwords is okay.

------
JackC
I see the argument for simplicity, but I think it would be much more impactful
to have a well-known URL for automated password changes.

It's common to see advice to "change all your passwords" following incidents
like Heartbleed or Cloudbleed or after having a personal computer hacked.[0]

This advice is useless -- it's way too time consuming, and also comes too
late. If you need to change all your passwords now, you actually needed to do
it six months ago.

A well-known URL that specified password requirements and an endpoint to hit
with username, old and new passwords would let password managers reliably and
routinely update passwords instead. To the extent "change all your passwords"
is ever good advice, it would become advice you could follow automatically
instead of never.

[0] Example of the form:
[https://securitywatch.pcmag.com/hacking/322494-heartbleed-
fa...](https://securitywatch.pcmag.com/hacking/322494-heartbleed-fallout-
change-all-your-passwords)

~~~
Klathmon
There's room for both ideas.

This one has the benefit of being stupid simple to implement and maintain. In
10 minutes I can throw this together for all of our login stuff.

But a fully automated password changing system/API? That's not exactly as
"maintenance free". Now you are maintaining a full API separate from your
normal routines, and it's in an area that I always advocate for simplicity
since subtle mistakes can mean compromised accounts. And the "fully automated"
API would also have to work with "multi-factor" systems, which alone make
everything more complicated to cover all the different ways it's done.

Don't let the possibility of a better solution kill the benefits of this
simpler one.

------
ghostly_s
From the spec:

> Servers must not locate the actual change password page at the change
> password url, per RFC5785 §1.1 Appropriate Use of Well-Known URIs.

I scanned the RFC but can't fine the prohibition against this. Curious, why
does it matter? Just because .well-known URLs are not meant to be exposed to
the user?

~~~
TazeTSchnitzel
That section says:

    
    
       There are a number of possible ways that applications could use Well-
       known URIs.  However, in keeping with the Architecture of the World-
       Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
       for general information retrieval or establishment of large URI
       namespaces on the Web.  Rather, they are designed to facilitate
       discovery of information on a site when it isn't practical to use
       other mechanisms; for example, when discovering policy that needs to
       be evaluated before a resource is accessed, or when using multiple
       round-trips is judged detrimental to performance.
    

I am guessing they consider “general information retrieval” and “URI
namespaces” to exclude it.

~~~
ghostly_s
I did see that section, but don't see how it follows. Putting your PW reset
page at this address would be using the URI spec for exactly it's intent, not
“general information retrieval”. My read of this clause is just that they
don't want you to start using .well-known as your primary namespace or
cluttering the registrations with junk that's not broadly applicable.

------
crescentfresh
Can someone clarify, is this actually for resetting a forgotten password? I
don't quite follow.

example.com's _change password_ functionality should be behind an
authenticated page that requires a) the user be already logged in, and 2) the
user's current password (for confirmation).

Whereas example.com's _forgot /reset password_ functionality is usually a
wide-open page anyone can reach to begin the process of password reset (more
inline with what this spec seems to be describing).

~~~
intertextuality
Did you read the explainer?

> Currently, if the user of a password manager would like to change their
> password on example.com, basically all the password manager can do is load
> example.com in a browser tab and hope the user can figure out how to update
> their password themselves.

> The goal of this spec is to do the simplest possible thing to improve this
> situation.

It's an attempt to standardize the endpoint for changing a password. Which is
kinda random for each website currently.

~~~
crescentfresh
> Did you read the explainer?

I did. My confusion arose from it. Something is clear to you that is not to me
:)

~~~
JW_00000
[https://news.ycombinator.com/.well-known/change-
password](https://news.ycombinator.com/.well-known/change-password) will just
redirect to
[https://news.ycombinator.com/changepw](https://news.ycombinator.com/changepw).
If the user isn't logged in, that page asks the user to log in.

~~~
crescentfresh
Ah I see, and from the perspective of a password manager it would know what
password to fill into the password field to get the user into the site. After
that, once on the change password screen said manager would also take over
generating a new password, yes?

------
juancampa
I haven't read the proposal but it made me think of something like:

/.well-known/personal-access-token

To get an access token for API access to my own data. You know, for our right
to be represented by a bot[1]

[1] [https://continuations.com/post/172413445510/we-need-
mandator...](https://continuations.com/post/172413445510/we-need-mandatory-
enduser-apis-for-social-and)

------
wolfgang42
Actual spec here: [https://wicg.github.io/change-password-
url/index.html](https://wicg.github.io/change-password-url/index.html)

------
pbnjay
ooh can we also get /.well-known/delete-account ??

seriously though, I would love this for all those sites that bury it as far as
possible...

~~~
NickBusey
This would be great, but like you said, the sites you would really want to use
this for would likely never implement it. Unless it were a requirement of
something like GDPR..

------
ancorevard
Used by Safari for website password it identifies as used on multiple
websites.

------
soheil
> If it's there (the response code is 2xx or 3xx), the password manager can
> cause the user's browser to navigate there when the user indicates they'd
> like to change their password.

The primary issue I see here is that there are a lot of websites that do 301
redirects from either non-www to www subdomain or non-https to https, would
this not confuse the password managers in assuming there is a .well-known even
though it’s just a benign redirect?

~~~
hober
This is being tracked by [https://github.com/WICG/change-password-
url/issues/4](https://github.com/WICG/change-password-url/issues/4)

------
soheil
One thing I really wish when it comes to Firefox Containers if I create a
container for Gmail and am logged into Google I want all the email links
(mailto:) to open in that container. I know currently you can have all the
sites with a specific URL to open in specific containers but I'm not sure if
there is a way to open various protocols in separate containers.

------
masa331
I wish every site would just use emailed sign-in links instead of passwords.
We wouldn't have to deal with all these password relative nonsenses - password
managers, .well-knowns, password requirements, password resets, weak
passwords, gazilion passwords in my head. Everything would be so much simpler

~~~
epse
And then your email gets compromised and everything is immediately lost? No
thanks

~~~
Rjevski
Everything is already lost if your email is compromised as they can just use
the "forgotten password" functionality and reset it thanks to their access to
your email.

~~~
tracker1
And that is why I have a 2FA app for my email.

------
noResetPage
[https://wicg.io/.well-known/change-password](https://wicg.io/.well-
known/change-password)

Also:

[https://news.ycombinator.com/.well-known/change-
password](https://news.ycombinator.com/.well-known/change-password)

------
tnorthcutt
After learning about this a few days ago, I created a Laravel package for
managing .well-known URLs: [https://github.com/tnorthcutt/laravel-well-
known](https://github.com/tnorthcutt/laravel-well-known)

I plan to add other URLs that make sense as well.

------
ndnxhs
YES, this is what I have been waiting for. A month ago I lost a USB with my
keepass file on it. The file is encrypted with a good password but I would
feel better if I could reset all my passwords just in case but that would take
me days.

------
janikvonrotz
It up to browser standards to make this thing reality. example.com does not
have any incentive to provide this url. However, if a users browser would
treat sites implementing this feature as "more secure", example.com will
gladly implement it.

------
Sir_Cmpwn
I was looking to do this for my pass-rotate project:

[https://github.com/ddevault/pass-
rotate/issues/1](https://github.com/ddevault/pass-rotate/issues/1)

I hope a spec gains traction.

------
nly
I'd rather we hade /.well-known/delete-account

------
choward
You really only have one password for web sites with password resets via email
and that's the password to log into your email account.

------
andrethegiant
Note to self, create some express middleware that listens to .well-known GETs
and redirects to a map of developer-supplied URLs.

------
IloveHN84
But works only on Apple devices..so in a very small amount of devices

------
michaelmcmillan
Allow me to change username/email while I'm at it!

------
edanweis
How about a well-known URL for unsubscribe?

~~~
IAmLiterallyAB
Not quite the same thing, but there are official email headers for
unsubscribing from email mailing lists.
[https://tools.ietf.org/html/rfc2369](https://tools.ietf.org/html/rfc2369)

------
amelius
Don't we have AI by now that can figure out what button to click to change the
password?

------
polemic
To be pedantic, 'well known' things are not usually specified in advance :D

------
gwbas1c
The real problem is that every single site needs its own separate password.

(Even worse are products and services where you need a separate password for
different features.)

The better way to solve this is to push for better account portability. We
already (kind-of) have this with websites that let you sign in with your
Google or Facebook ID. (Unfortunately, these systems still have privacy
problems because they share your email, or the web site fails if you don't
want to share your email.)

~~~
0xfeba
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

Though I think he will need a more convincing marketing site if he intends for
people to try it out.

~~~
Piskvorrr
GRC is not known for giving much importance to marketing.

