Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A well-known URL for changing passwords

github.com

Post reply on HN
Print view View original

161–170 of 179 posts

Re: A well-known URL for changing passwords

#161

Post by Rjevski »

epse wrote: post #159
masa331 wrote: post #155

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

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

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.

Re: A well-known URL for changing passwords

#162

Post by pc86 »

jmeyer2k wrote: post #116
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.

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.

I don't mean faster computationally I mean faster in terms of actually developing the product. In the scheme of even the simplest MVPs the additional developer time to hash an input twice is effectively zero.

Re: A well-known URL for changing passwords

#163

Post by pc86 »

frenchy wrote: post #150
kibibu wrote: post #143

Earlier quoted context omitted.

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.

Who uses MD5 for hashing password anymore?

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

Re: A well-known URL for changing passwords

#164

Post by ric2b »

dancek wrote: post #126
kingo55 wrote: post #118

Earlier quoted context omitted.

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

The point of per-user salts is to avoid common passwords from revealing themselves, so that an attacker can't limit his brute-force attempts to just the users with shared passwords that will be easy to break.

Re: A well-known URL for changing passwords

#165

Post by tialaramex »

jtl999 wrote: post #47
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?

As a site owner, how many of those should you handle? Already do special handling of acme-challenge for Let's Encrypt/ACME but that's a given.

As a site owner the main thing you should do about .well-known is be aware that it's special and so e.g. if you add a feature where users get a vanity page at www.example.com/username you shouldn't let them have the username .well-known

The leading dot is there both because that is already special in POSIX and because there's a good chance your validation whitelisting already forbids leading dots, just like newlines, slashes and other characters we can expect to cause mayhem. So this was a less dangerous choice than just well-known without the dot.

Re: A well-known URL for changing passwords

#166

Post by ghostly_s »

TazeTSchnitzel wrote: post #82
ghostly_s wrote: post #78

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?

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…

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.

Re: A well-known URL for changing passwords

#167

Post by WorldMaker »

buster wrote: post #153
WorldMaker wrote: post #105

Earlier quoted context omitted.

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 "OA…

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

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.

Re: A well-known URL for changing passwords

#168

Post by asdkhadsj »

SpaceNugget wrote: post #135
buster wrote: post #39

Earlier quoted context omitted.

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" or whatever a password change request would look like?

I'm not sure if I misunderstand what you are getting at but if you are talking about the .well-known/change-password thing that in this post, its just a well known _redirect_ to the regular change password page for that particular website, you cant PUT to it, it requires a human to navigate the page and fill out the password change form. Unfortunately its not a well-known api endpoint.

I just meant, if we're expecting every site to implement an API to augment the password flow, why even use passwords? Why not get rid of them entirely, and have an API on every website that handles auth? OAuth was just an example of something that could (poorly?) serve as that.

Re: A well-known URL for changing passwords

#169

Post by buster »

WorldMaker wrote: post #167
buster wrote: post #153

Earlier quoted context omitted.

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

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.

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.

Re: A well-known URL for changing passwords

#170

Post by zeroimpl »

CGamesPlay wrote: post #24
Someone1234 wrote: post #14

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

Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that passwo…

Changing your password for a google account seems to involve going to myaccount.google.com (which is not the domain your login is associated with) - so clearly this needs to support redirects to different subdomains.
Post reply on HN