Live data from Hacker News

A well-known URL for changing passwords

github.com

121–130 of 179 posts

Re: A well-known URL for changing passwords

#121
post #93

Earlier quoted context omitted.

If every website has to "figure out" how to "do the right thing", do you just assume they'll all do the same thing in the same way? I think they'll all come up with different ways to solve the problems, which will result in a different user experience for each site. So users will have to do something different on every site when they want to change their password. So it'll be the same as it is now, except that there'…

They already do things the way they want. TFA doesn't change that. This kind of spec doesn't and shouldn't specify UX. It's simply "where do your users go to change passwords?" with a simple reply of "Here: $URL".

It's actually only relevant to UX. It's not useful as an API call. You can't feed it any data, and it doesn't provide anything but a single URL redirect. It will just become a big "Change Password" button on a password manager.

In order to change the password, you have to be logged in. So the website will have to redirect the user to a log-in form, passing along the change-password form URL when authentication succeeds. Then the user can put in the old password and new password, go through an optional MFA hokey-pokey, and get it changed.

If the intent is to speed up password changes, a few optional additions would be faster than the above. The spec could optionally allow (1) the account ID, (2) the user ID, (3) the old password, and (4) the new password. The response could be a challenge and consent request for the user, which the user could then affirm and submit.

The website could still dictate how this works, but the idea is that the password manager would pass along all relevant data in the initial request, eliminating the need for the user to enter it all manually, and eliminating extra page loads. But it requires no site-specific state on the client-side, because all requests would be exactly the same, to this generic URL. Whatever implements the spec URL on the server-side would perform the login and present the password reset challenge, pre-populated for the user.

Re: A well-known URL for changing passwords

#122
post #7

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 . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

off topic but I'm dying to know: why is the "American Society of Heating, Refrigeration, and Air-conditioning Engineers (ASHRAE)" in the "People" section of that IANA well-known URI list?

Re: A well-known URL for changing passwords

#123
post #7

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 . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

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

Re: A well-known URL for changing passwords

#124
post #7

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 . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

off topic but I'm dying to know: why is the "American Society of Heating, Refrigeration, and Air-conditioning Engineers (ASHRAE)" in the "People" section of that IANA well-known URI list?

It's apparently because of an HTTP-based home automation protocol:

http://www.bacnet.org/

http://www.bacnet.org/Addenda/Add-135-2012am-ppr3-draft-17_c...

Re: A well-known URL for changing passwords

#125

Earlier quoted context omitted.

There's no excuse for plaintext passwords in 2019. Even the barest of frameworks provided mechanisms to hash and salt the damn things years before 2013. Not salting/hashing at this point is more than a disservice, it's the equivalent of deliberately not washing your hands after wiping your ass, then going on to serve sandwiches.

I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems. It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their us…

A salted presimised hash, of roughly the same sort we'd use today except that salt was only 12 bits (which seemed reasonable if your Unix systems have 500 users but not if your social network site has 500 million users) and the loop just runs the DES S-Boxes a bunch of times with no way to tune how many.

By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 a configurable amount of times instead of DES some fixed number of times.

Re: A well-known URL for changing passwords

#126

Earlier quoted context omitted.

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.

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 lon…

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.

Re: A well-known URL for changing passwords

#127
post #7

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 . > If it's there (the response code is 2xx or 3xx), the password manager can cause the user's browser to navigate ther…

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

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.

Re: A well-known URL for changing passwords

#128

Earlier quoted context omitted.

I believe Unix passwords were salted and hashed in the 70's and those weren't typically for customer-facing accounts nor obviously for public internet-facing systems. It boggles the mind that the 90s internet boom had to reinvent all the security wheels with such a great history to draw from -- then now that we have bothered to reinvent these wheels yet still decade or two back people are still delinquent in their us…

A salted presimised hash, of roughly the same sort we'd use today except that salt was only 12 bits (which seemed reasonable if your Unix systems have 500 users but not if your social network site has 500 million users) and the loop just runs the DES S-Boxes a bunch of times with no way to tune how many. By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5 a configurable amoun…

> By the 1990s Unix systems were mostly using PHK's version which had a larger salt and ran MD5

That timing seems a bit optimistic to me, especially at large shops where the original crypt() implementation was necessary because you were using things like NIS, Radius, LDAP, etc. and had devices which didn't support MD-5 or better. I was still seeing that into the mid-to-late 2000s.

Re: A well-known URL for changing passwords

#130
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

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

Post reply on HN