A well-known URL for changing passwords • Hacker News Board

Re: A well-known URL for changing passwords

#101

Post by Leace » Thu, Dec 06, 2018, 7:29 PM UTC

tzs wrote: post #76

isostatic wrote: post #4

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 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-... How widely adopted are these?

GnuPG can use /.well-known/openpgpkey since 2.1.12, and it is used by default since 2.1.23, when you do --lookup-key. E.g., $ gpg --lookup-key foo@example.org will include among the places searched /.well-known/openpgpkey/hu/ ?l=foo at example.org It also looks at /.well-known/openpgpkey/policy. Toss in "-auto-key-locate=clear,wkd,nodefault" to force it to look there for the key even if it already has a key for that…

is ZBase32(SHA1(localPart)) and the standard is described here: https://wiki.gnupg.org/WKD

If one controls a domain, has HTTPS set up and uses PGP this is the easiest and most secure way to host a key (`gpg --list-keys --with-wkd $KEY` shows the hash value).

Enigmail, Mailpile, Mailvelope will automatically discover the key when composing an e-mail. ProtonMail is also working on integration of WKD with their web mail.

Re: A well-known URL for changing passwords

#102

Post by orblivion » Thu, Dec 06, 2018, 7:32 PM UTC

notatoad wrote: post #83

hannob wrote: post #10

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.

This is the sort of scope creep that stops good things from happening. Sure, a full api for password changes sounds great. But why is that related to this project at all? This project is something that will take approximately 5 minutes to implement, and probably not much more to design the "spec" in the first place. and as is, it does something worthwhile. A huge complex project in a related area isn't a replacement…

I'm very sympathetic to creating a password change API, but having a button that takes me straight there would certainly save my time and make me dread the process a lot less.

Next on that list would be "update my payment methods". Of course websites love complicating our lives by hiding it in multiple different places, so that may be of limited utility.

Re: A well-known URL for changing passwords

#103

Post by devman0 » Thu, Dec 06, 2018, 7:32 PM UTC

isostatic wrote: post #4

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 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-... How widely adopted are these?

Apparently https://github.com/.well-known/change-password also works.

Re: A well-known URL for changing passwords

#104

Post by crescentfresh » Thu, Dec 06, 2018, 7:35 PM UTC

intertextuality wrote: post #97

crescentfresh wrote: post #95

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

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

> Did you read the explainer?

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

Re: A well-known URL for changing passwords

#105

Post by WorldMaker » Thu, Dec 06, 2018, 7:37 PM UTC

buster wrote: post #98

WorldMaker wrote: post #72

Earlier quoted context omitted.

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

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

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

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

Re: A well-known URL for changing passwords

#106

Post by pc86 » Thu, Dec 06, 2018, 7:38 PM UTC

curo wrote: post #99

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

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.

Re: A well-known URL for changing passwords

#107

Post by hamandcheese » Thu, Dec 06, 2018, 7:42 PM UTC

pc86 wrote: post #106

curo wrote: post #99

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

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.

Or maybe just ignorance?

Re: A well-known URL for changing passwords

#108

Post by WorldMaker » Thu, Dec 06, 2018, 7:44 PM UTC

delinka wrote: post #93

peterwwillis wrote: post #84

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

Right, the web has never figured out how to scale password UX. There are reasons websites don't intentionally use HTTP Basic/Digest Auth in 2018, beyond the basic implementation details that Basic/Digest aren't particularly secure. Most websites don't want a consistent user interface for password input. Login interfaces are important places to put branding, and include security theater to help users feel safe. The login page is the welcome mat of the web, and every site has a different idea of how it should be experienced, partly because that's a differentiator they want.

Re: A well-known URL for changing passwords

#109

Post by pc86 » Thu, Dec 06, 2018, 7:44 PM UTC

hamandcheese wrote: post #107

pc86 wrote: post #106

Earlier quoted context omitted.

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.

Or maybe just ignorance?

Protecting a user's password is such a basic level of understanding I think ignorance falls under "criminal stupidity" for this one.

Re: A well-known URL for changing passwords

#110

Post by jstarfish » Thu, Dec 06, 2018, 7:44 PM UTC

curo wrote: post #99

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

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.